Re: [Mingw-users] CRT lib: potential memory leakage
- Date: Sun, 07 May 2017 20:02:38 +0300
- From: Eli Zaretskii <eliz@xxxxxxx>
- Subject: Re: [Mingw-users] CRT lib: potential memory leakage
> Cc: mingw-users@xxxxxxxxxxxxxxxxxxxxx
> From: Emanuel Falkenauer <E.Falkenauer@xxxxxxxxxxxxxxxxx>
> Date: Sun, 7 May 2017 17:55:24 +0200
> I'm talking about mallocs and frees called by the
> functions INSIDE the DLL. Namely, a few of those mallocs were missing
> their corresponding frees and, as a result, even after the EXIT of the
> DLL, that memory was clearly not returned to the system.
A DLL cannot EXIT, AFAIK, it can only be unloaded. When it is
unloaded, all of its memory is released.
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. 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.
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).
> 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.
> > But before you decide that this is your problem, I suggest to make
> > sure that the DLLs your application loads remains in memory when the
> > application exits.
> 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.
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
thread. (And I suspect your DLLs do something very special to
"deserve" the results you describe, like maybe lock some of the memory
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: