From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408 Description of problem: xosview hangs under 2.4.18-4smp xosview works under 2.4.18-4 (and under 2.4.18-3smp) I did an strace and it hangs here: open("/proc/stat", O_RDONLY|O_LARGEFILE) = 4 fstat64(4, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x400fc000 read(4, "cpu 22963 0 1655 17816\ncpu0 116"..., 1024) = 1024 read(4, "00000 1000000000 1000000000 1000"..., 1024) = 1024 Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. need x86 & SMP 2. install RH7.3 3. install new kernal eratta (2.4.18-4smp) 4. Reboot 5. run xosview Actual Results: xosview hangs Expected Results: xosview should run as per normal Additional info: not 100% certain if this is a bug in xosview or new kernel eratta. Since new kernel changed the behaviour, initial bugzilla report is against kernel.
The same with "kernel-2.4.18-4.athlon" on single-processor mainboard.
I just saw the [RHBA-2002:085-11] advisory, and the following looks suspicious: 3. Problem description: . . . Finally, bugs in the vsnprintf implementation and in the way the kernel reads the /proc/stat file are now fixed. Note that xosview is having trouble reading /proc/stat (from the strace above).
The problem seems to be in fs/proc/proc_misc.c where, in the latest release, 1000000000 is added to kstat_irqs(i). I removed that change, and now xosview works fine. I have a single processor Athlon system.
The kernel bug adding 1 billion to the interrupt counts is fixed in 64825, but xosview should not hang due to the size of the /proc/stat increasing. Reassigned to xosview.
I ran xosview under ddd and note the following. In linux/cpumeter.cpu, CPUMeter::countCPUs() it is reading STATFILENAME (/proc/stats) by way of a C++ ifstream: ifstream stats( STATFILENAME ); . . char buf[1024]; . . stats.getline(buf, 1024); The problem is that the new intr line in the stats file is now much longer than it used to be (due to the kernel change). The new line length is 2476 characters, and the 1st read of that line will return the 1st 1024 bytes, but the 2nd read does not pick up the rest of the line. My C++ is not good enough to realize whether this is a bug in C++, or whether getline is supposed to work this way. one potential quick fix is to change all the proc/stat buffers from 1024 to 4096, but honestly, this is a crock, and a longer line will still cause this problem. (e.g. bugger size interrupt values). Someone familiar w/ C++ could probably address this problem.
I note that my suggested fix above (changing the buffer size) is not correct fix. After applying it, I note that xosview runs at 100% cpu usage. Have not investigated why though.
Created attachment 58464 [details] patch which uses std::string
If that doesn't help, the cpumeter.cc code contains much pointer arithmetic using C-style char buffers and string functions. Hard to mix with C++ strings.
I just uploaded src and i386 packages to incoming.redhat.com/libc6 with a modified buffer size of 4096. I didn't think that increasing the buffer size was the real proper way to fix it, but it's a reasonable temporary solution. I sent the xosview author the patch too, although it would seem that he's probably aware of this by now having read this bug report. Ho hum, will continue to use the version I have modified on the SMP machine here until RH get a solution out.
For information: I had a reply from the author, he has updated the CVS tree and changed the buffer length to 4096 in linux/cpumeter.cc. Note to self: Read bugzilla *before* bothering to do anything yourself!
It's fixed in 1.8.0-3
We are seeing this exact behavior on RedHat 9.0 with kernel-smp-2.4.20-18.9 and either xosview-1.8.0-11 or the rawhide xosview-1.8.0-15, except that in the strace it is hanging on reading /proc/interrupts instead of /proc/stat.