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

["FiSTY" <fisty fisty com>]

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.

...Matt

----- 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
deallocation
> 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
protected
> 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.
>
> Thanks,
>
> Steven
>
> --
> ==================================================================
> == Steven M. Cherry                            smc cherrys org  ==
> ==                 http://family.cherrys.org/steven/index.html  ==
> ==================================================================
>
> _______________________________________________
> xml mailing list
> xml gnome org
> http://mail.gnome.org/mailman/listinfo/xml