Re: heap corruption

Russell Yanofsky wrote:

>"SteveKing" <steveking@gmx.ch> wrote in message
>news:008401c2dd06$26e10aa0$3140d0c2@catv64254...
>
>
>>[...]
>>MSVCRT.dll and MSVCR70.dll
>>in the same process space lead to severe heap
>>corruption (see posts about the berkeley db
>>libs built with VC6 and VS.NET).
>>
>>
>
>This isn't generally true. The only situation where having two CRTs will
>lead to heap corruption is if a pointer malloc()ed in one DLL is free()d in
>another. Any DLL interface that is meant to be portable to different
>compilers (i.e. Visual C++, Borland, Metrowerks, Cygwin, Visual Basic) won't
>pass pointers back and forth this way. I'd be surprised if apr-iconv did
>this.
>
It does, actually.

> Doesn't apache code use its own memory management instead of malloc
>and free?
>
>
Yes, but APR's memory management is based on malloc and free in the end.

That said, I don't think it would be very hard to change APR to use
native Win32 functions (due to the nature of APR's pool, VirtualAlloc
would probably be best), nor teach apr-iconv to stop using malloc and
shift entirely to pools.

-- 
Brane Čibej   <brane_at_xbc.nu>   http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org