Re: [xml] LibXml2 Crash in MultiThreaded Windows

[Roumen Petrov <bugtrack roumenpetrov info>]

Igor Zlatkovic wrote:
> 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

Function malloc may not crash itself but if is a call to realloc, I 
expect same as for free.

Lan,
Please, could you search for article "Potential Errors Passing CRT 
Objects Across DLL Boundaries".

Roumen