GNOME Bugzilla – Bug 691077
gio-querymodules crashes with SIGSEGV
Last modified: 2013-01-11 09:20:07 UTC
Created attachment 232648 [details] [review] a patch When running gio-querymodules-64 a SIGSEGV may be raised and a core file generated. It happens: when running spec macro %glib2_gio_module_post (in MIC image creation, or rpm installation) when there is more than one library in directory /usr/lib64/gio/modules (one is not enough) Investigation shows that it comes from re-initialisation of libgobject.so (constructor function) from a dynamic library. It tries to access symbols previously defined but invalidated because the previous dynamic library that recorded it was unloaded. Reverting the commit http://git.gnome.org/browse/glib/commit/gio/gio-querymodules.c?id=1dc774a653e992e1153fbed16f90097fa8db467f solves the problem (see patch). But maybe is there an upstream "2.38" way of doing it since g_type_init is now deprecated.
The proposed patch is a hack. What is the real problem? It is that gobject and plugins don't unregister them when their dynamic library is swept out of memory. Is their a plan to solve it ?
(In reply to comment #1) calling g_type_init() multiple times within the same process space is perfectly legal, so I doubt reverting that commit is actually solving anything. > What is the real problem? It is that gobject and plugins don't unregister them > when their dynamic library is swept out of memory. if the plugin loads GObject and then tries to unload it, then it's always going to fail: GObject registers a lot of static types (i.e. type data that is not meant to be unloaded), so it has never been safe to unload it and then re-load it. > Is their a plan to solve it ? yes, the proposed plan is to disallow unloading GType modules altogether.
(In reply to comment #2) > (In reply to comment #1) > > calling g_type_init() multiple times within the same process space is perfectly > legal, so I doubt reverting that commit is actually solving anything. In fact, it solves the problem. > > What is the real problem? It is that gobject and plugins don't unregister them > > when their dynamic library is swept out of memory. > > if the plugin loads GObject and then tries to unload it, then it's always going > to fail: GObject registers a lot of static types (i.e. type data that is not > meant to be unloaded), so it has never been safe to unload it and then re-load > it. Oh yeah. BTW, to be clearly understood, libgobject is loaded and unloaded automatically by plugins libraries of /usr/lib64/gio/modules. > > Is their a plan to solve it ? > > yes, the proposed plan is to disallow unloading GType modules altogether. What a poor plan! But a good plan because it solves the problem. Then the solution is to remove line 97 of gio-querymodules: the line of 'g_module_close (module);'
(In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > > calling g_type_init() multiple times within the same process space is perfectly > > legal, so I doubt reverting that commit is actually solving anything. > > In fact, it solves the problem. it would be nice if you looked into *why* it seems to solve the issue. just closing the GModule should not do anything to the types registered by the GIO plugins - unless a plugin is trying to unload its own types. > > > What is the real problem? It is that gobject and plugins don't unregister them > > > when their dynamic library is swept out of memory. > > > > if the plugin loads GObject and then tries to unload it, then it's always going > > to fail: GObject registers a lot of static types (i.e. type data that is not > > meant to be unloaded), so it has never been safe to unload it and then re-load > > it. > > Oh yeah. BTW, to be clearly understood, libgobject is loaded and unloaded > automatically by plugins libraries of /usr/lib64/gio/modules. which libraries are these? can you pinpoint the actual plugin that causes this issue? > > > Is their a plan to solve it ? > > > > yes, the proposed plan is to disallow unloading GType modules altogether. > > What a poor plan! not really: unloading types never really worked, and it cannot be compatibly fixed. all in all, it's the least disruptive option.
(In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #2) > > > (In reply to comment #1) > > > > > > calling g_type_init() multiple times within the same process space is perfectly > > > legal, so I doubt reverting that commit is actually solving anything. > > > > In fact, it solves the problem. > > it would be nice if you looked into *why* it seems to solve the issue. It solves because gio-querymodules now creates the static types and keeps it available to the loaded plugins modules. More: it wasn't linked to libgobject-2.0 before and now it is (see "ldd /usr/bin/gio-querymodules-64" output) Before the patch load gio-querymodules -> auto dlopen libglib-2.0 load module 1 -> auto dlopen libgobject-2.0 -> auto constructor gobject close module 1 -> auto dlclose libgobject-2.0 load module 2 -> auto dlopen libgobject-2.0, auto constructor gobject CRASH After the patch load gio-querymodules -> auto dlopen libglib-2.0, auto dlopen libgobject-2.0, auto constructor gobject load module 1 -> nothing to do because already done (see man dlopen) close module 1 load module 2 -> nothing to do because already done (see man dlopen) ... > just closing the GModule should not do anything to the types registered by the > GIO plugins - unless a plugin is trying to unload its own types. > > > > > What is the real problem? It is that gobject and plugins don't unregister them > > > > when their dynamic library is swept out of memory. > > > > > > if the plugin loads GObject and then tries to unload it, then it's always going > > > to fail: GObject registers a lot of static types (i.e. type data that is not > > > meant to be unloaded), so it has never been safe to unload it and then re-load > > > it. > > > > Oh yeah. BTW, to be clearly understood, libgobject is loaded and unloaded > > automatically by plugins libraries of /usr/lib64/gio/modules. > > which libraries are these? can you pinpoint the actual plugin that causes this > issue? $ ls /usr/lib64/gio/modules giomodule.cache libgiognutls.so libgsettingsgconfbackend.so libdconfsettings.so libgioremote-volume-monitor.so libgvfsdbus.so > > > > > Is their a plan to solve it ? > > > > > > yes, the proposed plan is to disallow unloading GType modules altogether. > > > > What a poor plan! > > not really: unloading types never really worked, and it cannot be compatibly > fixed. all in all, it's the least disruptive option.
(In reply to comment #5) > > > > it would be nice if you looked into *why* it seems to solve the issue. > > It solves because gio-querymodules now creates the static types > and keeps it available to the loaded plugins modules. > More: it wasn't linked to libgobject-2.0 before and > now it is (see "ldd /usr/bin/gio-querymodules-64" output) Bingo. Thats the real issue, I'd say.
Then who confirms that bug?
Created attachment 233182 [details] [review] 0001-gio-querymodules-Ensure-we-re-linked-to-GObject.patch g_type_init() is deprecated, we should use g_type_ensure() instead.
Review of attachment 233182 [details] [review]: looks fine
I tested this patch on my build platform (openSUSE Build Service) and can confirm that my gio-querymodules crash is gone with this as well.