Re: [Mingw-users] CRT lib: potential memory leakage
- Date: Mon, 8 May 2017 03:08:40 +0200
- From: Emanuel Falkenauer <E.Falkenauer@xxxxxxxxxxxxxxxxx>
- Subject: Re: [Mingw-users] CRT lib: potential memory leakage
> A DLL cannot EXIT, AFAIK, it can only be unloaded.
Sure, that's what I meant (sorry for the sloppy term).
> When it is
> unloaded, all of its memory is released.
NOT sure, obviously (in particular: see below).
> I do agree that code that will run in a DLL should free memory it
> allocates, because a DLL might not be unloaded when the program using
> it exits.
, the DLL is always "removed from the address space of the current
process" - the reference says nothing as to the possibility of not
unloading due to memory leaks.
> But that has nothing to do with the issue which started
> this thread, which was about memory allocated by a _program_ and
> freeing that memory right before the program exits.
Agreed - but the more general conclusion people might get from your
initial comment could well be "bah, don't bother with leaks in your
programs: everything that was allocated will eventually be freed on exit
anyway" - which is definitely not always the case according to our
> IOW, programs and DLLs have different requirements in this regard, and
> thus practice that is good for programs might not be good for DLLs
> (and vice versa).
IMHO it's ALWAYS a good practice to free everything you allocated. One
Big Classic we experienced a zillion times is to realize that a whole
program can be used as a sub-routine in a "bigger scheme"... e.g. as a
function inside a DLL. At that point, any leaks that were left in the
original program under the excuse of "the OS will clean up after you"
will clearly become pretty dangerous (and good luck finding it all in a
code written by somebody else ten years ago!).
>> Once again then: is there a fundamental difference between a malloc
>> called by the parent process (say an .exe) and a malloc called inside a
> Yes, there is, see above.
Nope, there isn't - not the one you mention that is: unloading a DLL and
returning to the OS all memory it allocated during its use are two
wholly different issues.
Note the mention in that reference saying
"Before unloading a library module, the system enables the module to
detach from the process by calling the module's DllMain function, if it
has one, with the DLL_PROCESS_DETACH value. Doing so gives the library
module an opportunity to clean up resources allocated on behalf of the
... which strongly suggests that if you MISS the "opportunity to clean
up resources allocated on behalf of the current process", they might
well NOT be cleaned.
Also, if you have a look at what Application Verifier (in Win10 at
least) offers as "Basics", you will find "Leak", which is explained as
"Checks that when a dll is unloaded there are no outstanding resources
allocated by it". If leaving behind "outstanding resources allocated"
was really innocuous, there would IMHO be no reason to even check for
>> On the contrary: even when the DLL is properly FREED from memory
>> (FreeLibrary), somehow the memory leaks INSIDE the DLL stay marked as
>> "unavailable" for Win. And, as I said before, they do accumulate over
>> multiple loads of the DLL(*).
> I think this can only happen if the DLL is not really unloaded from
> memory. FreeLibrary doesn't unload a DLL, it only tells the system
> that the calling program has no more use for the DLL.
Agreed... and it eventually deletes it from memory completely, when no
more parent process uses it.
> But once again, this discussion was about programs, not about DLLs.
> When a program exits, its memory is released.
>> (1) start executable
>> (2) executable loads DLL
>> (3) DLL code allocates with malloc or new
>> (4) for some of the mallocs and news, the corresponding frees and
>> deletes are NOT called -> MEMORY LEAKS
>> (5) exit executable, with properly unloading the DLL (FreeLibrary)
>> (6) repeat from (1) again
>> ... and the MEMORY LEAKS in (4) are not returned to Win for reuse,
>> accumulating and eventually consuming all the RAM there is and crashing
>> the machine.
> This could happen, but is unrelated to the issue discussed in this
Please see above.
> (And I suspect your DLLs do something very special to
> "deserve" the results you describe, like maybe lock some of the memory
> they allocate.)
While it is true that we do lock SOME memory for the purposes of IPC,
NONE of the leaks we ended up plugging were locked. And besides, AFAIK
global (i.e. OS-wide) memory we lock for IPC is allocated in a
completely different segment from the process-local heap where malloc
But anyway: as I said I'll try to construct a sufficiently SIMPLE
example to exhibit the disastrous consequences memory leaks can have. If
I succeed, I'll report back.
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
MinGW-users mailing list
This list observes the Etiquette found at
We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated.
You may change your MinGW Account Options or unsubscribe at: