GNOME Bugzilla – Bug 305913
[PATCH] hash.c functions not protected again multi-threading issues
Last modified: 2009-08-14 07:05:32 UTC
Steps to reproduce: 1. Write a function that loads an XSLT Stylesheet 2. Call this function from 2 threads concurrently 3. Both threads will call at some point xmlHashUpdateEntry3 with the same parameters (see stack) which will try to xmlFree() the same bloc. Stack trace: xsltFreeExtElement (ext=0x059af718) xmlHashUpdateEntry3 (table=0x01962d08, name="document", name2="http://www.jclark.com/xt", name3=NULL, ...) xmlHashUpdateEntry2 (...) xsltRegisterExtModuleElement (name="document", URI="http://www.jclark.com/xt",...) xsltRegisterAllExtras () xsltInit () xsltNewStylesheet () xsltParseStylesheetImportedDoc () xsltParseStylesheetDoc () xsltParseStylesheetFile (...) Other information: As far as I can see, the xmlHashTable structures managed by hash.c are not protected in case of concurrent access by several threads. This is the case of the hash table used by libxslt for example (crash case, the static table xsltElementsHash) but I think that it is a general problem. In this specific case, both threads want to set the same slot (name="document", name2 = "http://www.jclark.com/xt"), which results in freeing twice the content of this slot if the thread switching occurs during xmlFree. However I think that the hash table structures should be protected with a mutex (xmlRMutex for example ?) during the execution of most the functions of hash.c because any concurrent access to the same hash table could corrupt this table.
Created attachment 47125 [details] [review] Patched hash.c, 1.30 with mutexes I made this patch to fix the bug quickly as it was blocking for me, I tested it only in the context of my project (mostly SAX and XSLT processing in multithreaded environment).
Isn't it the caller's responsibility to synchronize access to the hash?
In general libxml2 and libxslt garantee that there is no concurent modification, I'm surprized it happened in their context. I didn't want to apply the patch without first making a check about the speed impact of it, so this has been pending. Daniel
The real bug is that in libxslt/extensions.c xsltElementsHash is a global variable which is shared between transformations. Its access should then be synchronized using a libxml2 xmlMutex . It's a bug, but I think making hash table concurrent is the wrong way to fix this. I will look at this, Daniel
Okay I finally fixed the libxslt reentrancy problem around the global variables used in extensions. I think this fixes the issue found here. Daniel