Re: [xml] xmlDocDump crashing on windows



<Igor changed the subject line to fit the thread>

Eric Zurcher csiro au wrote:
Enno,

I guess I'm not surprised that you get a crash in this context. If I
understand things correctly, when the application and the libxml2 DLL are
using different run-time libraries, they're each going to have their own
"stdout", with their own file-locking mechanism in the multi-threaded case.
The DLL is going to have trouble accessing a "stdout" which is under the
control of the main application's run-time.
The situation is a bit like trying to use malloc in the main application,
then passing the resulting pointer to a DLL and expecting it to be able to
free it. It can work if the runtime is in common, but will fail otherwise.

Perhaps it might be useful if libxml2 exported its version of the standard
IO units (e.g, xmlStdIn, xmlStdOut, xmlStdErr), so that the application
could use them in API functions that
make use of a FILE* as an argument. I suppose there could even be an
xmlFOpen and xmlFClose.

Does that make sense to anyone else, or am I way off base here?

How would you declare these? With stdin and friends I guess it would be okay to have functions which return the desired file descriptor, but what about malloc/free?

In a production version, memory functions are macros which resolve to malloc/free. These will always be tied to the runtime of any module at compilation time. The only solution for this is to remove macros and use functions which have their implementation in libxml and do nothing else but delegating the call to malloc/free.

For one, this would break the binary compatibility. For two, this would introduce an additional function call per allocation. How much impact on the performance would that give? Note that this will propagate to everything that uses libxml, ie libxslt, xmlsec, GNOME...

In every case, people will eat our hearts if we break the ABI, unless we go to libxml3 and do it there. Also, if the performance degradation is more than three nanoseconds, noone will want to have it.

It certainly would make sense to isolate all the differences between the underlying runtimes and handle them in one place, in a generic way, so that everyone can use what she pleases and never get a problem. I just don't see a way to do it. Everything I can think of breaks the ABI.

Ciao,
Igor




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