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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]