Description of problem: Some programs crash (gnumeric, e.g.), others leave error messages when they are closed (firefox 2 and opera 9.21, e.g.): 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 Version-Release number of selected component (if applicable): I'm still running Fedora 6.93 (rawhide) but last night 133 updates and 6 installs were done on this machine and it is only after these updates that these errors began. Using kernel 3175 in order to avoid softirq errors of 3190 & 3194. Sounds like a Gnome 2.14 issue but I don't know which part of Gnome it might be. How reproducible: Occurs every time I use gnumeric, firefox 2.0.0.3, or opera 9.21 (shared qt). Gnumeric crashes every time. The browsers do not crash but leave plenty of error messages behind when closed. Steps to Reproduce: 1. 2. 3. Actual results: Program crashes or error messages about memory corruption. Expected results: Additional info:
gnome-common is a package that helps developers of gnome applications write their Makefile and configure scripts. Reassigning this bug to gnumeric as you seem to have a repeatable crasher with that application.
I know it will be hard to track this down, since over 130 updates were loaded last night (and these errors started thereafter). The Opera 9.21 error turned out to be a problem using gcj (java). But firefox 2.0.0.3 and gnumeric-1.6.3-7.fc8 both produce memory warnings immediately when the programs are called from a command prompt in an xterm window. Here is the error message from gnumeric: ***MEMORY-WARNING***: gnumeric[5370]: 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... And here it is from firefox: ***MEMORY-WARNING***: firefox-bin[5168]: 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... Both of these error messages display even before the respective window comes up, so I doubt either program is the cause. Maybe a library they both access? Could gtk be involved? Sorry, that's all I can give you.
Notice that you updated to gnumeric-1.6.3-7.fc8 iow you managed to hit a mirror which is already carrying the first development work for Fedora 8, including a new beta glib2 release: glib2-2.13.2-1.fc8 By updating glib2 to this release I managed to reproduce this problem too, changing component to glib2 and reassigning to mclasen p.s. Toshio, I understand that this is not a gnome-common bug, but next time please try to find the correct component instead of reassigning it to just one of the other components mentioned in the description.
Created attachment 155908 [details] ldd output of broken home-built Gaim Whatever broke in last night's updates, it's one of these libraries....
Confirmed it's a glib2 rather than gnumeric/gnome. A self-built Gaim broke as well....
Created attachment 156545 [details] patch to compat-wxGTK26 to make this problem go away, sort of I was having the same problem with audacity. The attached patch to compat-wxGTK26 made the problem go away. Well, sort of. It got rid of the message about g_thread_init being called too late, and audacity managed to run for longer before crashing, but it was still crashing. I got it to stop crashing by running it with MALLOC_CHECK_ set to 0. I therefore suspect that there are memory corruption problems in either glib2 or audacity, but I wasn't able to isolate them.
> I therefore suspect that there are memory corruption problems in > either glib2 or audacity See backtraces in bug 244542. Since the glib2 upgrade, Audacity crashes inside glib2 in various ways, regardless of whether it's built against wxGTK 2.8 or 2.6.
The warning has been removed in glib2 2.13.7, and the possible problem it was indicating has been fixed. If you are seeing crashes with 2.13.7, please file separate bugs with stacktraces.