Start any mozilla application from the command line and you will see ***MEMORY-WARNING***: thunderbird-bin[15732]: GSlice: g_thread_init() must be called before all other GLib functions; memory corruption due to late invocatio n of g_thread_init() has been detected; this program is likely to crash, leak or unexpectedly abort soon... Though I didn't observe instability of mozilla-firefox or thunderbird yet because of this I see that people in the forums are concerned particularly about ... unexpectedly abort soon... see, e.g. http://forums.gentoo.org/posting.php?mode=quote&p=4054321 http://forums.gentoo.org/posting.php&mode=quote&p=4061286 I googled around and found an easy fix that was once upon a time applied to mozilla-firefox on freebsd (and was retracted later). These fixes were not for the problem I mention, however they work also for this problem. There was also an upstream bug filed but it was never checked-in. Who knows why! Here are the original sources http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/ports/www/firefox/files/Attic/patch-toolkit_xre_nsAppRunner.cpp?rev=1.1;content-type=text%2Fplain;hideattic=0 http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/ports/www/firefox/files/Attic/patch-browser_app_Makefile.in?rev=1.1;content-type=text%2Fplain;hideattic=0;sortby=date These are for firefox I'll attach them in a moment and also the modified ones for mozilla-thunderbird and seamonkey. I will try to revive the mozilla bug to get them in upstream. My last concern: I am not a specialist in memory threading, someone who is more involved is very wellcomed to speak up, as maybe there is a good reason, why these patches never made it. Reproducible: Always Expected Results: mozilla apps should silently start from the command line
Created attachment 120311 [details, diff] g_thread_init mozilla-firefox for mozilla-firefox
Created attachment 120312 [details, diff] g_thread_init mozilla-thunderbird these patches should work also on 1.5 versions and sorry about the forum links, the second one should be https://forums.gentoo.org/posting.php?mode=quote&p=4054321
and sorry about the forum links, the second one should be http://forums.gentoo.org/posting.php?mode=quote&p=4061286 Didn't find a direct link to the respective posts.
Created attachment 120319 [details, diff] g_thread_init seamonkey modified to fit the seamonkey sources
forgot to post the original mozilla bug https://bugzilla.mozilla.org/show_bug.cgi?id=247204 Note the patch posted in this patch differs substantially from what was once used in freebsd.
Investigating this a little bit further I see the GSLice g_thread_init error message only with the self-compiled versions, but NOT with pre-compiled mozilla-firefox-bin or sunbird-bin. The question is, if any of our patches for mozilla-firefox and friends triggers this.
I don't get that error...
Do you have the gnome use-flag enabled, maybe?
(In reply to comment #8) > Do you have the gnome use-flag enabled, maybe? > yes, but disabling it doesn't help (In reply to comment #7) > I don't get that error... > Ok, finally I found out what is going on The warning output comes from glib-2.13 and will be probably also present in 2.14. Now, you may be tempted to resolve this bug as upstream or later, however that earlier glib versions do not show this warning doesn't mean that the gthreads are initialized correctly. "it has been claimed in a number of places that adding the above warning is breaking glib ABI. this is not the case, because the requirement has always been there, it just wasn't as strictly enforced." Tim Janik in this thread http://mail.gnome.org/archives/gtk-devel-list/2007-January/msg00005.html I'm just in the process to get a similar patch into the mozilla-trunk see https://bugzilla.mozilla.org/show_bug.cgi?id=247204 It has already r+/sr+ but then I found that addl patch would be needed to build static. So, maybe you want to wait until its decided mozilla upstream if its finally correct....
As of version glib-2.13.7 gslice can now cope with being called after a thread started actually. So, the warning was removed and will never be seen with mozilla or other products.
