bug#34320: Fwd: Re: bug#34320: Emacs 26.1: RAM does not get released after quitting Emacs

["René Kuligowski" <renekuligowski@o2mail.de>]

Hmm… let me take another look… as far as I can tell, there's no 
recognizable owner to those, and ld seems not to be involved here — it 
shows with a big batch of libs, but not in the blocks in question, and 
most of them are not used by Emacs, afaik from the configure options and 
makefiles (but don't take my word for it, I'm not one of you Emacs 
developers ;-) ).  Looks more like a zombie without a zombie process to 
me, sort of like 'kill -9' successful but for some weird reason the 
memory being detached and not freed.  Can this happen with 
multi-threading, when the current thread's parent quits and somehow the 
child cannot cleanly exit?

   However, I'll try a few more methods, to find out as much as I can.  
Might take one or the other day, though.


Thanks so far!


On 05.02.2019 16:20, Eli Zaretskii wrote:
>> Date: Tue, 05 Feb 2019 11:45:29 -0100
>> From: René Kuligowski<renekuligowski@o2mail.de>
>>
>>     I also checked thoroughly in the VFSes (/sys, /proc etc.) and ran a
>> mem tracer.  The memory blocks are not freed, but stay allocated, like
>> from a forgotten free() call or a severely buggy malloc() call (like the
>> common issues with gcc 3.3 and 4.5).
>>      
> Can you see which software module "owns" the memory that is not freed?
> Could it be, for instance, that Emacs loaded some system shared
> libraries, and the OS didn't unload them?
>
>
>