GNOME Bugzilla – Bug 97487
Crash in gdk_event_apply_filters
Last modified: 2015-03-24 13:00:35 UTC
Package: gnome-panel Severity: critical Version: GNOME2.1.0 2.1.1 Synopsis: Spontaneous crash Bugzilla-Product: gnome-panel Bugzilla-Component: Panel BugBuddy-GnomeVersion: 2.0 (2.1.1) Description: panel, it go kaboom Debugging Information: Backtrace was generated from '/gnome/head/INSTALL/bin/gnome-panel' [New Thread 8192 (LWP 8607)] 0x420ae169 in wait4 () from /lib/i686/libc.so.6
+ Trace 29773
Thread 1 (Thread 8192 (LWP 8607))
send_event = 0, display = 0x80c1af8, window = 29360129, width = 29360129, height = 1164813186}, xconfigurerequest = {type = 17, serial = 73726, send_event = 0, display = 0x80c1af8, parent = 29360129, window = 29360129, x = 1164813186, y = 0, width = 24, height = 2, border_width = 798, above = 0, detail = 0, value_mask = 4}, xcirculate = {type = 17, serial = 73726, send_event = 0, display = 0x80c1af8, event = 29360129, window = 29360129, place = 1164813186}, xcirculaterequest = {type = 17, serial = 73726, send_event = 0, display = 0x80c1af8, parent = 29360129, window = 29360129, place = 1164813186}, xproperty = {type = 17, serial = 73726, send_event = 0, display = 0x80c1af8, window = 29360129, atom = 29360129, time = 1164813186, state = 0}, xselectionclear = { type = 17, serial = 73726, send_event = 0, display = 0x80c1af8, window = 29360129, selection = 29360129, time = 1164813186}, xselectionrequest = {type = 17, serial = 73726, send_event = 0, display = 0x80c1af8, owner = 29360129, requestor = 29360129, selection = 1164813186, target = 0, property = 24, time = 2}, xselection = {type = 17, serial = 73726, send_event = 0, display = 0x80c1af8, requestor = 29360129, selection = 29360129, target = 1164813186, property = 0, time = 24}, xcolormap = {type = 17, serial = 73726, send_event = 0, display = 0x80c1af8, window = 29360129, colormap = 29360129, new = 1164813186, state = 0}, xclient = {type = 17, serial = 73726, send_event = 0, display = 0x80c1af8, window = 29360129, message_type = 29360129, format = 1164813186, data = { b = "\0\0\0\0\030\0\0\0\002\0\0\0\036\003\0\0\0\0\0", s = {0, 0, 24, 0, 2, 0, 798, 0, 0, 0}, l = {0, 24, 2, 798, 0}}}, xmapping = {type = 17, serial = 73726, send_event = 0, display = 0x80c1af8, window = 29360129, request = 29360129, first_keycode = 1164813186, count = 0}, xerror = { type = 17, display = 0x11ffe, resourceid = 0, serial = 135011064, error_code = 1 '\001', request_code = 0 '\0', minor_code = 192 ' ------- Bug moved to this database by unknown@bugzilla.gnome.org 2002-11-02 10:44 ------- Reassigning to the default owner of the component, gnome-panel-maint@bugzilla.gnome.org.
Looking at this trace, it looks useless, but I submitted it anyway. It was totally spontaneous.
Andrew, were you doing something special ?
No. Sorry :-(
Got this again when closing the mouse capplet
Got this again when closing galeon. It seems to happen when I window-manager-close an application. Sometimes.
Andrew: are you using the notification area ? If so, I think it's a dup of #94514.
Doh, please ignore the previous comment.
*** Bug 97932 has been marked as a duplicate of this bug. ***
*** Bug 97975 has been marked as a duplicate of this bug. ***
*** Bug 97962 has been marked as a duplicate of this bug. ***
For the record: still happens in 2.1.2.
*** Bug 98081 has been marked as a duplicate of this bug. ***
Andrew: which version of gnome-panel were you using the first time you saw this bug ? Was it 2.1.1 or HEAD after 2.1.1 was released ? All the duplicates come from 2.1.2 versions. So it looks like something was broken between 2.1.1 et 2.1.2.
I build from CVS, so it would be HEAD.
*** Bug 98220 has been marked as a duplicate of this bug. ***
*** Bug 98290 has been marked as a duplicate of this bug. ***
*** Bug 98346 has been marked as a duplicate of this bug. ***
*** Bug 98583 has been marked as a duplicate of this bug. ***
All the previous duplicates were from version 2.1.2. However, there's this old bug #85553 which seems quite similar. This was with gnome-panel 2.0.0.
*** Bug 98680 has been marked as a duplicate of this bug. ***
*** Bug 98729 has been marked as a duplicate of this bug. ***
*** Bug 98487 has been marked as a duplicate of this bug. ***
*** Bug 98777 has been marked as a duplicate of this bug. ***
/me is getting spam :-(
Sorry for the spam, Andrew. I'm setting the priority to 'Urgent'.
Don't worry about it
*** Bug 99103 has been marked as a duplicate of this bug. ***
I'll pitch in that it seems to be happening to me multiple times upon a wm close event...
*** Bug 99193 has been marked as a duplicate of this bug. ***
Owen: is this related to bug 97451? Is it possibly gdk/gtk's fault?
Not likely to be GDK/GTK+'s fault, though I couldn't be sure of it; most likely, the panel messing up it's filter management in some way. It's not related to bug 97451, I'd be pretty sure. (It looks reasonably similar to the gnome 1.4 crash-o-doom, but that might just be coincidental)
*** Bug 99345 has been marked as a duplicate of this bug. ***
I easily remember having this nasty crash-on-wm-close-event since the commit of translucent panels of 2002-11-01 since I'm updating HEAD about twice a week. I didn't know if it doesn't crash if translucent panels aren't activated. I'll just try.
Well, I don't see any crash left when using the standard gtk theme. Please ppl try confirming this. Sorry not to have helped before :/
No such luck. I am using standard panels ("Default" background), and they keep crashing.
I reverted to transparent panels, and I still don't have had a crash since this morning. I'm being lucky or what ? Sorry, I can't reproduce with either transparent or not ATM :/ I'm still sure this is it, since this is the sole commit that impacted all the panel widgets code. Andrew: are you running CVS HEAD or still 2.1.2 ?
CVS HEAD, I updated yesterday.
In fact, I may not be getting this crash still since I just got bug 99361; some of the crashes I thought were this may actually have been bug 99361. I'll look at backtraces from now on.
*** Bug 99381 has been marked as a duplicate of this bug. ***
*** Bug 99404 has been marked as a duplicate of this bug. ***
*** Bug 99643 has been marked as a duplicate of this bug. ***
*** Bug 99663 has been marked as a duplicate of this bug. ***
In bug 99663 (the last duplicate), filed by Kjartan Maaras, he says the following: The panel crashed when I ran gedit in valgrind with a 2 meg datafile from cachegrind. Valgrind/gedit was eating up most of my memory when the panel crashed.
Okay, I've tried hard to reproduce this but didn't succeed. All I got was the trace in #98853 once. So I don't know what's going on here really. I'm pretty sure the bug (and #98853) is caused by the translucent background patch - prolly memory corruption/ref counting error somewhere - but eyeballing the code I can't see anything obvious.
*** Bug 99706 has been marked as a duplicate of this bug. ***
I got _this_ crash, from HEAD, without any transparent panels.
I still believe its due to the translucent panel patch. The event filter for the background monitor is installed whether or not any panels are translucent ... which sucks.
Just a note to say that I *think* that #59500 started in 1.4.0.4 which was the very release that translucent panels were added to 1.4.x :-/ On the bright side, maybe this is what finally causes someone to spend enough time on the bug to get it fixed in both releases :-)
Well, if you can reproduce it ... feel free to spend as much time as you want on fixing it. Especially since you've so much experience looking at it already :-)))) (I still can't reroduce)
Owen: I have some suspicions about this .. It seems to me that the window on which the filter is being invoked gets a DestroyNotify during the filter invocation, then the filter list is corrupt and we're screwed ... Given that the filter handler for the background monitor emits a signal from which (AFAIR) quite a few roundtrips are done ... This is the root window, though, so that's pretty far fetched. However, in trying to reproduce this I did once get the "attempted to destroy root window" g_error ... So, I dunno - anything ring a bell to you ?
Round trips don't matter ... events won't get processed until you run the main loop. If you run the main loop though out of an event filter, well, I would expect bad things... it's possible that some rentrancy protection is possible, but it's going to be difficult.
Maybe getting someone to spend time on finding a reproducable test case and removing the patch to see if it's really the culprit would be good?
*** Bug 99962 has been marked as a duplicate of this bug. ***
*** Bug 99960 has been marked as a duplicate of this bug. ***
*** Bug 100256 has been marked as a duplicate of this bug. ***
So I've just committed a re-write of the background rendering code. If this bug was due to memory corruption in the old code it may have gone away ... I have my doubts though. So, anyone who saw this regularily - I'd appreciate if you could update and let us know if you still get this bug.
I just got this ... so its a *very* rare thing ... FWIW the window structure looked like this (gdb) p *(GdkWindowObject *) window $4 = {parent_instance = {parent_instance = {g_type_instance = {g_class = 0x81d29c8}, ref_count = 2, qdata = 0x0}}, impl = 0x830fa00, parent = 0x18, user_data = 0x21, x = 137223096, y = 0, extension_events = 0, filters = 0x190, children = 0x4, bg_color = { pixel = 63, red = 8192, green = 0, blue = 49}, bg_pixmap = 0x0, paint_stack = 0x2f, update_area = 0x2f, update_freeze_count = 136086760, window_type = 0 '\000', depth = 0 '\000', resize_count = 0 '\000', state = 136048648, guffaw_gravity = 0, input_only = 0, modal_hint = 0, destroyed = 0, event_mask = 135937128}
I had several crashes every day before, and haven't had a single crash after the latest commit, so even if the bug is not completely solved the panel is a lot more usable now. Thanks!
For what its worth, before Mark's re-write of the background rendering code I had this panel crash many times per day. After Mark's patch, I have had zero.
Let me guess, you guys don't have a translucent background right ? Then this bug is definetly triggered by panel-background-monitor - the monitor is not enabled now unless you have a translucent background. Richard or Dennis: could you confirm you're not using a translucent background ?
Yep, I'm not using a translucent background.
Yes, the same here. I am not using a translucent panel.
I still have translucents panels and crashes, but your commit added another problem with my translucent panels. I've got a translucent corner panel with only icons, and the first time it's exposed, you only see the panel shaded, but not a single icon, even if the panel size is correctly requested. When I hover the icons, they're 'shown'. As a side note, since the appeareance of this bug, I think my panels are eatting up all my memory, and then are crashing each time they couldn't have any more. For instance, when I've just logged in after a booting, the panels _always_ take _a lot of time_ before being very crashy. I don't know if that can help or not though
*** Bug 100705 has been marked as a duplicate of this bug. ***
*** Bug 100748 has been marked as a duplicate of this bug. ***
For what its worth I've just committed a Pixmap leak fix from Federic to this code. The pixmap was leaked when the desktop background changed. This could well be the bug ... the pixmap reference was the pixmap for the background owned by nautilus ...
Is this the case in 1.4.x too? if it's an easy fix I'd love to see it fixed there too.
Kjartaan: I don't know. If it uses the BackgroundMonitor code Ian wrote the probably yes. The fix was @@ -187,7 +187,11 @@ if (xev->type == PropertyNotify && xev->xproperty.atom == monitor->xatom && xev->xproperty.window == monitor->xwindow) { + if (monitor->gdkpixmap) + g_object_unref (monitor->gdkpixmap); monitor->gdkpixmap = NULL; + if (monitor->gdkpixbuf) + g_object_unref (monitor->gdkpixbuf); monitor->gdkpixbuf = NULL; g_signal_emit (monitor, signals [CHANGED], 0); }
The only similar code I can find is from desktop_event_filter() in main.c:481: static GdkFilterReturn desktop_event_filter (GdkXEvent *gdk_xevent, GdkEvent *event, gpointer data) { XEvent *xevent; GSList *item; PanelWidget *panel; xevent = (XEvent *) gdk_xevent; if (xevent->type == PropertyNotify && xevent->xproperty.atom == gdk_atom_intern("ESETROOT_PMAP_ID", TRUE)) { get_desktop_pixmap (); for (item = panels; item; item = g_slist_next (item)) { panel = PANEL_WIDGET (item->data); if (panel->back_type == PANEL_BACK_TRANSLUCENT) { panel_widget_setup_translucent_background (panel); panel_widget_force_repaint (panel); } } } return GDK_FILTER_CONTINUE; } If you can help fix this I owe you a bottle of scotch, or tullamore dew if that's more up your alley :)
BTW, this shows Ian's original translucency patch: http://cvs.gnome.org/bonsai/cvsquery.cgi?treeid=default&branch=gnome-core-1-4&branchtype=match&dir=gnome-core%2Fpanel&file=&filetype=match&who=yakk&whotype=match&sortby=Date&hours=2&date=all&mindate=&maxdate=&cvsroot=%2Fcvs%2Fgnome
This is prolly it: yakk: +static void yakk: +get_desktop_pixmap() yakk: +{ yakk: + desktop_pixmap = get_pixmap_prop ("_XROOTPMAP_ID"); yakk: +} it should be if (desktop_pixmap) gtk_object_unref (GTK_OBJECT (desktop_pixmap)); desktop_pixmap = get_pixmap_prop ("_XROOTPMAP_ID");
Some more leaks (I think): yakk: + /* and we're finished with it */ yakk: + gdk_pixbuf_ref (background_shaded); yakk: + if (panel->backpix != NULL) { yakk: + gdk_pixbuf_unref (panel->backpix); yakk: + } yakk: + panel->backpix = background_shaded; yakk: + gdk_pixbuf_unref (background); Should remove the gdk_pixbuf_ref (background_shaded);. We already own the pixbuf. yakk: + panel->backpixmap = pixmap; yakk: + gdk_pixmap_ref (panel->backpixmap); Similarily, the ref here isn't neccessary.
Doh. He fixed that in his second patch :/
I'm updating from CVS and using a transparent panel for a bit. Let's see if it still crashes :-)
Woaah, I admit there's now a big difference: I didn't had any crash since I updated to HEAD, say 10 hours ago, whereas I'm still using translucent panels. Thanks, Frederic :) ----------------- On a side note : The exposure problem I talked about two days ago is still present ATM though. That's quite strange having a really-transparent-panel :) I can provide very small screenshots to explain the problem If I didn't explained the thing correctly. I think everyone can reproduce this with a translucent panel with some launchers. I may fill another bug for that if this bug is considered closed in some time.
Is anyone seeing this crash with 2.1.4 ?
Okay, I'm assuming its fixed. If anyone gets a dup with >= 2.1.4 please re-open. Owen: its a bit worrying that leaking foreign pixmap references could lead to such a weird crash. We'd need to come up with a decent test case to nail it, though.
*** Bug 101953 has been marked as a duplicate of this bug. ***
bug 101953 is in 2.1.5 - reopening (it has the same trace as one of the dupes here)
I'm hoping that bug 101953 has an incorrect version... there aren't any other duplicates.
Mmhh, I don't know if the version is correct, but as far as this bug is concerned, I never had a single crash since Frederic's fix. Couldn't this one be closed ?
Alex: are you sure that your bug (bug #101953) occured with gnome-panel 2.1.5 ? Are you using a transparent panel ? For the record, Alex reproduced bug #98274 (see bug #101836) too. So #98274 was reopened too. Stephane: we'll close the bug when we're sure it's fixed. But you can remove yourself from the CC.
#101593 isn't actually a dup - even if it is reproducable in 2.1.5. Closing again.
*** Bug 103705 has been marked as a duplicate of this bug. ***
*** Bug 118350 has been marked as a duplicate of this bug. ***
*** Bug 119224 has been marked as a duplicate of this bug. ***
*** Bug 119854 has been marked as a duplicate of this bug. ***
*** Bug 124264 has been marked as a duplicate of this bug. ***
*** Bug 131956 has been marked as a duplicate of this bug. ***