After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 625851 - segfault due to weak pthread symbols
segfault due to weak pthread symbols
Status: RESOLVED FIXED
Product: libxml2
Classification: Platform
Component: general
git master
Other Linux
: Normal normal
: ---
Assigned To: Daniel Veillard
libxml QA maintainers
Depends on:
Blocks:
 
 
Reported: 2010-08-02 16:22 UTC by Mike Hommey
Modified: 2010-10-15 17:52 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
Patch (1.20 KB, patch)
2010-08-02 16:22 UTC, Mike Hommey 		none Details | Review

Description Mike Hommey 2010-08-02 16:22:38 UTC 
Created attachment 166996 [details] [review]
Patch

this is a rehash of bug 609926, because I can't reopen that one. The real issue of that bug, which is only revealed when building statically, is twofold.

First, there seems to be a problem with how gcc and ld treat libpthread and libxml2's setting of weak symbols, but that's another story.

Second, in xmlInitParser, both __xmlGlobalInitMutexLock and xmlInitGlobals are called before xmlInitThreads, and both use pthread symbols.  __xmlGlobalInitMutexLock does so directly, without checking if the symbol exists, and xmlInitGlobals calls xmlNewMutex, which correctly depends on libxml_is_threaded... except libxml_is_threaded is still -1 by then... And again, when releasing the global mutex in __xmlGlobalInitMutexUnlock, the pthread function is called directly.

The patch I'm attaching fixes that while keeping weak symbols and not affecting libxml2's behaviour regarding threads.
Comment 1 Pacho Ramos 2010-08-31 12:52:28 UTC 
Also affects to Gentoo users:
http://bugs.gentoo.org/show_bug.cgi?id=306479
Comment 2 Daniel Veillard 2010-10-15 17:52:32 UTC 
Okay that fix is a bit more complex but the reordering should be fine.
The risks sounds minimal compared to a segfault, so fine,

  I pushed the patch, 

   thanks a lot !

Daniel