GNOME Bugzilla – Bug 686822
possible dlopen()/dlclose() issue with automatic g_type_init()
Last modified: 2012-10-27 16:30:19 UTC
We have a segfault reported from gdk-pixbuf-query-loaders that includes the new gobject_init_ctor(). An initial theory here is that if dlclose() has been called, we'll crash when re-entering. See the attached stack.
Created attachment 227192 [details] backtrace
Created attachment 227195 [details] More bactracing requested by walters Output of: libtool --mode=execute gdb --args ../gdk-pixbuf/gdk-pixbuf-query-loaders libpixbufloader-pcx.la libpixbufloader-png.la b gobject_init_ctor r t a a bt c t a a bt q
Created attachment 227196 [details] backtraces of gobject_init_ctor That last file was wrong, this should be right.
Created attachment 227203 [details] [review] queryloaders: Ensure we link to libgobject This call is necessary to ensure we actually link against libgobject; otherwise it may be stripped if -Wl,--as-needed is in use. The reason we need to link against libgobject is because it now has a global constructor. If the dynamically loaded modules happen to dlclose() libgobject, then reopen it again, we're in for trouble. See https://bugzilla.gnome.org/show_bug.cgi?id=686822 Patch-suggested-by: Ryan Lortie <desrt@desrt.ca> Signed-off-by: Colin Walters <walters@verbum.org>
This patch puts "g_type_ensure (G_TYPE_OBJECT);" within a #ifdef G_OS_WIN32, so it doesn't get called for me. Moving it to immediately after the following #endif does make ldd now say that it's linking to libgobject-2.0.so.0 (which it wasn't before). Which I believe does fix my problem. Shortly after, I'm getting: /usr/bin/ld: /home/darxus/source.test.master/gdk-pixbuf/gdk-pixbuf/tmp-introspectGGuCWy/GdkPixbuf-2.0.o: undefined reference to symbol 'g_module_open' Which I think is not directly related?
Comment on attachment 227203 [details] [review] queryloaders: Ensure we link to libgobject Attachment 227203 [details] pushed as 3a0531d - queryloaders: Ensure we link to libgobject
(In reply to comment #5) > This patch puts "g_type_ensure (G_TYPE_OBJECT);" within a #ifdef G_OS_WIN32, so > it doesn't get called for me. Argh, my bad. Sorry about that...I had such high confidence in the patch I didn't even bother to check it was being called in gdb. > Moving it to immediately after the following > #endif does make ldd now say that it's linking to libgobject-2.0.so.0 (which it > wasn't before). Which I believe does fix my problem. Pushed then, thanks.
*** Bug 686698 has been marked as a duplicate of this bug. ***
Colin, can you put a warning about this possible pitfall of removing the explicit g_type_init call to README.in ?
(In reply to comment #9) > Colin, can you put a warning about this possible pitfall of removing the > explicit g_type_init call to README.in ? Done.