Re: Debugging emacs memory management

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

> 1. How does one debug this? There's a memory profiler (launched with
> (profiler-start) ),

Right, it's not really memory profiler.

Have you tried `memory-usage' (available from a GNU ELPA near you)?
It won't give you an answer, but it does give a slightly more detailed
account of the memory known to be used, so we can tell whether it's Lisp
data that's retained for too long, or whether the leak is in data not
managed in the Lisp heap, for example.

> 1.  seq 1000000 > /tmp/dat                  [ create large file on disk ]
> 2.  emacs-snapshot                          [ 32MB RSS ]

> 3.  open /tmp/dat                           [ 40MB ]
> 4.  (delete-region (point-min) (point-max)) [ 40MB ]
> 5.  (undo)                                  [ 47MB ]
> 6.  (kill-buffer)                           [ 40MB ]
> 7.  (garbage-collect)                       [ 40MB ]

> 3a. open /tmp/dat                           [ 46MB ]
> 4a. (delete-region (point-min) (point-max)) [ 60MB ]
> 5a. (undo)                                  [ 60MB ]
> 6a. (kill-buffer)                           [ 60MB ]
> 7a. (garbage-collect)                       [ 60MB ]

> 3b. open /tmp/dat                           [ 60MB ]
> 4b. (delete-region (point-min) (point-max)) [ 60MB ]
> 5b. (undo)                                  [ 60MB ]
> 6b. (kill-buffer)                           [ 60MB ]
> 7b. (garbage-collect)                       [ 60MB ]

Failure to shrink after you stop using something is not considered
a leak: there can be any number of reasons why some part of Emacs
decides not to return the space to the OS, even though it's known (at
some level) to be free and can/will be reused for something else in
the future.

> Without knowing the internals, it looks like a leak, but I can't be
> sure.  If I move around the /tmp/dat buffer, and (delete-region) various
> other chunks, I can eat up even more memory.

That's no guarantee that there's a leak, but if you can keep eating
arbitrary amount of memory by repeated use of
delete-region+kill-buffer+find-file then it does look like
a leak, indeed.


        Stefan