GNOME Bugzilla – Bug 521478
Erratic behaviour in vertical windowlist case 100% CPU and potential dataloss
Last modified: 2008-12-09 05:10:50 UTC
Steps to reproduce: 1) Add a windowlist to a narrow vertical panel. 2) Open many windows/applications 3) Once windowlist decides to divide into two columns (usually long before actal available space is reached) CPU is stuck at 100% and system becomes unresponsive. Stack trace: Other information: As mentioned in http://bugzilla.gnome.org/show_bug.cgi?id=86382#c61 having a narrow vertical panel (40px-ish wide) will send your gnome-panel into a 100% CPU usage loop due to the erratic switching to two columns in window-list. See http://bugzilla.gnome.org/show_bug.cgi?id=86382#c59 for how the problem manifests itself on a wider (120px) panel. While you can save the situation by (after considerable time) manage to alt-ctrl-f1 and login to killall -9 gnome-panel, for a large amount of Ubuntu users this will lead to a dataloss situation by having to force a cold reboot with the powerswitch.
This bug (together with the generally erratci behaviour) was not present in gnome-panel windowlist 2.18
I also experience this bug with Panel 2.20.1 on Ubuntu 7.10 (Gutsy), 1280x1024 screen resolution, with plenty of RAM. I have a Window List applet on left vertical panel of width ~40px. Having 8 windows opened is ok. Opening the 9th window makes gnome-panel use 100% CPU until I kill it.
Looks like a duplicate of bug 511994
Yes, it does seem to be a duplicate of bug 511994 and also of bug 487080 , the latter which has been closed as a duplicate of bug 86382 I split of this bug from bug 86382 since it's both not exactly the same and is Critical in nature, but I still think the problem originates in the "fixes" for bug 86382 Also this bug IS present on fully updated 8.04 LTS beta. Somebody REALLY should start caring about this before 8.04 LTS is out the door. PS This is NOT a ram problem. I have 4GiB of RAM on my desktop and I'm not seeing RAM spikes on neither my desktop or my laptop. And can somebody PLEASE change the Status away from unconfirmed? This is a crasher bug and even if the temporary solution is easy (no windowlist in vertical panels) that in many is difficult to figure out for a normal user since the reason why things "hang" is not readily apparent.
I can't confirm this with 2.22.2. I've even got to the point of having the windows in 3 columns, and CPU usage is normal, panel is responsive and I can swith to any window I want. Could anyone confirm it's fixed in 2.22?
In 2.22.2, the bug remains, albeit in a subtler form. Merely opening 10-12 windows no longer locks up the machine. However, try leaving 10-12 windows open, and then change the panel width (via property dialog). This freezes the panel and drives CPU to 100%.
> I've even got to the point of having the windows in 3 columns, You completely missed the requirement for reproducing this. The windowlist has to be _too_narrow_to_fit_even_2_coluns_. It's when it tries to switch to the second column, but can't, since there is no space, that it goes into a loop that puts the CPU to 100%. So try again, eg using 40px wide column and 30px size icons (should fit 1 column of icons but not two...)
Created attachment 113907 [details] Vertical window list with 4 columns
The panel width was 24 pixels. And every time it needs to add a new column because the current one is full, all the columns get smaller so a new one fits in the panel. Also, in the vertical window list there are no icons, at least not here (not even with one column)
(In reply to comment #6) > However, try leaving 10-12 windows open, and then change the panel width (via > property dialog). This freezes the panel and drives CPU to 100%. It works fine here, with 12 windows and 3 columns, resizing from 24 pixels to 30 and 40. No heavy CPU usage and no freeze
(In reply to comment #9) > Also, in the vertical window list there are no icons, at least not here (not > even with one column) There wasn't with 24 pixels width, but there are with 40.
If the behaviour has changed in 2.22.2 to allow the width of each window-entry to collapse, then this bug might very well be fixed. Unfortunately I have no easy way to verify the fix presently. Sitting on an Ubuntu 7.10 box. Will try to put something newer on my laptop in the next days.
I've reproduced this bug in debian sid using gnome-panel 2.20.3. Then, I've installed gnome-panel 2.22.2 from experimental, restarted gnome and had the same problem. So, this is not fixed in gnome-panel 2.22.2 as some people have claimed.
This bug is caused when calling panel_applet_set_size_hints (panel-applet.c) inside the applet_size_request function (window-list.c) all these files are from gnome-panel code. The applet_size_request function is actually a callback, connected to the size_request of the applet object, and the weird thing is that every the time this callback was called, it happened more than twice. So, with a great number of windows open, it becomes really slow.
Today I tested with a freshly installed fully upgraded Ubuntu 8.04 on my laptop. No matter how I stressed the windowlist (well over 50 open apps/instances in up to 20-30 columns) it never once locked up. So AFAICT, this bug seems to have been fixed*. Relevant version numbers libwnck22 2.22.3-0ubuntu1 gnome-panel 2.22.2-0ubuntu1.1 * Do note though, I dont know if any debian and/or ubuntu specific patches changes behaviour from plain vanilla, as I havnt verified by compiling gnome from source and repeating the tests. If someone finds it still persisting in plain gnome sources, feel free to reopen. :)