Re: [xml] LibXml2 Crash in MultiThreaded Windows

[Igor Zlatkovic <igor zlatkovic com>]

On 09/06/08 09:04, Lav Mehrotra wrote:
> I used /MT ( Static Link to C Runtime ) throughout in the Wrapper as 
> well as my client ( statically linking to my Wrapper Lib ).
>
> I finally got hold of all the .C source files of LibXml2 & compiled them 
> in VS 2005  as well as old VC6 & changed accordingly all my Wrapper & 
> Client to VS 2005 or VC 6 projects
>
> But the problem remained.

Of course. You'll have to compile zlib and iconv using these same 
settings, or turn them off.

> I know original LibXml2.dll , iconv.dll & zlib1.dll were all built in 
> the old VC6 Environment.

Wrong, it is the compiler which comes with the DDK and that one is 
tweaked so it links to the system C runtime (msvcrt.dll) and not a VS 
product runtime (msvcrXX.dll). This is done in order to, while using a 
newer compiler, still be able to:

1. Run on every system regardless whether one of the several Visual 
Studio product runtimes exists on the system.

2. Be compatible with vast majority of other open source software which 
is made using GCC (mingw edition), which can only link to the system 
runtime for licencing reasons.

I guess it would be best if I would drop Microsoft's compiler and use 
GCC to make the binaries. I want to do this for some time now.

> It would be nice , if a LibXml2 VS 2005 Solution project is provided 
> along with the source code as Xerces guys have done .

Such solution project does not exist. I don't have the Visual Studio 
IDE, just the naked compiler. The makefiles and scripts for 
configuration are all I have and they are in the win32 subdirectory of 
the source tree.

> ( In VS2005 Environment Crash Occurs in msvcr80.dll  in void * __cdecl 
> _malloc_base (size_t size) Line 154 ââ..
> //  allocate memory block
> res = _heap_alloc(size);  )

That is very odd. That is the place where malloc is implemented in the 
runtime. This should not crash. Either you have the wrong location or 
you have a larger problem here.

free() crashes when you pass it a pointer to the memory allocated in a 
different runtime. File read/write/seek/close operations crash when you 
give them a FILE* pointer created in a different runtime. Hell breaks 
loose when you share stdin, stdout and similars between runtimes. But 
malloc should not crash. It gets just a plain integer, the number of 
bytes to allocate and that should succeed unless you mix 32-bit and 
64-bit runtimes.

Please double check your environment, this does not look healthy.

Ciao,
Igor