Since my latest world update, running /usr/kde/3.5/bin/nspluginscan as provided by the kde-base/nsplugins-3.5.10-r1 package from kde-sunset opens four crash handler windows. I know that you don't support KDE 3.5, but I've investigated the issue, and I expect it might crop up in other places as well, so I'm filing this bug here for reference and as a heads up. The crash takes this form: [Thread debugging using libthread_db enabled] Traceback (most recent call last): File "/usr/share/gdb/auto-load/usr/lib64/libgobject-2.0.so.0.2400.1-gdb.py", line 9, in <module> from gobject import register File "/usr/share/glib-2.0/gdb/gobject.py", line 3, in <module> import gdb.backtrace ImportError: No module named backtrace [KCrash handler] #5 0x0000000000000000 in ?? () #6 0x00007f871ad17afc in IA__g_content_type_get_description (type= 0x7f871b20f87f "application/ogg") at gcontenttype.c:700 #7 0x00007f871b20ac33 in NP_GetMIMEDescription () at totemPluginGlue.cpp:361 #8 0x0000000000405009 in tryCheck(int, QString const&) () #9 0x000000000040673a in scanDirectory(QString, QStringList&, QTextStream&) () #10 0x0000000000407f47 in main () Notice that the top stack frame is a NULL pointer. That's because the function tries to lock a mutex, but the thread system of glib hasn't been properly initialized yet. In the past, an uninitialized thread system would cause the mutex functions to become no-ops, but since upstream commit 94b8613b5ffefadb5c82424bd1f3083ff11fa811 these functions simply assume that the threads system has been properly initialized. The best reference on this change might be the upstream RFE https://bugzilla.gnome.org/show_bug.cgi?id=606775 where you will also find patches of the commits I reference here. Judging from the ldd output it would seem that nspluginscan itself doesn't use glib, but the media-video/totem-2.30.0-r1 plugin on the other hand seems to do. In that case I guess it would be totem's responsibility to ensure the threads system is properly initialized. Perhaps by calling g_type_init or g_thread_init. As calling the threads init repeatedly used to be officially illegal in past versions, maybe the call should be conditiond like the one inside g_type_init from commit fa2bced1f30f93443ef43ce8b5b1e437cd07168c is. Or we could simply rely on the de-facto behaviour or a recent enough version, and call g_thread_init unconditionally. Or maybe there is yet another initialization function that libs should call? I don't know enough about glib to decide which of these alternatives would be most advisable. I assume that other libraries might be using gio or gobject without proper initialization as well, and will therefore be affected by this same bug.
You should open an upstream bug report against totem for this Thanks
(In reply to comment #1) > You should open an upstream bug report against totem for this Just filed https://bugzilla.gnome.org/show_bug.cgi?id=621771
Thanks a lot
Upstream has committed a patch: http://bugzilla-attachments.gnome.org/attachment.cgi?id=163824 We probably should apply it conditionally, based on >=glib-2.24, as upstream comments indicate they won't apply that patch to versions intended for glib-2.22.
Conditionally doesn't work. It keeps it broken on systems that build totem against older glib, and then afterwards upgrade glib without rebuilding totem (nothing typically would require or indicate a need for that, glib is fully backwards compatible). The point of the upstream comment comes from the fact that only since glib-2.24 g_type_init started initializing the thread system as well per http://library.gnome.org/devel/gobject/stable/gobject-Type-Information.html#g-type-init So it's safe to apply this always. How to fix it for glib-2.22 is a different question, as g_thread_init is quite complicated.
(In reply to comment #5) > So it's safe to apply this always. I agree, https://bugzilla.gnome.org/show_bug.cgi?id=606775#c8 says as much. > How to fix it for glib-2.22 is a different > question, as g_thread_init is quite complicated. But for glib-2.22, the code was happy to work with an uninitialized threads system. Therefore problems with 2.22 would only occur if the code was executed from a multi-threaded non-glib application. I'd guess nspluginscan is single-threaded, so that shouldn't be affected. And upstream doesn't seem to consider totem-2.30 + glib-2.22 broken, at least not enough to warrant fixing. If someone knows an affected package, or wants to address this even without an actual manifestation of the bug, how abou replicating the initialization code from current g_type_init? I'm not sure whether all required preprocessor macros will be in place, though.
(In reply to comment #6) > how about replicating the initialization code from current g_type_init? I mean these four lines from commit fa2bced1f30f93443ef43ce8b5b1e437cd07168c: #ifdef G_THREADS_ENABLED if (!g_thread_get_initialized()) g_thread_init (NULL); #endif
+*totem-2.30.2 (08 Jul 2010) + + 08 Jul 2010; Pacho Ramos <pacho@gentoo.org> +totem-2.30.2.ebuild, + +files/totem-2.30.2-init-gtype.patch, + +files/totem-2.30.2-mp2t-support.patch, + +files/totem-2.30.2-webm-support.patch: + Version bump with lots of fixes, also include upstream patch to solve + crash reported in bug #324237 (by Martin von Gagern).
