Re: Debugging memory leaks/stale references

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

> garbage-collect output alone is not very helpful.

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 think this can be implemented reasonably easily:

  0 - change mark_object so as to increment a counter `objects_marked' each
      time it marks an object.
  1 - set the mark bit on X (so as ot pretend it and its children were
      already marked).
  2 - call the gc_mark routine (extracted from garbage_collect).
  4 - reset objects_marked to 0.
  3 - call `mark_object(X)'.
  5 - read the value of objects_marked.
  6 - do the gc_sweep.
  7 - return the value read.

Obviously it'd be a slow function (it does a full GC just to get a single
integer number), but maybe it's good enough?

You could start by calling (mapcar 'count-exclusive-children (buffer-list))
every once in a while to see how the numbers evolve.
Or maybe (let ((res nil))
           (mapatoms (lambda (s)
                       (push (cons s count-exclusive-children s) res)))
           res)

> (I'm going to test CVS Emacs soon, just to be sure that the behavior
> is still the same.

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

> It's probably a Gnus bug, but you never know.)

It might also be in Emacs or in an interaction between the two.
I remember seeing strange things a couple years back where dead buffers
where kept "alive" much longer than I thought (and they can hold on to
a lot of data in their variables and overlays).


        Stefan