After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 468495 - System Monitor system tab does not show all CPUs
System Monitor system tab does not show all CPUs
Status: RESOLVED FIXED
Product: system-monitor
Classification: Core
Component: sysinfo
2.18.x
Other Linux
: Normal normal
: ---
Assigned To: System-monitor maintainers
System-monitor maintainers
: 502572 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2007-08-20 12:20 UTC by Sebastien Bacher
Modified: 2011-11-17 06:10 UTC
See Also:
GNOME target: ---
GNOME version: 2.17/2.18


Attachments
The requested various output (11.97 KB, text/plain)
2008-10-19 18:08 UTC, Yanko Kaneti
  Details
Combined screenshot, one says 6 the other 8 (81.22 KB, image/png)
2008-10-19 21:16 UTC, Yanko Kaneti
  Details
minimal fix to libgtop. works for me. (594 bytes, patch)
2008-10-21 09:41 UTC, Yanko Kaneti
reviewed Details | Review
read file into buffer completely (880 bytes, patch)
2009-01-11 14:48 UTC, Byron Hammond
reviewed Details | Review

Description Sebastien Bacher 2007-08-20 12:20:55 UTC
The bug has been opened on https://bugs.launchpad.net/ubuntu/+source/gnome-system-monitor/+bug/131295

"Binary package hint: gnome-system-monitor

On Dell PowerEdge 1950, dual quad core Xeon only the first 5 CPUs are listed on the gnome-system-monitor system tab. This list should if possible auto-resize to accomodate any number of CPU cores.

Also the automatic colour selection for the CPU time graphs on the resources tab uses the same red colour for the last four CPUs.
...
http://launchpadlibrarian.net/8746711/system-monitor.png
system-monitor.png (43.2 KiB, image/png)

Version is 2.18.1.1.

Obviously the colour issue on the resources tabs is easily fixed by the user selecting their own colours so is quite trivial.

Screen shot attached."
Comment 1 Benoît Dejean 2007-08-20 13:37:10 UTC
Please attach your /proc/cpuinfo
Comment 2 Sebastien Bacher 2007-08-21 08:02:24 UTC
the submitter reply

"http://launchpadlibrarian.net/8910688/cpuinfo.txt
Cpuinfo details (3.9 KiB, text/plain)

Cpuinfo attached. Fairly straightforward, two quad core L5320 Xeon processors."
Comment 3 Benoît Dejean 2007-08-21 09:22:14 UTC
If you have gnome-python-desktop, could you please thy this :
python -c 'import gtop; print gtop.cpu()'
Comment 4 Benoît Dejean 2007-08-21 09:22:40 UTC
Which libgtop version ?
Comment 5 Benoît Dejean 2007-08-21 09:24:09 UTC
ok, i think i found it anyway :)
Comment 6 Benoît Dejean 2007-08-21 09:35:35 UTC
how many CPU are displayed in the resource tab ?
Comment 7 Benoît Dejean 2007-08-21 09:48:07 UTC
ok, sorry for all that spam, i'm just working on it.

then :

python -c 'import gtop; print gtop.sysinfo()'
Comment 8 Sebastien Bacher 2007-08-21 13:56:25 UTC
'http://launchpadlibrarian.net/8915749/python-gtop.txt
python-gtop.txt  (6.2 KiB, text/plain)

Output from python in attached files.

Eight CPUs are shown in resources tab but the initial state is for the last four to all have the same colour (red)."
Comment 9 Benoît Dejean 2007-08-21 14:32:22 UTC
Is that the same kernel ? because some fields are new. I cannot reproduce it myself, i'm running with your cpuinfo and get the 8 CPUs.

grep BUFSIZ /usr/include/*.h please ?

There's a little bug in gnome-python-desktop/gtop, i'm going to fix, that's why the cpu() lists have only 7 elements.

The color issue is a different topic, easy to fix. Just to check, are all the graphs showing activity ?
Comment 10 Sebastien Bacher 2007-08-21 15:07:37 UTC
the same kernel than what? feisty has 2.6.20
Comment 11 Benoît Dejean 2007-08-21 15:20:59 UTC
the one used to get cpuinfo and the one used to run these python tests
Comment 12 Sebastien Bacher 2007-08-23 09:13:06 UTC
reply from the distribution bug submitter

"http://launchpadlibrarian.net/8953673/cpuinfo.txt
cpuinfo.txt (4.9 KiB, text/plain)

Attached a new cpuinfo file, the desktop machine was unavailable when I generated the cpuinfo.txt so that came from an identical system running Ubuntu 7.04 Server. The python run was performed on the desktop machine that shows the problem.

Note, the problem exists only on the "System" tab, i.e. the left most tab that shows the OS version, CPUs and system status. The graphs page shows all 8 cores correctly so it looks like the underlying libraries correctly enumerate things but the UI just doesn't have space to list all the CPUs. I did notice in the output from the python run that it sees them as 2 CPUs each with 4 cores which is is correct. So maybe a better way of listing them would be to list the actual physical CPUs and then have an expander to list the cores for a particular CPU?"
Comment 13 Benoît Dejean 2007-08-23 10:40:18 UTC
Yes, the grouping/expander looks like a good idea. But /proc/cpuinfo is really fuzzy, there is no standard formatting between arch. And it's linux-centric, but why not :)

I'm really waiting for you to post 'grep BUFSIZ /usr/include/*.h', because i don't know why but libgtop heavily relies on this macro for buffer size, and this could explain why the resultat are truncated. Because with these cpuinfo files, i can't reproduce, i get the full list.
Comment 14 Sebastien Bacher 2007-08-23 14:35:17 UTC
the BUFSIZ is set to 8192
Comment 15 Benoît Dejean 2007-12-08 23:11:22 UTC
*** Bug 502572 has been marked as a duplicate of this bug. ***
Comment 16 Yanko Kaneti 2008-10-17 17:25:12 UTC
I see the same thing under fedora. There is also the fedora bug about it.
https://bugzilla.redhat.com/show_bug.cgi?id=467455
Confirming.
Comment 17 Benoît Dejean 2008-10-18 16:28:22 UTC
Could you please run http://launchpadlibrarian.net/8915749/python-gtop.txt ?
Comment 18 Benoît Dejean 2008-10-19 10:36:19 UTC
Could you please attach your /proc/stat and tell me what is your libgtop version ?
Thanks.
Comment 19 Yanko Kaneti 2008-10-19 18:06:33 UTC
Did you read comment 12 carefully? There should not be a problem with libgtop if the graphs page shows the correct number of cores. Its the "System" tab only that is the problem.
Unless of course g-s-m has umpteen ways of determining the same thing....
Comment 20 Yanko Kaneti 2008-10-19 18:08:47 UTC
Created attachment 120875 [details]
The requested various output
Comment 21 Benoît Dejean 2008-10-19 20:35:21 UTC
Well, that's exactly the case in libgtop. That bug was workaround around 2.19.91 that's why i'd like to know your libgtop version.
Comment 22 Yanko Kaneti 2008-10-19 20:57:46 UTC
Paint me confused. libgtop shouldn't have to do anything with the difference between the number of cores reported in the "System" tab and the one in the "Resources" tab in gnome-system-monitor. 

I was testing both gnome-system-monitor and libgtop from fedora rawhide
libgtop2-2.24.0-1.fc10.i386
gnome-system-monitor-2.24.0-3.fc10.i386
and the ones from jhbuilding head.
Comment 23 Yanko Kaneti 2008-10-19 21:16:12 UTC
Created attachment 120884 [details]
Combined screenshot, one says 6 the other 8
Comment 24 Benoît Dejean 2008-10-20 18:05:40 UTC
If you look at the gtop.sysinfo() output, you can see only 6 cores, just like on the screenshot. The first tab uses sysinfo() while the resources tab uses gtop.cpu(). That's why i'm looking into a libgtop problem.
Comment 25 Benoît Dejean 2008-10-20 18:14:37 UTC
I wonder why when i replay the cpuinfo file you provide with 2.24.0 i get : 

LD_LIBRARY_PATH=lib/.libs python -c 'import gtop; print [p["processor"] for p in gtop.sysinfo()];'
['0', '1', '2', '3', '4', '5', '6', '7']

:/
Comment 26 Yanko Kaneti 2008-10-20 21:24:56 UTC
Sorry for being so petulantly incredulous. Couldn't believe the libarary had more than one way of fetching that particular info.

The problem is indeed a short read of /proc/cpuinfo in init_sysinfo->file_to_buffer from libgtop, here it does only 4050 bytes, it has to be read again to get the whole thing. Perhaps this has something to do with the 4KB fedora kernel stack size. I see you've done a similar workaround in the past for /proc/stat reading.
Comment 27 Yanko Kaneti 2008-10-20 21:40:10 UTC
I've been told this 4K are actually the kernel page size and this is exactly the expected behaviour. These files should be read 4KB a piece.
Comment 28 Benoît Dejean 2008-10-20 22:45:44 UTC
(In reply to comment #26)
> Sorry for being so petulantly incredulous. Couldn't believe the libarary had
> more than one way of fetching that particular info.

It's not the same info at all. On one hand you have the cpu features, on the other hand you have the cpu times. It's the parsing that fails in one case.

> The problem is indeed a short read of /proc/cpuinfo in
> init_sysinfo->file_to_buffer from libgtop, here it does only 4050 bytes, it has
> to be read again to get the whole thing. Perhaps this has something to do with
> the 4KB fedora kernel stack size. I see you've done a similar workaround in the
> past for /proc/stat reading.

Any strace of "python -c 'import gtop; print [p["processor"] for p
in gtop.sysinfo()];'" ?

That's not related at all to kernel page size.
Comment 29 Yanko Kaneti 2008-10-20 23:04:08 UTC
I told you what happens because I've tracked and tested it. You need to read the proc files (in this case /proc/cpuinfo) in less than page size pieces or in whatever pieces the OS gives it to you, but with more than one read.
I doesn't have anything to do with wrong parsing of the output. 
Comment 30 Benoît Dejean 2008-10-21 06:34:09 UTC
I don't care then. "works here".
Comment 31 Yanko Kaneti 2008-10-21 09:41:44 UTC
Created attachment 120997 [details] [review]
minimal fix to libgtop. works for me.
Comment 32 Matthias Clasen 2008-11-10 02:08:13 UTC
The patch leaks buffer
Comment 33 Byron Hammond 2009-01-11 14:48:03 UTC
Created attachment 126219 [details] [review]
read file into buffer completely

read should be looped until it returns 0 or the buffer is full. This patch works for me as I can reproduce the same bug.
Comment 34 Benoît Dejean 2009-01-11 22:18:30 UTC
i know, i just don't get why this could be interrupted. i'd just like someone to show me a strace output
Comment 35 Byron Hammond 2009-01-12 10:45:23 UTC
Want the whole strace file or just the relelvant lines?
Here is what looks to be the relevant snippet...

7222  stat("/usr/bin/lsb_release", {st_mode=S_IFREG|0755, st_size=10750, ...}) = 0
7222  open("/proc/cpuinfo", O_RDONLY)   = 17
7222  read(17, "processor\t: 0\nvendor_id\t: Genuin"..., 16383) = 3660
7222  close(17)                         = 0
7222  open("/proc/meminfo", O_RDONLY)   = 17
7222  read(17, "MemTotal:      6118460 kB\nMemFre"..., 8191) = 826
7222  close(17)                         = 0
7222  open("/etc/mtab", O_RDONLY)       = 17
7222  futex(0x7f694f882b80, 0x81 /* FUTEX_??? */, 2147483647) = 0
7222  fstat(17, {st_mode=S_IFREG|0644, st_size=829, ...}) = 0
7222  mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f6953644000
7222  read(17, "/dev/sda5 / ext3 rw,relatime,err"..., 4096) = 829
7222  open("/proc/filesystems", O_RDONLY) = 18
7222  fstat(18, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
7222  mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f69534e9000
7222  read(18, "nodev\tsysfs\nnodev\trootfs\nnodev\tb"..., 1024) = 309
7222  read(18, "", 1024)                = 0
7222  close(18)                         = 0
Comment 36 Benoît Dejean 2009-01-12 18:38:02 UTC
OK thanks. I found it very strange because even when i run libgtop on a 128 way ia64, i don't get this behaviour, the content on /proc files always comes as a whole.
Comment 37 Benoît Dejean 2009-01-12 18:42:05 UTC
I've commited a patch a bit different, i hope you won't mind.

http://svn.gnome.org/viewvc/libgtop/branches/gnome-2-24/sysdeps/linux/glibtop_private.c?r1=2790&r2=2789&pathrev=2790
Comment 38 Robert Roth 2011-07-11 09:30:55 UTC
If the patch for this has been commited, and fixes the problem, this issue should be set to Fixed.
Comment 39 Robert Roth 2011-11-17 06:10:19 UTC
As the fix is in libgtop master([1]), I am setting this as fixed. Feel free to reopen if you have this issue using gnome system monitor 3.2.1 or later.
 
[1] http://git.gnome.org/browse/libgtop/tree/sysdeps/linux/glibtop_private.c#n70