Bug#641905: procps: CPU usage reporting for very long running jobs broken.
Package: procps Version: 1:3.2.8-9 Severity: normal I found a bug in reporting of CPU usage for a long running calculation on a quad-core 64 bit machine. While the calculation runs I monitor the process by running the following command every 30 seconds: ps -C elmfract -o args=,%cpu=,time=,rss=,vsz=,pid= Below is a fragment of the logfile that shows where it goes wrong: /home/eric/bin/elmfract F14 398 24-20:29:51 7733232 7989604 1771 /home/eric/bin/elmfract F14 398 24-20:31:51 7733232 7989604 1771 /home/eric/bin/elmfract F14 1712725 106751-23:47:16 7733232 7989604 1771 /home/eric/bin/elmfract F14 1719007 107149-12:01:11 7733232 7989604 1771 The first two lines show a CPU usage of 398%, i.e. practically 4 cores busy. The second two lines show a CPU usage of 1712725%, suggesting some 17127 busy cores. As it turns out, my machine does not have that many cores :-). Also the reporting of 106751 cpu days used for the calculation seems exagerated. The running process is not in the least bit bothered, and produces correct results. It happens after approximately 24*24*3600+20*3600+31*60+51 = 2147511 cpu seconds were spent. This is very close to 2^31 milliseconds, which hints at a signed 32 bit integer overflowing somewhere. Probably not many people run calculations of several cpu weeks. The phenomenon is reproducible, I have seen it with another long calculation, at exactly the same moment. The process itself reports its cpu usage using the times(2) system call, as follows: CPU (total) real: 178h 3m 6.43s, usr: 38163h 3m 32.80s, sys: 2542964h 7m 37.79s, total: 2581127h 11m 10.59s The user and system times obtained via times(2) are wrong, but the elapsed time (measured by the times(2) return value) is OK. My guess is that this may be a proc filesystem problem. -- System Information: Debian Release: 6.0.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages procps depends on: ii initscripts 2.88dsf-13.1 scripts for initializing and shutt ii libc6 2.11.2-10Embedded GNU C Library: Shared lib ii libncurses5 5.7+20100313-5 shared libraries for terminal hand ii libncursesw55.7+20100313-5 shared libraries for terminal hand ii lsb-base3.2-23.2squeeze1 Linux Standard Base 3.2 init scrip Versions of packages procps recommends: ii psmisc22.11-1utilities that use the proc file s procps suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#495181: libapache2-mod-php5 does not install php5.conf and php5.load
Package: libapache2-mod-php5 Version: 5.2.6-2+b1 Severity: grave How the problem was found: On a clean lenny system I tried to install mediawiki. I had done this before on an etch system where it went so smoothly I almost forgot how I configured it. This time I could not get to the configuration. The browser (iceweasel) appeared not know what to do with .php files when pointed to http://localhost/mediawiki/config: it asked me if I wanted to download them (at some point I got the same complaint about .phtml file). Analysis: I tracked the problem down to the libapache2-mod-php5 package not installing the php5.load and php5.conf files in the /etc/apache2/mods-enabled/ directory, and, subsequently not enabling them. 'dpkg -S php5.conf' and 'dpkg -S php5.load' /did/ report that the files were there while they weren't. I opened the deb file with 'ar x' and found out that the php5.load and php5.conf files were indeed present in the expected place. I looked at the control files in the package but can see nothing that would remove the files, and my limited knowledge of debian packages stopped me from further understanding. The /etc/apache2/mods-enabled/ directory was writable (for root), owned by root, group root, permissions drwxr-xr-x (and the disk was not full). Related installed package versions: apache2: 2.2.9-6 apache2-mpm-prefork: 2.2.9-6 apache2.2-common: 2.2.9-6 php5: 5.2.6-2 php5-common: 5.2.6-2+b1 Fix: I took the php5.load and php5.conf files from the deb archive, and copied them manually into /etc/apache2/mods-enabled/, used a2enmod to enable the php5 module for apache, and restarted the apache server. Then the mediawiki config url as mentioned above loaded correctly. I did not use it further yet but it seems to work now (TM). Related bugs: I guess this bug may be related to bugs #463905 and #471548. The latter talks about removing and reinstalling the package. I did remove and reinstall the package a few times, when I was trying to get the mediawiki package to work. However, the mediawiki never worked in the first place, and I suspect it is due to the problem with the libapache2-mod-php5 package, and has nothing to do with reinstalling, though I may be wrong of course. Rating: I rated this bug grave because the php5 module is not enabled after installation, and cannot be enabled using a2enmod. Hope this helps, please do ask for more info if needed. Regards, Eric Meijer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495181: [php-maint] Bug#495181: libapache2-mod-php5 does not install php5.conf and php5.load
Ondřej Surý wrote: I guess this bug may be related to bugs #463905 and #471548. The latter talks about removing and reinstalling the package. I did remove and reinstall the package a few times, when I was trying to get the mediawiki package to work. Eric, could you do: # dpkg --force-depends --purge libapache2-mod-php5 and then reinstall it using apt-get # apt-get install libapache2-mod-php5 I think that you just removed libapache2-mod-php5 in the past, then removed conf files from /etc/apache2/mods-available/ (this is place where php5.load and php5.conf gets installed). If you only 'remove' package without purging conf files stays in place and if you manually removed them they won't get reinstalled. I think that this problem is just your local setup and package is not broken. Ondrej. Ondrej, This does work. I still don't understand how the php5.* files disappeared in the first place. Thanks, Eric -- Eric L. Meijer, email: [EMAIL PROTECTED] fractals: http://www.elmweb.nl/ gitaar: http://www.elmweb.nl/guitar/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#411769: Indefinitely looping atan2() function for amd64
Package: libc6
Version: 2.3.2.ds1-22sarge5
Architecture: amd64
CPU: Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz
$ uname -a
Linux gloeiworm 2.6.18-2-amd64 #1 SMP Wed Nov 15 03:18:20 UTC 2006
x86_64 GNU/Linux
Problem:
==
With the right arguments the atan2() function will run on indefinitely
(forever unless killed). This is found for both C++ and C programs.
The simplest C program I could find that exhibits the problem is
file oef.c:
#include math.h
int main()
{
atan2(0.87600557019648551, 0.012279899574599516);
return 0;
}
build it:
gcc -o oef oef.c -lm
run it:
./oef
This will run forever.
If I attach with gdb, I can see the following:
$ gdb
GNU gdb 6.3-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as x86_64-linux.
(gdb) attach 4492
Attaching to process 4492
Using host libthread_db library /lib/libthread_db.so.1.
Reading symbols from /home/eric/pruts/oef...done.
Reading symbols from /lib/libm.so.6...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux-x86-64.so.2...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
0x2b0a15e124ec in __signbitl () from /lib/libm.so.6
(gdb) where
#0 0x2b0a15e124ec in __signbitl () from /lib/libm.so.6
#1 0x2b0a15e13e46 in __signbitl () from /lib/libm.so.6
#2 0x2b0a15e13681 in __signbitl () from /lib/libm.so.6
#3 0x2b0a15e13522 in __signbitl () from /lib/libm.so.6
#4 0x2b0a15ddd4e0 in fegetexcept () from /lib/libm.so.6
#5 0x2b0a15df5b95 in atan2 () from /lib/libm.so.6
#6 0x00400559 in main ()
The top of the stack is exactly the same as in my actual C++ program,
the behaviour depends on the exact values of the arguments of the atan2
function. In my actual program there are millions of calls to atan2()
that run just fine before this happens. The behaviour does not seem to
depend on optimization flags, also happens with mfpmath=387, and is the
same for C and C++. I got almost the same problem when I made my own
atan2() implementation, but then the __signbitl() in the stack was
called from an atan() function. The problem does not occur on my other
sarge system, which is 32bit Pentium 4.
It seems like this is a known problem with the 64 bit port of the math
library:
see http://sourceware.org/ml/libc-alpha/2003-11/msg00187.html
Please ask if you need more info,
Eric Meijer
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
