GNOME Bugzilla – Bug 335311
100% CPU usage & freeze on drawer resize.
Last modified: 2007-04-16 03:33:22 UTC
1) Create a corner panel 2) Add a drawer, position it on the end of the panel next to the screen edge. 3) Open the drawer's properties 4) Decrease the drawer's size gradually. At some point, the panel begins consuming 100% cpu, and locks out input. (Ctrl-Alt-F1 and capslock don't work) until gnome-panel is killed. On my desktop, this happens at and below 42 pixels width on the right side, or 39 pixels width on the left side. Happens with openbox & metacity window managers. It does *not* happen if I put the drawer somewhere other than a screen-edge-adjacent end of the panel.
Confirmed present in gnome-panel 2.14.1.
Confirmed in 2.16.2, but this time from increasing the size of the drawer, not decreasing it. It's a very bad freeze. Had to ssh in remotely, which by itself took several minutes due to how unresponsive the system was. If I hadn't been able to, I would have lost any data I had open, therefore I'm increasing the severity/priority of this bug.
I couldn't make this happen in 2.17.2. I placed the drawer applet in the bottom-right corner (far right of the bottom panel) and tried to resize it up or down, slowly or faster, with the drawer open or closed, but I couldn't get any bad behavior. Does this still happen in the latest version? If so, could you give more details on how to make this happen (is there a specific corner? a specific way to add/move the drawer before opening its properties windows?).
I could not reproduce this either. Lowering severity and priority
Just got it again, GNOME gnome-panel 2.17.90. This time, it was increasing the size beyond some threshold of a (OPEN) drawer on the very left end of a non-expanded horizontal panel at the top-left of the screen. Re-reading my post, I didn't mention that the drawer apparantly needs to be open while resizing it in order to trigger this. Upon restarting gnome-panel in order to recover, while the drawer's size was still set so as to trigger this issue, it occured again immediately upon opening the drawer. I also noticed for the first time that, for a second or two once the drawer was open that it was "jiggling" back and forth by a pixel or two. Once it got out of control and locked up my X input it appeared to stop. Again, I had to find another machine from which to ssh in and kill gnome-panel to halt the process without a hard reboot. That's why I had filed the severity/priority as high as i did.
*** This bug has been marked as a duplicate of 332916 ***