GNOME Bugzilla – Bug 114929
Random crash [dup 105745]
Last modified: 2004-12-22 21:47:04 UTC
Package: gnome-panel Severity: normal Version: 2.2.1 Synopsis: Random crash Bugzilla-Product: gnome-panel Bugzilla-Component: Panel BugBuddy-GnomeVersion: 2.0 (2.2.0.1) Description: Description of Problem: Didn't really do anything, had Kylix 3 runnig, Mozilla and XEmacs. Closed the XEmacs and the panel-crash window came up. Steps to reproduce the problem: 1. 2. 3. Actual Results: Expected Results: How often does this happen? Not very often, had something similar some weeks ago. Additional Information: Debugging Information: Backtrace was generated from '/usr/bin/gnome-terminal' (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...[New Thread 16384 (LWP 22832)] 0x40a160c7 in waitpid () from /lib/libpthread.so.0
+ Trace 37680
Thread 1 (Thread 16384 (LWP 22832))
------- Bug moved to this database by unknown@bugzilla.gnome.org 2003-06-11 08:53 ------- The original reporter (kim.karlsson@luc.ac.be) of this bug does not have an account here. Reassigning to the exporter, unknown@bugzilla.gnome.org. Reassigning to the default owner of the component, gnome-panel-maint@bugzilla.gnome.org.
Cool! You have debugging symbols in one of these mysterious crashes. This may be a duplicate of bug 105745 and may prove helpful. If you get any more of these mysterious crashes, _please_ make sure to submit them. We don't have very many stack traces of these random crashes that have debugging symbols and the developers have had a hard time tracking the problem down. I'm not sure if it's a duplicate (I tend to be pretty horrible at guessing these duplicates when the crashes happen in gdk/gtk+ code), so I'll leave this open for now. Moving to gnome-terminal (though I think it should probably be moved on to gtk+), since the stack trace was generated for a crash in that application. Adding GNOMEVER2.2 & STACKTRACE keywords, setting priority->high & severity->critical (it's a crasher), and marking as new.
Reporter: what version of gtk+ is this ?
*** Bug 114435 has been marked as a duplicate of this bug. ***
I'mn about 60% certain that this is different than bug 105745; my main reason for thinking this is that there are 3 frames in GDK not 4. I have some idea what is going on in this bug -- I discovered a few weeks ago that gdk_event_translate() crashes in just this way if you feed it an event where event->window is a pixmap. But GTK+ should really receive such an event - the only core types of events that fit the bill NoExpose/GraphicsExpose if you copy from pixmaps with certain GC setting that GDK doens't use. If the 'xevent' values in the backtrace are accurate, then this was an extension event - core events only go up to 35. To figure out what extension event it was, we'd need the output of 'xdpyinfo -ext all' (best attached, not pasted) If this diagnosis is correct, I can fix the bug by fixing gdk_event_translate(), but I'd really like to know *what* sort of event is being received. (Partly so I can know how to reproduce/test.)
Created attachment 17506 [details] Output of 'xdpyinfo -ext all'
*** Bug 115085 has been marked as a duplicate of this bug. ***
I've also asked the reporter of bug 115085 to attach the output of 'xdpyinfo -ext all', in case it's helpful to have the info from multiple different people with potentially different configurations.
Created attachment 17980 [details] xdpyinfo output
*** Bug 116530 has been marked as a duplicate of this bug. ***
*** Bug 116356 has been marked as a duplicate of this bug. ***
*** Bug 115594 has been marked as a duplicate of this bug. ***
Bug 116065 may also be a duplicate, but it has one more function in the stack trace (gdk_event_apply_filters), so I'm not sure. The three duplicates I just marked also had debugging symbols. One of them was in gnome-panel. I think this should be moved to gtk+; let me know if I'm wrong.
*** Bug 116938 has been marked as a duplicate of this bug. ***
Elijah, Kjartan - the important thing to get here is not the xdpyinfo information - all the XEvents for the dups here just look like garbage, but rather information about what exact package of GTK+ is triggering these crashes (Version and whose package, in case something like the menu shadow patch is causing the bug.)
I'm using gtk+ from CVS with only a couple of minor typo fixes, one leak fix: diff -u -r1.50.2.2 gtkiconfactory.c --- gtk/gtkiconfactory.c 5 Jul 2003 15:01:05 -0000 1.50.2.2 +++ gtk/gtkiconfactory.c 9 Jul 2003 20:52:33 -0000 @@ -2447,6 +2447,9 @@ { g_object_unref (icon->pixbuf); + if (icon->style) + g_object_unref (icon->style); + g_free (icon); } This is the only code change and should really be filed as a separate bug.
*** Bug 117021 has been marked as a duplicate of this bug. ***
*** Bug 118660 has been marked as a duplicate of this bug. ***
The crash in bug 118660 was with gtk+-1.2.10-25 (rh9 with all updates).
Jules: Oops, I think I should have been more careful in my instructions. It appears that Red Hat provides the GNOME 1.x version of gtk+ in a package called gtk+ and the GNOME 2.x version of gtk+ in a package called gtk2. So we're more interested in the version of the gtk2 package. But if you're simply using the RedHat 9 packages, then that's all the info we need.
All traces here, looking at line numbers, are from GTK+-2.2.1. Kjartan - are you sure that you actually saw this crash? None of the duplicates even look like they were filed by you, and certainly none of them look like they were with GTK+ from early July. I'm going to resolve this as duplicates of bug 105745; if we get any duplicates with GTK+-2.2.2 or newer, please reopen. *** This bug has been marked as a duplicate of 105745 ***
The fix wasn't actually in 2.2.2, so read "2.2.3 or newer"