GNU bug report logs - #34320
Emacs 26.1: RAM does not get released after quitting Emacs

Previous Next

Full log

Message #17 received at submit <at> debbugs.gnu.org (full text, mbox):

From: René Kuligowski <renekuligowski <at> o2mail.de>
To: Eli Zaretskii <eliz <at> gnu.org>, bug-gnu-emacs <at> gnu.org
Subject: Re: bug#34320: Fwd: Re: bug#34320: Emacs 26.1: RAM does not get
 released after quitting Emacs
Date: Wed, 06 Feb 2019 20:46:17 -0100

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 <at> 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?
>
>
>    

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.