Re: [Mingw-users] CRT lib: potential memory leakage
- Date: Sun, 7 May 2017 17:55:24 +0200
- From: Emanuel Falkenauer <E.Falkenauer@xxxxxxxxxxxxxxxxx>
- Subject: Re: [Mingw-users] CRT lib: potential memory leakage
>> When after just two days of uptime 10 of my 12 gigs of RAM are reported
>> "in use" by the Task Manager, then the printer disconnects by itself,
>> then the Internet disappears, and then running new programs becomes
>> generally impossible... you know something is really amiss.
> That's not something that happens to me, surely.
>> Well, you are onto something here: practically all of our stuff is in
>> DLLs! So can you explain what you mean by "Memory for DLLs is
>> allocated by the system, not by the application", i.e. what is the
>> fundamental difference between calling malloc in an exe and a DLL? In
>> both, the memory may subsequently be freed...
> Simply what I wrote: when a DLL is loaded, the application doesn't
> call 'malloc' to allocate the memory needed for the DLL. So it won't
> help to call 'free'. If the DLL was loaded with LoadLibrary, you can
> unload it with FreeLibrary,
You are stating the obvious (LoadLibrary and FreeLibrary), which is NOT
what's in stake here: 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.
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
DLL? I don't see what that difference could be.
> but if it was loaded automatically, you
> cannot do even that, I think.
Indeed, you can't.
> 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(*).
Ergo it seems NOT to be the case that Win reclaimes everything that was
allocated when the application (and its DLL) exits.
P.S. (*) Just to make absolutely sure you understand what I mean:
(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
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: