Re: [xml] libxml and threads

On Wed, Feb 23, 2005 at 09:54:27AM +0100, Massimo Cafaro wrote:
Everything works fine, but I have found that many memory leaks are 
associated with libxml2 APIs. The leaks are small, but they are so many 
that this is a serious problem. Now, I strongly believe that it is 
entirely my fault, but I need to understand exactly how to use libxml2 
in threaded applications. 

Leak: 0x0110f690  size=48       string 'MUTX' 
        Call stack: [thread 280c000]: | 0x0 | _pthread_body | 
thread_starter | provider_thr | grelc_get_sql | 
xmlSAXParseMemoryWithData | xmlCreateMemoryParserCtxt | 
xmlNewParserCtxt | xmlInitParserCtxt | xmlDefaultSAXHandlerInit | 
__xmlDefaultSAXHandler | xmlGetGlobalState | xmlNewGlobalState | 
xmlInitializeGlobalState | xmlInitGlobals | xmlNewMutex | malloc | 

  The threads code is the only one which can legally do direct malloc()
without using xmlMalloc(), so it's among the memory use I won't detect
leaks in regression tests.

It looks like a mutex object is never deallocated. 

The code looks like 

xmlDocPtr doc; 

doc = xmlParseMemory (docname, strlen(docname) - 1); 

Is this the way to write this kind of code? I was not able to find any 
example of threaded code. I have found some APIs for dealing with 
threads tough. 

  You must make sure you made the call to the library initialization
xmlInitParser() before any call to the library in the main thread,
and make sure you never call xmlParserCleanup() unless nothing will
ever use the library or library produced data.

mutex object and call related lock/unlock functions). The libxml2 I am 
using is the latest one officially released on January. I am working on 
Mac oS X 10.3.8 

  I don't use Mac oS X, I know Apple people now use libxml2 and they
should be able to track down that problem better than me. It is a
thread local storage problem and is usually platform specific. The
memory you're pointed out should be freed by xmlCleanupGlobals() 
which is called by xmlCleanupParser() and to be released only once
in the whole application lifetime. I can't see how this specific call
can lead to " many memory leaks".
  I.e. I looked at your problems but don't see how this could lead to
what you are describing.


Daniel Veillard      | Red Hat Desktop team
veillard redhat com  | libxml GNOME XML XSLT toolkit | Rpmfind RPM search engine

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]