Re: Debugging memory leaks/stale references

[Stefan Monnier <monnier@iro.umontreal.ca>]

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