Post by Eli ZaretskiiA DLL cannot EXIT, AFAIK, it can only be unloaded.
Sure, that's what I meant (sorry for the sloppy term).
Post by Eli ZaretskiiWhen it is
unloaded, all of its memory is released.
NOT sure, obviously (in particular: see below).
Post by Eli ZaretskiiI 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.
According to
https://msdn.microsoft.com/en-us/library/windows/desktop/ms683152(v=vs.85).aspx
, 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.
Post by Eli ZaretskiiBut 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
experience.
Post by Eli ZaretskiiIOW, 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!).
Post by Eli ZaretskiiPost by Emanuel FalkenauerOnce 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?
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
current process.
... 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
the condition.
Post by Eli ZaretskiiPost by Emanuel FalkenauerOn 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.
Post by Eli ZaretskiiBut once again, this discussion was about programs, not about DLLs.
When a program exits, its memory is released.
Post by Emanuel Falkenauer(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.
Please see above.
Post by Eli Zaretskii(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
allocates.
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.
Best,
Emanuel
------------------------------------------------------------------------------
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-***@lists.sourceforge.net
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-***@lists.sourceforge.net?subject=unsubscribe