Andre Poenitz <[EMAIL PROTECTED]> 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. _______________________________________________ help-gplusplus mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-gplusplus
