Re: [xml] LibXml2 Crash in MultiThreaded Windows



Hi all,

Plz try to create 2 threads or more in a Windows VC++ 20005 Test exe /
Application. 
Put libxml2.dll , iconv.dll , zlib1.dll at runtime folder

Within the thread try to call xmlParseFile(const char* filename) or
xmlParseMemory() API if u intend to read any Xml within threads.
NOTE: These calls are in my Reader / Writer class Ctor

Or call xmlSaveFormatFile() / xmlSaveFile() APIs if u intend to save any
Xml within threads.

My crash occurs exactly when the 2nd thread is calling any of the above
APIs

CRASH Message : Unhandled Exception at XXX .Access Violation Writing
Location yyy

I have used Windows Mutex / Critical Sections & xmlMutex /xmlRMutex(
exposed in Threads.h) , within my ThreadProc but to no avail.

I have tried hard to play with all the possible switches /MT , /MTd ,
/MD , /MDd but could not resolve the crash.

I even made the same application in VC6 environment , but crash occurs
on 2nd Thread.

NOTE : Within my thread I create Reader / Writer object on Stack so it
goes out of scope when the thread fun exits , calls Dtor of Reader /
Writer object , which does 

xmlFreeDoc(m_ptrXMLDoc);
xmlCleanupParser();


I used Xml Memory APIs to check whether the crash is due to any FILE*
issues
In Parsing XML from memory there is no FILE* , but still it crashes on 
xmlParseMemory() when 2nd Thread calls it


Our application has a Server which sends some XML Data to clients using
Sockets , I have used xmlDocDumpFormatMemory() to get the Memory Buffer
& Size of a XML file , then send them  both to the client & use
xmlParseMemory() to parse the XmlBuf send by the Server


Regds,

Lav



-----Original Message-----
From: Daniel Veillard [mailto:veillard redhat com] 
Sent: Tuesday, June 10, 2008 5:28 PM
To: Rob Richards
Cc: Lav Mehrotra; xml gnome org; igor zlatkovic com
Subject: Re: [xml] LibXml2 Crash in MultiThreaded Windows

On Mon, Jun 09, 2008 at 07:56:42AM -0400, Rob Richards wrote:
Also it would be grt if u or Igor can spare some of ur valuable time
&
go thru this blog......


http://blog.kowalczyk.info/archives/2006/08/07/the-missing-msvcr80dll-s
t
ory/

  But there isn't much we can do about this, this means the libc
interfaces
are not standardized on Windows.
 

There is nothing strange about that. It also is a good reason why its 
stressed not to mix where you allocate/de-allocate memory (same with 
file descriptors) when working with dlls. If allocated in dll, make
sure 
you de-allocate from within the dll. If you follow those guidelines,
you 
can successfully use the library with a client compiled with a
different 
run-time.

  Maybe one thing we can try do is minimize the reliance on FILE * . I
would
hope fd integers values might be more portable across implementations
(or at least not lead to crashes). Of course we can't just deprecate
FILE *
based APIs but making sure we don't use them too much internally and
maybe
document the associated problems. I think most of the FILE based APIs
are
about dump or debug output, and with the xmlSave module it should be as
convenient to use Fds .
  For internal use it's maybe the xmlIO.c which could be cleaned up 
a bit, but it's unclear this would really bring much benefits.

Daniel

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard redhat com  | libxml GNOME XML XSLT toolkit
http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/


DISCLAIMER:
This email may contain confidential or privileged information for the intended recipient(s) and the views 
expressed in the same are not necessarily the views of Zensar Technologies Ltd. If you are not the intended 
recipient or have received this e-mail by error, its use is strictly prohibited, please delete the e-mail and 
notify the sender. Zensar Technologies Ltd. does not accept any liability for virus infected mails. 



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