Nicholas Clark writes: > On Mon, Nov 19, 2007 at 06:01:17PM -0500, Michael Poole wrote: > >> Alternatively, the system allocator(s) is/are Too Damn Broken to work >> reliably in the various permutations of DLL Hell -- q.v. Windows -- >> and calling free() on a pointer that another DLL malloc()'ed can crash >> your application or silently corrupt the heap. (I wish I were joking >> about this.) > > Is this documented behaviour?
The documentation used to warn against doing things that would trigger it; the Visual C++.NET documentation doesn't mention it anywhere I can find. It is a side effect of the multiple heaps you get when you link your DLL against a static version of Microsoft's C runtime (for example, to avoid locking your DLL's user into a certain version of the C runtime DLL), or if your DLL links against a different variant of the C runtime DLL than the application. When you allocate memory from one heap and try to free it in another heap, the debug variant of the runtime library throws an assertion failure. It's been a while since I had to deal with Windows, but I believe the release versions of the runtime continue with silently corrupted heaps. (I suspect this is part of why third-party Windows libraries ship with both debug and non-debug variants: linking against the multi-threaded DLL runtime is an easy workaround, but you're still left choosing between the debug and release options of that, and they use different heaps.) Michael
