GNOME Bugzilla – Bug 510547
Epiphany/Webkit fails to start due to initializing threads twice
Last modified: 2008-01-20 12:41:45 UTC
I built epiphany/webkit for the first time via jhbuild, but it wouldn't start and gave this error on the commandline: GThread-ERROR **: GThread system may only be initialized once. It appears that g_thread_init() is being called in a WebKit global constructor somewhere, which happens before main(). So when Epiphany initializes threads, it aborts.
Created attachment 103184 [details] [review] Check whether threads are initialized before calling g_thread_init() I'm not sure if this is necessarily the correct fix, but it seems to fix things for me.
(In reply to comment #0) > I built epiphany/webkit for the first time via jhbuild, but it wouldn't start > and gave this error on the commandline: > > GThread-ERROR **: GThread system may only be initialized once. > > It appears that g_thread_init() is being called in a WebKit global constructor > somewhere, which happens before main(). So when Epiphany initializes threads, > it aborts. > I don't think it's possible that the webkit constructor is called befare our main :) Are you sure it comes from ephy-main? Could you break on g_log and see who's calling it?
FWIW, WebKit checks before initializing threads. Odd.
Oh, in c++ it's quite possible for a constructor to run before main if it's a global object. Here is the backtrace from g_log: Breakpoint 2, IA__g_log (log_domain=0xb61e6868 "GThread", log_level=G_LOG_LEVEL_ERROR, format=0xb61e6ee4 "GThread system may only be initialized once.") at gmessages.c:516 516 va_start (args, format); (gdb) bt
+ Trace 185965
I built webkit with --enable-video, so it looks like WebKit is initializing some gstreamer stuff in a global constructor which also initializes threads. Hope that helps
Madness! :) Ok, then we should definitely guard the thread initialization in our main (it's probably a good idea *anyway*). chpe?
I think webkit shouldn't have global constructors. Where is that code in webkit, exactly?
Well, I would agree that it's slightly questionable for webkit to be initializing it in a global constructor, which is why I said I wasn't sure if it was the right fix or not. I took a quick look through the webkit source to try to find out where it's happening, but I'm not familiar with webkit code, and I couldn't spot it immediately. Even so, my patch doesn't seem like it would do any harm in any case. It would make things a bit more robust, but I suppose it would hide issues like this (I don't know whether you'd consider that a good thing or not).
Also, just to avoid confusion: if you didn't notice, my backtrace above is oddly corrupted. It appears that I copy/pasted the stack track twice and the second time I pasted it into the middle of the first one. The correct trace is: (init=0x0) at gthread-impl.c:293 293 { (gdb) bt
+ Trace 185975
It's happening due to the use of GST_PLUGIN_DEFINE_STATIC in VideoSinkGStreamer.cpp. This GStreamer macro expands out to generating a constructor function that calls into _gst_plugin_register_static, which somehow results in g_thread_init being called. We should be able to fix this in WebKit by not using the GST_PLUGIN_DEFINE_STATIC macro, and instead deferring the operation until first use.
Filed in WebKit's Bugzilla as <http://bugs.webkit.org/show_bug.cgi?id=16944>.
This appears to have been caused by a recent change in GStreamer. Since static initializers are bad anyway, I'm working on a fix in WebKit. http://bugs.webkit.org/show_bug.cgi?id=16944
Fix landed in WebKit r29675/r29676.
Thanks guys. I guess we can close this now, as chpe does not want to add the check in our main.