Re: [xml] LibXml2 Crash in MultiThreaded Windows

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.


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