GNOME Bugzilla – Bug 634534
Crash in gdk_event_apply_filters()
Last modified: 2010-11-11 13:23:43 UTC
Program received signal SIGSEGV, Segmentation fault. 0x00007ffff758ec96 in gdk_event_apply_filters (display=0x6361e0) at gdkeventsource.c:72 72 result = filter->function (xevent, event, filter->data); Missing separate debuginfos, use: debuginfo-install flac-1.2.1-6.fc12.x86_64 libXtst-1.0.99.2-3.fc12.x86_64 libasyncns-0.8-1.fc13.x86_64 libcanberra-0.26-2.fc15.x86_64 libcanberra-gtk3-0.26-2.fc15.x86_64 libogg-1.2.0-1.fc14.x86_64 libsndfile-1.0.23-1.fc14.x86_64 libtdb-1.2.1-3.fc14.x86_64 libtool-ltdl-2.2.10-3.fc14.x86_64 libvorbis-1.3.1-2.fc14.x86_64 nss-softokn-freebl-3.12.8-1.fc14.x86_64 polkit-0.98-4.fc14.x86_64 pulseaudio-libs-0.9.21-6.fc13.x86_64 pulseaudio-libs-glib2-0.9.21-6.fc13.x86_64 tcp_wrappers-libs-7.6-59.fc14.x86_64 (gdb) bt
+ Trace 224621
67 while (tmp_list) 68 { 69 GdkEventFilter *filter = (GdkEventFilter*) tmp_list->data; 70 71 tmp_list = tmp_list->next; 72 result = filter->function (xevent, event, filter->data); 73 74 if (result != GDK_FILTER_CONTINUE) 75 return result; 76 } (gdb) p filter $1 = (GdkEventFilter *) 0x0 I get this when changing the resolution of my screen using the display panel in gnome-control-center. I would either add an assert() if the members of the list are never supposed to be NULL, or there's a bug removing that filter from the list.
My gtk+ tip was of d1829ecd7436e84267d224b3c73ae406cc61e855. Testing with the latest master now.
Same thing happens with the latest master.
Sorry, setting importance for a bit of red.
valgrind output is absolutely uninsteresting, then I switch resolutions and get: ==13597== Jump to the invalid address stated on the next line ==13597== at 0x2C20307830207B20: ??? ==13597== by 0x8F0: ??? ==13597== Address 0x2c20307830207b20 is not stack'd, malloc'd or (recently) free'd ==13597== ==13597== ==13597== Process terminating with default action of signal 11 (SIGSEGV) ==13597== Bad permissions for mapped region at address 0x2C20307830207B20 ==13597== at 0x2C20307830207B20: ??? ==13597== by 0x8F0: ??? Not really useful.
My guess would be that some loaded module installs a filter, then gets unloaded without removing it.
Actually was a double-free in libgnome-desktop that was causing the filters to be freed. Not sure why valgrind wasn't able to catch it.
Created attachment 174244 [details] [review] Fix possible double-free when destroying private windows This could cause free'ing random data when the members of ->windows were destroyed, but ->windows itself wasn't. As it was != NULL, we'd be free memory that wouldn't belong to us anymore.
Attachment 174244 [details] pushed as 7e967de - Fix possible double-free when destroying private windows