[xsd-users] (Windows) mixing debug/release Xerces lib

[Boris Kolpackov]

Hi Greg,

Greg Carter <greg at permedia.ca> writes:

> We have an application that has a plug-in interface, where each plug-in 
> is a separate dll on windows.  We use XML extensively in the interface.  
> It is conceivable that a 3rd party developing a plug-in will be using 
> XSD/xerces.  We designed the interface so that all new/delete of 
> exported objects occurs within the plug-in dll.  This way it doesn't 
> matter if the plug-in is debug while the application calling the plug-in 
> is built in release mode.  However I have noticed that if the plug-in 
> uses a different xerces lib (xerces-c_3_0D.dll vs xerces-c_3_0.dll) then 
> in the parse routine for an XML type we get an access violation.  If I 
> switch the debug plug-in dll build to use xerces-c_3_0.dll, all is 
> fine.

What is the stack trace? Is it memory allocation related? Normally,
when you try to free a memory block by calling a wrong heap, you
get an assertion in VC++ runtime, not access violation.


> Reading the xerces faq I found:
> http://xerces.apache.org/xerces-c/faq-build-2.html#faq-13

Is any of the components in your application linking to the static
VC++ runtime? If they all use DLL runtimes and, as you said, memory
allocation does not cross plugin boundaries, then this shouldn't
be a problem.


> Is XSD generated code calling delete[] directly on the strings allocated 
> by the xerces parser?  Or is this another problem?

In the default configuration (XSD_USE_LCP is not defined), XSD-
generated code does not call any Xerces-C++ code that allocates and
returns strings. When XSD_USE_LCP is defined, XMLString::transcode
is called but then we pass a memory manager to make sure that
allocation and deallocation happens on the same heap. This memory
manager is also used in the call to Base64::decode which allocates
a byte array.

Boris

P.S.: Your email violates rule #2 in the Posting Guidelines:

http://www.codesynthesis.com/support/posting-guidelines.xhtml

While you changed the subject in your reply, it still contains the
wrong In-Reply-To header which breaks threading. See archives for
example (your message is at the bottom):

http://www.codesynthesis.com/pipermail/xsd-users/2009-February/thread.html