Summary: | dev-libs/glib-2.24.1: SIGSEGV due to uninitialized threads in call from media-video/totem-2.30.0-r1 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Martin von Gagern <Martin.vGagern> |
Component: | [OLD] GNOME | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://bugzilla.gnome.org/show_bug.cgi?id=621771 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 313037 |
Description
Martin von Gagern
2010-06-16 09:27:21 UTC
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). |