[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Debugging memory leaks/stale references
From: |
Stefan Monnier |
Subject: |
Re: Debugging memory leaks/stale references |
Date: |
Mon, 27 Sep 2004 16:49:23 -0400 |
User-agent: |
Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3.50 (gnu/linux) |
>> I think it would be worthwhile to start with the basic info returned by
>> `garbage-collect' and such stuff. See `memory-usage.el' below.
>> [ I thought you already tried that, but the few lines above make me think
>> that you don't even know whether the extra MBs are made up of cons cells, or
>> strings, or non-elisp-data, or ...]
> Others already did this. But thanks anyway, I repeated the
> experiment: The numbers indeed lack any distinct increase in
> magnitude. 8-(
Well, that means that the increase is apparently elsewhere, which is good
because it already tells you that hacking on the gc_marking code probably
won't help you.
Now, that doesn't rule out all of alloc.c :-(
>>> Are there any other objects that can change their size after
>>> allocation? (I'm pretty sure that there are no additional Lisp
>>> objects allocated, but maybe an existing object grows without bounds.)
>>
>> Yes. Things like the specpdl "stack", the matrices used in display, maybe
>> the text-property-tree nodes, ...
> Hmm, I'm going to gather a few more stats.
> (And running Emacs under valgrind could prove helpful because I could
> determine if the low-level allocator leaks memory.)
Another thing you might want to try is:
- check /proc/$$/maps before and after the memory growth.
- based on that, infer the memory range where the new (tho supposedly dead)
data is located.
- from GDB, peek at that memory range to see if you recognize the kind of
data that's there.
Stefan
- Debugging memory leaks/stale references, Florian Weimer, 2004/09/21
- Re: Debugging memory leaks/stale references, Simon Josefsson, 2004/09/21
- Re: Debugging memory leaks/stale references, Richard Stallman, 2004/09/28
- Re: Debugging memory leaks/stale references, Florian Weimer, 2004/09/28
- Re: Debugging memory leaks/stale references, Florian Weimer, 2004/09/28
- Re: Debugging memory leaks/stale references, Richard Stallman, 2004/09/29
- Re: Debugging memory leaks/stale references, Kenichi Handa, 2004/09/29
- Re: Debugging memory leaks/stale references, Kim F. Storm, 2004/09/28
Re: Debugging memory leaks/stale references, Stefan Monnier, 2004/09/21