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 564723 - libxml2 lead to crash when it dynamically loaded into multi-thread application
libxml2 lead to crash when it dynamically loaded into multi-thread application
Status: RESOLVED FIXED
Product: libxml2
Classification: Platform
Component: general
2.6.x
Other Linux
: Normal normal
: ---
Assigned To: Daniel Veillard
libxml QA maintainers
Depends on:
Blocks:
 
 
Reported: 2008-12-16 12:09 UTC by Alex Ott
Modified: 2012-01-18 15:30 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement


Attachments
Proposed patch for fix this problem (1.42 KB, patch)
2008-12-16 12:15 UTC, Alex Ott
none Details | Review

Description Alex Ott 2008-12-16 12:09:17 UTC
We have a multithread application, that loads some plugins dynamically. One of the plugins use libxml2 for data processing, and often crashes. During investigations, i found that libxml2 causes this crash, as it non properly use pthread library - it register global variable with pthread_key_create and pass cleanup procedure for this variable.
But libxml2 doesn't unregister this variable with pthread_key_delete, so when thread in finished, and library is already unloaded, then glibc try to call cleanup procedure, and crash with following backtrace:

  • #0 ??
  • #1 __nptl_deallocate_tsd
    at pthread_create.c line 153
  • #2 start_thread
    at pthread_create.c line 268
  • #3 clone
    from /lib/libc.so.6

Comment 1 Alex Ott 2008-12-16 12:15:38 UTC
Created attachment 124788 [details] [review]
Proposed patch for fix this problem

This patch should fix described problem. At least we don't observe it already
Comment 2 Daniel Veillard 2009-01-18 15:43:12 UTC
Okay, I think I understand and overall agree with the patch, but
you still need to check for pthread_key_delete not being null
(and the key too) before calling it.

  I commited that fix,

   thanks !

Daniel
Comment 3 boicotinho 2012-01-18 15:30:52 UTC
You need to reset once_control to an uninitialized state:

once_control = PTHREAD_ONCE_INIT;

otherwise xmlGetGlobalState() will not call xmlOnceInit() which again will not allocate a new key with pthread_key_create(). 

Thus when xmlCleanUpParser() is called for the 2nd time, it will delete the old key (from first call to pthread_key_create()), which now could potentially be owned by some other code.

This bug showed up for me at work.