mem leak

mem leak

[Miles Bader]

Does anybody have advice for finding a memory leak in emacs?

Recent builds seems to have some leak:  even with only a few small
buffers open, Emacs rapidly consumes more and more memory (to the point
where the system eventually becomes unusable).

-Miles
-- 
Ich bin ein Virus. Mach' mit und kopiere mich in Deine .signature.

Re: mem leak

[David Kastrup]

Miles Bader <miles.bader@necel.com> writes:

> Does anybody have advice for finding a memory leak in emacs?
>
> Recent builds seems to have some leak:  even with only a few small
> buffers open, Emacs rapidly consumes more and more memory (to the point
> where the system eventually becomes unusable).

garbage-collect is an interactive built-in function in `C source code'.
(garbage-collect)

Reclaim storage for Lisp objects no longer needed.
Garbage collection happens automatically if you cons more than
`gc-cons-threshold' bytes of Lisp data since previous garbage collection.
`garbage-collect' normally returns a list with info on amount of space in use:
 ((USED-CONSES . FREE-CONSES) (USED-SYMS . FREE-SYMS)
  (USED-MARKERS . FREE-MARKERS) USED-STRING-CHARS USED-VECTOR-SLOTS
  (USED-FLOATS . FREE-FLOATS) (USED-INTERVALS . FREE-INTERVALS)
  (USED-STRINGS . FREE-STRINGS))
However, if there was overflow in pure space, `garbage-collect'
returns nil, because real GC can't be done.

[back]

This might help tracking down what kind of memory is consumed, and
whether it is Lisp-visible.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: mem leak

[Miles Bader]

David Kastrup <dak@gnu.org> writes:
> (garbage-collect)
>
> Reclaim storage for Lisp objects no longer needed.
> Garbage collection happens automatically if you cons more than
> `gc-cons-threshold' bytes of Lisp data since previous garbage collection.
...
> However, if there was overflow in pure space, `garbage-collect'
> returns nil, because real GC can't be done.

That seems to answer my question -- when I do (garbage-collect), it
returns nil!!!!!  If it's not GCing... :-O

I guess pure space overflowed when I built emacs and I didn't notice
(even with all the recent discussion :-).

Thanks,

-Miles
-- 
"Most attacks seem to take place at night, during a rainstorm, uphill,
 where four map sheets join."   -- Anon. British Officer in WW I

Re: mem leak

[LENNART BORGMAN]

From: Miles Bader <miles.bader@necel.com>
> David Kastrup <dak@gnu.org> writes:
> > (garbage-collect)
> >
> > Reclaim storage for Lisp objects no longer needed.
> > Garbage collection happens automatically if you cons more than
> > `gc-cons-threshold' bytes of Lisp data since previous garbage 
> collection....
> > However, if there was overflow in pure space, `garbage-collect'
> > returns nil, because real GC can't be done.
> 
> That seems to answer my question -- when I do (garbage-collect), it
> returns nil!!!!!  If it's not GCing... :-O
> 
> I guess pure space overflowed when I built emacs and I didn't notice
> (even with all the recent discussion :-).

What message should one look for? Does not the build fail?

Re: mem leak

[Miles Bader]

LENNART BORGMAN <lennart.borgman.073@student.lu.se> writes:
>> I guess pure space overflowed when I built emacs and I didn't notice
>> (even with all the recent discussion :-).
>
> What message should one look for? Does not the build fail?

It prints a warning message, but it tends to get lost among the large
amount of other noise that emacs spits out during compilation.

[I don't have the exact message handy, but I believe it was quoted in
the recent discussion about purespace.]

-Miles
-- 
The car has become... an article of dress without which we feel uncertain,
unclad, and incomplete.  [Marshall McLuhan, Understanding Media, 1964]

Re: mem leak

[Romain Francoise]

Miles Bader <miles.bader@necel.com> writes:

> It prints a warning message, but it tends to get lost among the large
> amount of other noise that emacs spits out during compilation.

The splash screen shows a warning message when pure space overflowed
during the build.  It's hard to miss.

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

Re: mem leak

[Miles Bader]

Romain Francoise <romain@orebokech.com> writes:
>> It prints a warning message, but it tends to get lost among the large
>> amount of other noise that emacs spits out during compilation.
>
> The splash screen shows a warning message when pure space overflowed
> during the build.  It's hard to miss.

... unless you have the splash screen disabled (as I do) ... :-/

-miles

-- 
The car has become... an article of dress without which we feel uncertain,
unclad, and incomplete.  [Marshall McLuhan, Understanding Media, 1964]

Re: mem leak

[Miles Bader]

Miles Bader <miles.bader@necel.com> writes:
>>> It prints a warning message, but it tends to get lost among the large
>>> amount of other noise that emacs spits out during compilation.
>>
>> The splash screen shows a warning message when pure space overflowed
>> during the build.  It's hard to miss.
>
> ... unless you have the splash screen disabled (as I do) ... :-/

Is there any reason _not_ to make the build fail in this case?

As I've found an Emacs with an overflowed pure space is not very usable
anyway... so it's something that really should be fixed immediately by
the builder if it happens.

-miles
-- 
It wasn't the Exxon Valdez captain's driving that caused the Alaskan oil spill.
It was yours.  [Greenpeace advertisement, New York Times, 25 February 1990]

Re: mem leak

[Stefan Monnier]

> As I've found an Emacs with an overflowed pure space is not very usable
> anyway... so it's something that really should be fixed immediately by
> the builder if it happens.

Overflow can happen because the .elc file is missing, and the
not-completely-functional Emacs that results is quite functional enough to
then byte-compile the file, so it makes bootstrapping easier.


        Stefan

Re: mem leak

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> Overflow can happen because the .elc file is missing, and the
> not-completely-functional Emacs that results is quite functional enough to
> then byte-compile the file, so it makes bootstrapping easier.

Hmmm, how hard would it be to have it runnable, but not _installable_ in
such a case (for instance, if it retained the executable, but gave it
another name, "emacs-non-pure" or something)?

[I don't know whether it's easy to get the results of the failure in a
form that make can easily use...]

-Miles

-- 
Somebody has to do something, and it's just incredibly pathetic that it
has to be us.  -- Jerry Garcia

Re: mem leak

[Richard Stallman]

    Is there any reason _not_ to make the build fail in this case?

Yes.  Sometimes pure space overflow is due to a bug.  The best way to
investigate it is to look inside the dumped Emacs.  If overflow made
the build fail, you'd have to edit puresize.h before you could debug.