Re: Debugging memory leaks/stale references

[Florian Weimer <fw@deneb.enyo.de>]

* Stefan Monnier:

>> Is it possible to dump all reachable Lisp objects to a file, in the
>> format that is returned by princ?
>
> Not that I know.
>
>> I could run diff(1) on two versions of the file, and this might reveal
>> which objects are leaking (or held by stale references).
>
> That's an interesting idea.
> But one of the problems is that `princ' is not enough.  Starting from the
> root set (i.e. the stack, and the global vars), princ would fail to print
> a lot of info because buffers are just printed #<buffer foo> without
> exposing its contents.

Hmm, I don't think so.  You'd have to mimic a GC traversal, and GC
does descend into buffer objects.

> Indeed.  One thing I was thinking about is a function
> `count-exclusive-children' which would take an object X as a parameter
> (could be the obarray, a buffer, a symbol, ...) and would return the number
> of objects that would die if X died.

I'm not sure about the usefulness of this function.  If data
structures are cyclic, it might not yield any actionable data at all.

> I think it's indeed the same with CVS, based on reports we got here not that
> long ago from Kai and others.

Indeed.  But at least my Emacs doesn't crash at the end of the day.

>> It's probably a Gnus bug, but you never know.)
>
> It might also be in Emacs or in an interaction between the two.

Or even with GNU libc's malloc().  The Emacs allocator disables
allocation using mmap() in some cases, and the corresponding part of
the libc allocator might have been subject to bit rot lately.