GNU bug report logs -
#43389
28.0.50; Emacs memory leaks
Previous Next
Full log
Message #290 received at 43389 <at> debbugs.gnu.org (full text, mbox):
* Eli Zaretskii <eliz <at> gnu.org> [2020-11-22 23:17]:
> > Date: Sun, 22 Nov 2020 22:52:14 +0300
> > From: Jean Louis <bugs <at> gnu.support>
> > Cc: fweimer <at> redhat.com, 43389 <at> debbugs.gnu.org, dj <at> redhat.com,
> > michael_heerdegen <at> web.de, trevor <at> trevorbentley.com, carlos <at> redhat.com
> >
> > I am now following this strategy here:
> > https://github.com/jemalloc/jemalloc/wiki/Use-Case%3A-Leak-Checking
>
> That uses a different implementation of malloc, so I'm not sure it
> will help us.
It will not help if you are able to interpret the PDF reports and you
do not see anything helpful. If you do interpret those PDF reports
please tell me as such could be useful to find possible causes or find
other issues in Emacs.
Does this here tells you anything?
https://gnu.support/files/tmp/2020-11-22/jeprof.26889.0.f.heap.pdf
Does this add module isra.0 inside tells you anything?
https://gnu.support/files/tmp/2020-11-22/jeprof.26922.0.f.heap.pdf
I am using dynamic modules like vterm and libpq, can that influence
memory or create memory leaks?
What is tst_post_reentrancy_raw, is that something that eats memory?
I am still running this session with jemalloc and I wish to see if
anything will happen that blocks the work similar how it blocks with
the normal run. This helps slightly in determination. As if run of
Emacs with jemalloc does not cause problems one time, maybe 2-5 times
or 10 times, that may be deduce problem to standard malloc and not
Emacs.
Then in the next session I will try again the tools as described and
submit data.
To help me understand, do you think problem is in Emacs or in glibc
malloc?
This bug report was last modified 4 years and 58 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.