Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 8304)]
0x407bcbf2 in pthread_mutex_lock () from /lib/libpthread.so.0
#0 0x407bcbf2 in pthread_mutex_lock () from /lib/libpthread.so.0
#1 0x406491c1 in _XLockMutex () from /usr/X11R6/lib/libX11.so.6
#2 0x406342d3 in XrmQGetResource () from /usr/X11R6/lib/libX11.so.6
#3 0x40613fe2 in XGetDefault () from /usr/X11R6/lib/libX11.so.6
#4 0x404ef3d0 in get_boolean_default () from /usr/lib/libcairo.so.2
#5 0x404ef4c8 in _cairo_xlib_init_screen_font_options () from
#6 0x404ef87d in _cairo_xlib_screen_info_get () from /usr/lib/libcairo.so.2
#7 0x404ed606 in _cairo_xlib_surface_create_internal () from
#8 0x404ed967 in cairo_xlib_surface_create () from /usr/lib/libcairo.so.2
#9 0x403f64c3 in gdk_x11_ref_cairo_surface () from
#10 0x403d0c88 in _gdk_drawable_ref_cairo_surface () from
#11 0x403dac72 in gdk_pixmap_ref_cairo_surface () from
#12 0x403d0c88 in _gdk_drawable_ref_cairo_surface () from
#13 0x403e44ef in gdk_window_begin_paint_region () from
#14 0x401dfb9f in gtk_main_do_event () from /usr/lib/libgtk-x11-2.0.so.0
#15 0x403e6e0a in gdk_window_process_updates_internal () from
#16 0x403e6f5e in gdk_window_process_all_updates () from
#17 0x401518ce in gtk_container_idle_sizer () from
#18 0x408bb243 in g_idle_dispatch () from /usr/lib/libglib-2.0.so.0
#19 0x408b83a8 in g_main_dispatch () from /usr/lib/libglib-2.0.so.0
#20 0x408b9398 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#21 0x408b96bd in g_main_context_iterate () from /usr/lib/libglib-2.0.so.0
#22 0x408b9c33 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#23 0x401df4c3 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#24 0x0805891b in main (argc=1, argv=0xbffff7e4) at main.c:592
This is certainly not a bug that afflicts GTK+ and cairo-using programs in general.
Before we can do anything to debug this, we'll need more information. Could you
please let us know:
1) What program was this? (And what version)
2) How was it compiled? (From a distribution? Manually? If so, please describe
the build process as accurately as possible)
distribution: Lunar Linux http://lunar-linux.org/
compiled from svn sources. No special optimizations.
Xfmedia version 0.9.0svn, Copyright (c) Brian Tarricone, <email@example.com>
Released under the terms of the GNU General Public License.
Compiled against xine-lib 1.1.0, using xine-lib 1.1.0.
Compiled against Xfce 4.3.0, using Xfce 4.3.0.
Most other apps and libs are compiled with:
-O3 -s -mtune=athlon-xp -march=athlon-xp -mmmx -msse -m3dnow -mfpmath=sse,387
A few days ago I upgraded to glibc 2.3.5.
downgrading gtk (2.8.1 -> 2.6.9) fixed the issue. Might still be a problem in
xfmedia or cairo. Dunno.
Hi all - I'm the author of the app in question. I'm unable to reproduce the bug
with the default gtk theme; once I switch to ClearLooks, I get the crash. I do
*not* get the crash with gtk 2.6.10, even using ClearLooks. So, I managed to
get a bt off of a debug build of all of this stuff.
Anyway, this is all out of garnome 2.12.0:
Backtrace is huge; I'll attach.
Created attachment 3246 [details]
backtrace with debug info
I've found a way to "fix" the problem. Here's the situation, with my attempt to
not ramble on:
Xfmedia uses xine-lib to play audio/video files. xine-lib requires that apps
call XInitThreads() before using xine. I have a GtkWidget, called XfmediaXine,
which wraps xine into a a gtk widget. In xfmedia_xine_realize(), I call
XInitThreads() before creating a separate Display* to track xine events (this is
the way recommended by the xine developers to avoid locking problems between
xine and gdk).
Now, I removed the XInitThreads() call from xfmedia_xine_realize(), and moved it
to main(), right under g_thread_init(); gdk_threads_init(); gtk_init();. Now I
get no crash, and everything *appears* to be behaving properly.
Any ideas what was up with this? My previous method worked with gtk 2.2, 2.4,
and 2.6, and only started causing crashes using gtk 2.8. Anyway, unless this
rings a bell to someone as a gtk/cairo problem that I somehow managed to
trigger, feel free to close this.
Thanks for the update.
I really don't have enough experience with Xlib thread support to know if there's
anything that can or should be done in cairo to help here.
I'm glad you foud a way to work around the problem.
I'm closing this as NOTOURBUG.