Web lists-archives.com

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 
the machine.


------------------------------------------------------------------------------
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
MinGW-users@xxxxxxxxxxxxxxxxxxxxx

This list observes the Etiquette found at 
http://www.mingw.org/Mailing_Lists.
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:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-request@xxxxxxxxxxxxxxxxxxxxx?subject=unsubscribe