Re: [xml] Questions about libxml as a DLL on win32.

The issue you're describing isn't 100% accurate (atleast from my
experience).  I've heard about these types of boundaries, but if you set
things up correctly, they become a non-issue.

The main problem arrises when the DLL uses a difference set of run-time
libraries than the executable.  Then memory gets allocated one way, then
deallocated another.  For instance, if your DLL is linked to the C Runtime
statically, but the EXE is linked dynamically, these sorts of problems show
up.  However, if all projects are linked the same way (ie. all are using
Multithread DLL and/or Debug Multithread DLL) and all projects have the same
byte alignment, then the problem disappears.

Atleast, this is the evidence that I've witnessed in my own developments.
I've successfully linked libxml as a DLL to my applications without problems
by following these guidelines.


----- Original Message -----
From: "Steven M Cherry" <smc cherrys org>
To: <xml gnome org>
Sent: Tuesday, October 09, 2001 12:35 PM
Subject: [xml] Questions about libxml as a DLL on win32.

Hello All,

I use libxml on linux, and win32.  I've got some questions about problems
that I've run into (and fixed on my own) with the library being used
as a DLL on the win32 platform.

The xmlFree function is defined as a function pointer that is set at
runtime to dynamically allow different deallocation routines to be used
to allow for maximum flexibility.  However, in the case of a DLL on win32
memory allocation and deallocation is a /very/ sensitive issue.

Basically a DLL has a boundary layer around it that enforces memory
allocation and deallocations to happen on the same side of the boundary.
Memory can be shared and read and written across this boundary, but
if it is allocated on one side of the boundary, it must be freed on the
same side of the boundary.

The function pointer nature of xmlFree ends up violating this memory
boundary layer of the DLL.  What ends up happening is that the xmlFree
pointer is initialized inside the DLL and therefore points to the
routine that is valid for the DLL.  However, when my code calls xmlFree
to free up strings allocated by libxml (xmlGetProp mainly) I get seg
faults (the windows equivalent) because my code is not allowed to execute
the DLL's memory deallocation routines.

So basically libxml has exported a pointer to an operating system
set of code that is only allowed to be used by the libxml DLL itself.

With this being the situation, I can't call xmlFree at all to free up
the memory allocated by libxml.

xmlFreeDoc works just fine, because it's actually a real function that
used xmlFree internally to free up the memory.  At that point, xmlFree
is being invoked on the correct side of the DLL boundary and everything
works just fine.

What I did to solve this problem is to re-define xmlFree as a real live
function in the libxml DLL and it just calls free();  This was not a big
deal for me, and then I just re-compiled the DLL for win32 and everything
works fine.

I'd like to get people's comments or suggestions on this issue because
I still might be missing something.  Like I said, it works now, and I
don't get any memory leaks in my app anymore.  But other viewpoints are
also welcome.

I use NT 4.0, and Win2000.  I use the Borland 5.5 free compiler to do
all of my NT development.  Which also, btw, means that I've ported libxml
to the borland 5.5 compiler environment to build the DLL.  If anybody's
interested, I can send my diff's to the list.



== Steven M. Cherry                            smc cherrys org  ==
==         ==

xml mailing list
xml gnome org

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