Re: Minimal program crashes, depending on linker script

[Paul Pluzhnikov]

Andre Poenitz <poenitz@htwm.de> writes:

>> Win32 also effectively uses the same model,
>> resulting in a whole slew of complications, such as: you shalt not
>> free() memory in FOO.DLL, if that memory was malloc()ed in BAR.DLL
>> (unless both were linked with /MD flag).
>
> I thought the reason for that was that each DLL uses its own heap,

When a DLL is linked without /MD, it gets a copy of LIBC.LIB (or
one of its variants, e.g. LIBCMT.LIB or LIBCMTD.LIB) statically
bound into it. A program that uses two such DLLs, gets two separate,
possibly different, and completely isolated copies of malloc()
implementation.

Each copy, upon DLL initialization, creates its own private heap (via
HeapCreate()), and then allocates large chunks from that private
heap (via HeapAlloc()) and "chops" it into smaller chunks handed
out by malloc.

> so malloc() in one and free() in another is problematic as they access
> different heaps.

That's correct: malloc() in one, free() in another, and you corrupt
all kinds of LIBC internal structures.

> But I think I see the issues are related.

They are the direct result of Microsoft's decision to put HeapAlloc()
into (always shared) KERNEL32 and to put malloc()/free() into
sometimes shared LIBC*.LIB, and of the "every DLL to itself"
linking model.

Cheers,
-- 
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.