GNOME Bugzilla – Bug 316911
dragging the top panel around with a multiload-applet-2 in it causes a crash
Last modified: 2010-01-24 01:07:20 UTC
This bug has been opened here: http://bugzilla.ubuntu.com/show_bug.cgi?id=15999 "Here's how: 1. right-click in some empty space on the panel at the top of the screen 2. "Add to Panel..." 3. click "System Monitor" in the "System & Hardware" section 4. click "Add" 5. right-click on the cpu-meter that appears in the panel 6. click 'Preferences' 7. turn on 3 or 4 of the graphs. I use "processor", "network", "swap space" and "harddisk" 8. click 'Close" 9. find some more empty space on the panel at the top of the screen 10. click and hold the left mouse button on that empty space in the panel. the mouse cursor should become a fist 11. drag the fist to the left border of the screen. the panel will redraw along the left side. I usually get a crash at this point. if you don't get a crash, keep the left mouse button held down and try dragging to the right side and the bottom edge in turn. wave the mouse around all over the screen. I always get a crash within a few seconds of doing this. The crash looks like this: The application "multiload-applet-2" has quit unexpectedly. At that time, my mouse cursor is stuck as a fist, and won't click anywhere, so I have to use the keyboard to chose "close". Then I see: "System Monitor" has quit unexpectedly, along with the option to reload it."
backtrace of the crash using gnome-applets 2.12
+ Trace 63133
I can reproduce ================================== Backtrace was generated from '/opt/gnome211/libexec/multiload-applet-2' Using host libthread_db library "/lib/tls/libthread_db.so.1". `system-supplied DSO at 0xffffe000' has disappeared; keeping its symbols. [Thread debugging using libthread_db enabled] [New Thread -1223215424 (LWP 5862)] 0xb7d1f1de in __waitpid_nocancel () from /lib/tls/libpthread.so.0
+ Trace 63149
Thread 1 (Thread -1223215424 (LWP 5862))
*** Bug 169211 has been marked as a duplicate of this bug. ***
Confirmed with FC4. Some experimentation suggests that the same bug exists in charpick and may be filed as #315723.
*** Bug 322902 has been marked as a duplicate of this bug. ***
this just happened with only the cpu meter enabled.
seems to happen when trying to unref the tooltips widget ? g_object_unref (g->tooltips);
This is from a gdb trace (don't ask me why it is creating and destroying so many objects) during the crash it seems that *g is pointing to non-useful memory: Breakpoint 2, load_graph_load_config (g=0x810cfc0) at load-graph.c:273 Breakpoint 2, load_graph_load_config (g=0x810e138) at load-graph.c:273 Breakpoint 2, load_graph_load_config (g=0x810e500) at load-graph.c:273 Breakpoint 2, load_graph_load_config (g=0x810e940) at load-graph.c:273 Breakpoint 2, load_graph_load_config (g=0x810ebb8) at load-graph.c:273 Breakpoint 2, load_graph_load_config (g=0x810ee68) at load-graph.c:273 Breakpoint 3, load_graph_destroy (widget=0x80e5658, data_ptr=0x810cfc0) Breakpoint 3, load_graph_destroy (widget=0x80e56d8, data_ptr=0x810e500) Breakpoint 3, load_graph_destroy (widget=0x80e5798, data_ptr=0x810ee68) Breakpoint 3, load_graph_destroy (widget=0x80e5698, data_ptr=0x810e138) Breakpoint 3, load_graph_destroy (widget=0x80e5718, data_ptr=0x810e940) Breakpoint 3, load_graph_destroy (widget=0x80e5758, data_ptr=0x810ebb8) Breakpoint 2, load_graph_load_config (g=0x810e940) at load-graph.c:273 Breakpoint 2, load_graph_load_config (g=0x810e138) at load-graph.c:273 Breakpoint 2, load_graph_load_config (g=0x81101c8) at load-graph.c:273 Breakpoint 2, load_graph_load_config (g=0x81180e8) at load-graph.c:273 Breakpoint 2, load_graph_load_config (g=0x8118518) at load-graph.c:273 Breakpoint 2, load_graph_load_config (g=0x81186a8) at load-graph.c:273 Breakpoint 3, load_graph_destroy (widget=0x80e5820, data_ptr=0x810e940) Breakpoint 3, load_graph_destroy (widget=0x80e58a0, data_ptr=0x81101c8) Breakpoint 3, load_graph_destroy (widget=0x80e5960, data_ptr=0x81186a8) Breakpoint 3, load_graph_destroy (widget=0x80e5860, data_ptr=0x810e138) Breakpoint 3, load_graph_destroy (widget=0x80e58e0, data_ptr=0x81180e8) Breakpoint 3, load_graph_destroy (widget=0x80e5920, data_ptr=0x8118518) Breakpoint 2, load_graph_load_config (g=0x810ebb8) at load-graph.c:273 Breakpoint 2, load_graph_load_config (g=0x8115328) at load-graph.c:273 Breakpoint 2, load_graph_load_config (g=0x8118360) at load-graph.c:273 Breakpoint 2, load_graph_load_config (g=0x8117ff8) at load-graph.c:273 Breakpoint 2, load_graph_load_config (g=0x811a0c8) at load-graph.c:273 Breakpoint 2, load_graph_load_config (g=0x811a258) at load-graph.c:273 Breakpoint 3, load_graph_destroy (widget=0x80e59a0, data_ptr=0x810ebb8) Breakpoint 3, load_graph_destroy (widget=0x80e5a20, data_ptr=0x8118360) Breakpoint 3, load_graph_destroy (widget=0x80e58e0, data_ptr=0x811a258) Breakpoint 3, load_graph_destroy (widget=0x80e59e0, data_ptr=0x8115328) Program received signal SIGSEGV, Segmentation fault. 0x008d117b in g_object_unref () from /usr/lib/libgobject-2.0.so.0 (gdb) bt
+ Trace 66125
Here is a somewhat more readable trace. >> load_graph_new (8528638) multiload @ 8507180 << load_graph_new >> load_graph_new (852cc00) multiload @ 8507180 << load_graph_new >> load_graph_new (8531d68) multiload @ 8507180 << load_graph_new >> load_graph_new (8532258) multiload @ 8507180 << load_graph_new >> load_graph_new (8532578) multiload @ 8507180 << load_graph_new >> load_graph_new (8532880) multiload @ 8507180 << load_graph_new glibtop: This machine has 1 CPUs, 1 are being monitored. >> load_graph_destroy (8528638) << load_graph_destroy >> load_graph_destroy (8531d68) << load_graph_destroy >> load_graph_destroy (8532880) << load_graph_destroy >> load_graph_destroy (852cc00) Program received signal SIGSEGV, Segmentation fault.
+ Trace 66126
$1 = {multiload = 0x8532570, n = 139667576, id = 23, speed = 88, size = 1, orient = 88, pixel_size = 3, draw_width = 124, draw_height = 21, get_data = 0x58, allocated = 23, colors = 0x7c, data = 0x1, data_size = 124, pos = 0x17, colors_allocated = 127, main_widget = 0x1, frame = 0x7e, box = 0x17, disp = 0x7f, pixmap = 0x1, gc = 0x58, timer_index = -1, tooltips = 0x7c, show_frame = 21, cpu_time = {88, 23, 124, 0, 0}, cpu_last = {0, 0, 0, 25, 17228120}, cpu_initialized = 139681104, visible = 0, tooltip_update = 0, name = 0xa0 <Address 0xa0 out of bounds>}
It fails on the ones that aren't on my panel. The three that ran are cpuload, netload and diskload. I then added swapload to my panel and it then did 4 correctly. If I have all 6, it doesn't crash.
2006-02-14 Davyd Madeley <davyd@madeley.id.au> * main.c: Unconditionally destroy the graph widgets even if they're not visible, otherwise they will simply be destroyed when their container is destroyed, only it will crash now that it's user_data has been free'd. Closes #316911.