Re: [xml] LibXml2 Crash in MultiThreaded Windows
- From: "Lav Mehrotra" <l mehrotra zensar com>
- To: <veillard redhat com>, "Rob Richards" <rrichards ctindustries net>
- Cc: xml gnome org, igor zlatkovic com
- Subject: Re: [xml] LibXml2 Crash in MultiThreaded Windows
- Date: Tue, 10 Jun 2008 18:35:10 +0530
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]