GNOME Bugzilla – Bug 391278
g_thread_init() called too late, possibly causing memory corruptions
Last modified: 2007-08-17 11:16:24 UTC
With glib trunk, I get this critical warning when running gst-inspect-0.10, gst-typefind-0.10 etc: ***MEMORY-WARNING***: gst-launch-0.10[16931]: GSlice: g_thread_init() must be called before all other GLib functions; memory corruption due to late invocation of g_thread_init() has been detected; this program is likely to crash, leak or unexpectedly abort soon... glib svn trunk, gstreamer/gst-plugins-* cvs HEAD
If this is true, and I understand it correctly, this would not only seem to be an ABI break on glib's part [*], but also completely defeat the purpose of doing library initialisations indirectly via GOption, at least for libraries that use threads internally. The problem seems to come from g_option_context_add_group(), which creates GList nodes, which internally uses GSlice. So basically all applications initialising GStreamer via GOption have to be changed to initialise the GLib thread system first (if gst_init() is used directly, we do the call to g_thread_init() first and can only pray that the application hasn't used any other GLib/Gtk functions first). [*] However, the GLib API manual says "g_thread_init() must not be called directly or indirectly as a callback from GLib.", and I guess that includes GOption callbacks, so arguably we've been using it incorrectly all along ...
Created attachment 79172 [details] [review] Init GLib threads in constructor, and warn if that's not possible and threads haven't been initialised elsewhere Not sure what to do about this. Two possibilities come to mind: 1) Change our init semantics. This probably means most applications initialising GStreamer via GOption need to be changed/fixed. 2) Try to initialise the threading system in a constructor and issue a warning in cases where that's not possible (ie. where the compiler does not support it or we don't have special code for that compiler) and where the threading system hasn't been initialised by the time the application calls gst_init_get_option_group(). This would only affect applications that link against a GStreamer that hasn't been compiled with GCC or Forte and that use GOption for initing and haven't inited the threads system otherwise yet. And even for those cases there's not really a functional regression, we just init the thread system as early as possible, issue a warning and keep our our fingers crossed. Can anyone think of a better option? Attached patch implements option 2).
Related discussion on gtk-devel-list: http://mail.gnome.org/archives/gtk-devel-list/2007-January/msg00005.html Even if this gets resolved in GLib in future, it still affects all GStreamer appplications using GLib-2.10.x and GLib-2.12.x. Not using the constructor hack, for three reasons: - it breaks applications which do g_thread_init (NULL) unconditionally first thing in main(), such as totem - it hides the problem on most systems, so applications are much less likely to get fixed - application authors and people deploying applications should be aware the problem exists for current and previous versions of GStreamer and GLib Committed the following for now, I think it's the best we can do: 2007-01-05 Tim-Philipp Müller <tim at centricular dot net> * gst/gst.c: (gst_init_get_option_group), (gst_init_check), (init_pre): Call g_thread_init() first thing in gst_init() / gst_check_init(). When initialisation is done via gst_init_get_option_group() and GOption parsing, issue a warning if the GLib thread system has not been initialised yet by the time gst_init_get_option_group() is called, as it's quite likely other GLib functions such as g_option_context_new() have been called already then, and g_thread_init() must be called before any other GLib function. The application in question must be fixed in that case, since memory corruption might happen otherwise. We issue the warning because even if the GLib folks decide to work around the problem on their end in future, this is still an issue with all GLib versions >= 2.10.0, so we should warn until we depend on a GLib version we know to be safe. Closes bug #391278.
*** Bug 354483 has been marked as a duplicate of this bug. ***
*** Bug 379690 has been marked as a duplicate of this bug. ***
*** Bug 386847 has been marked as a duplicate of this bug. ***
*** Bug 366359 has been marked as a duplicate of this bug. ***
*** Bug 370974 has been marked as a duplicate of this bug. ***
*** Bug 378525 has been marked as a duplicate of this bug. ***
*** Bug 382294 has been marked as a duplicate of this bug. ***
*** Bug 389421 has been marked as a duplicate of this bug. ***
*** Bug 382885 has been marked as a duplicate of this bug. ***
*** Bug 405867 has been marked as a duplicate of this bug. ***
*** Bug 430407 has been marked as a duplicate of this bug. ***
*** Bug 435337 has been marked as a duplicate of this bug. ***
*** Bug 440386 has been marked as a duplicate of this bug. ***
*** Bug 440387 has been marked as a duplicate of this bug. ***
*** Bug 467556 has been marked as a duplicate of this bug. ***