Taking a CPU offline causes users of glibtop_get_cpu() to have problems with ‘xcpu’ array variables
In more detail than the title, glibtop_get_cpu() output for any of the xcpu array variables appears to stop at the first disabled processor. For example, let’s assume a quad core machine and disable ‘cpu1’ (0 indexed). cpu0, cpu2 and cpu3 are still enabled. In this case, glibtop_get_cpu() produces output as if only one processor is enabled. See attachments.
More detailed: I was using the following command on a Linux machine (Ubuntu 18.04) as I have a hardware problem which affects one (only one) of the CPU’s in a quad-core machine causing an intermittent system freeze every other day.
# echo 0 > /sys/devices/system/cpu/cpu1/online
The above command had the desire affect – the machine does not hang anymore.
The problem is that libgtop does not seem to handle the above situation very well. Basically, glibtop_get_cpu_s() and glibtop_open_s() don’t deal with a disabled CPU.
Still more detail: the libgtop library basically parses /proc/stat (at least in the Linux implementation). When cpu1 (e.g.) is disabled, the string ‘cpu1’ disappears from /proc/stat. The proposed change basically allows for that by allowing for the situation where ‘cpu1’ (say) does not appear in the output. ‘cpu1’ (say) is then skipped over and the statistics for ‘cpu2’ (say) will be placed in the array index that ‘cpu1’ would have used. That is, the statistics array is ‘bunched up’ – leaving no ‘holes’.
Question: Should the array be bunched up like this, or should functions using libgtop allow for ‘holes’ in the array?
I am proposing a small set of changes below that allow for libgtop to ‘bunch up’ over the holes. This is my first bug contribution to gnome so please feel free to make suggestions or criticisms.
Samples of the problem: PreviousBehaviour-AllCPUsOnline.txt PreviousBehaviour-CPU1Offline.txt AfterFix-CPU1Offline.txt
Proposed changes: open.c.patch cpu.c.patch