Emacs 21.2 - Garbage collector frenzy :-)

Emacs 21.2 - Garbage collector frenzy :-)

[François Pinard]

This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English, because the Emacs maintainers do not have
translators to read other languages for them.

Your bug report will be posted to the bug-gnu-emacs@gnu.org mailing list,
and to the gnu.emacs.bug news group.

In GNU Emacs 21.2.1 (i586-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2002-04-12 on titan
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: POSIX
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: fr_CA.ISO-8859-1
  locale-coding-system: iso-latin-1
  default-enable-multibyte-characters: t

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

This is a difficult bug to report, and in fact, I am asking for help about
how to get useful information to report, yet without using too much of my
free time trying to understand the conditions behind the problem.  Not easy.

The problem is that, at regular intervals (maybe once every fifteen
minutes or so, I did not precisely timed it), Emacs suddenly starts
burning CPU solidly for about 20 seconds, not responding to commands,
and in particular, not responding to `C-g's.  This occurs spontaneously,
and even when I do not actually use Emacs (I'm not typing in this window).
Then, everything comes back to normal, and commands accumulated while
Emacs was burning CPU then execute in a row.  I thought about doing `(setq
garbage-collection-messages t)', and the minibuffer does display "Garbage
collecting..." and "Gargabe collecting...done" maybe 30 times in a row,
each time those CPU frenzies occur. :-)

I tried using a bare Emacs (no `.emacs') and the problem does not occur,
but then, Emacs is not very usable for me in practice.  I progressively
re-inserted sections of my `.emacs', waiting half an hour after each excerpt
to see if the problem seems to be there or not.  Since I have a rather big
`.emacs' setup, this sums up to a many, many hours, and I stopped trying
to get clues after a few days, as I need a full customised Emacs to work
effectively, and cannot let me stop or crawl for many days.  But I do not
see what other technique I could use to get clues more efficiently.

This is with Emacs 21.2 that I thought about checking if the problem is
related to garbage collection, but I remember having observed such CPU
loops in the latest pretest before 21.2, without much to say about them at
the time.  Not that I have so much more to say now...  How could I proceed
towards better reporting the problem?  (the problem occurred twice while
I was composing this message, so it is more frequent than I thought).


Recent input:
C-s C-s C-s C-s C-a C-p C-e C-p <return> C-a C-x g 
g C-n C-k C-p C-e <return> r e t u r n SPC c o m m 
o n . E q ( n o d e [ 1 ] , SPC c o m m o n . V e r 
b a t i m ( ' 0 ' ) ) C-n C-a C-SPC C-n C-n C-n C-n 
C-w M-x e m a c s - b u g <return> <backspace> <backspace> 
<backspace> <backspace> <backspace> <backspace> <backspace> 
<backspace> <backspace> r e p o r <tab> <return>

Recent messages:
/home/pinard/fpub/topy/Topy/scmtopy.py clean
Wrote /home/pinard/fpub/topy/Topy/scmtopy.py
Mark set [2 times]
Closes block: ...def f_member(self, node):
Mark set [3 times]
Auto-saving...done
Mark set
Mark saved where search started
Mark set [2 times]
Loading emacsbug...done

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard

Re: Emacs 21.2 - Garbage collector frenzy :-)

[Karl Eichwalder]

pinard@iro.umontreal.ca (François Pinard) writes:

> I progressively re-inserted sections of my `.emacs', waiting half an
> hour after each excerpt to see if the problem seems to be there or
> not.

Use a b-tree like approach: Start with half your settings; it the bug
doesn't accur, use the other half; proceed this way until you will find
the offending setting.  Okay, things getting interesting when a
combination of settings causes the bug.

> Since I have a rather big `.emacs' setup,

This could mean two things:

    . Emacs lacks essential features--please, report those as usability
    bugs.

    . Updating Emacs you forgot to trim down your .emacs ;-)

Hope this helps.

-- 
ke@suse.de (work) / keichwa@gmx.net (home):              |
http://www.suse.de/~ke/                                  |      ,__o
Free Translation Project:                                |    _-\_<,
http://www.iro.umontreal.ca/contrib/po/HTML/             |   (*)/'(*)

Re: Emacs 21.2 - Garbage collector frenzy :-)

[David desJardins]

Karl Eichwalder <keichwa@gmx.net> writes:
> This could mean two things:
> 
>     . Emacs lacks essential features--please, report those as usability
>     bugs.
> 
>     . Updating Emacs you forgot to trim down your .emacs ;-)

Actually, a large and growing fraction of my .emacs file is devoted to
turning off or disabling various misfeatures.  The more features get
crammed in, the bigger my file gets.  However, I think the people who
put this stuff in are proud of it; I don't think they will be much
impressed if I report their new features as "usability bugs".

                                        David desJardins

Re: Emacs 21.2 - Garbage collector frenzy :-)

[Eli Zaretskii]

On 21 Apr 2002, =?iso-8859-1?q?Fran=E7ois?= Pinard wrote:

> This is with Emacs 21.2 that I thought about checking if the problem is
> related to garbage collection, but I remember having observed such CPU
> loops in the latest pretest before 21.2, without much to say about them at
> the time.  Not that I have so much more to say now...  How could I proceed
> towards better reporting the problem?

Try this:

  - Run Emacs under GDB.  Be sure to start GDB from the `src' directory 
    of the Emacs source tree, to make it use the .gdbinit file with all
    the additional commands it defines.

  - When the problem happens, interrupt Emacs with "kill -TSTP PID", 
    where PID is the Emacs process ID, or by typing "C-c" at the window 
    where Emacs is run under GDB.  This should cause GDB to kick in.

  - At the GDB prompt, type "xbacktrace".  It should produce the 
    Lisp-level backtrace showing what function caused the massive GC.

  - Still at the GDB prompt, type "bt" for the C-level backtrace.

  - Repeat the above 3 steps several times, each time continuing Emacs 
    after producing the backtraces.  After that, you should have enough 
    information to figure out what feature(s) causes the massive GC.  
    Post that info here.

The file etc/DEBUG in the Emacs distribution has more hints for debugging 
Emacs.

Re: Emacs 21.2 - Garbage collector frenzy :-)

[Pavel Janík]

   From: David desJardins <desj@math.berkeley.edu>
   Date: 21 Apr 2002 22:29:46 -0700

   > crammed in, the bigger my file gets.  However, I think the people who
   > put this stuff in are proud of it; I don't think they will be much
   > impressed if I report their new features as "usability bugs".

I don't think so. Please report them.
-- 
Pavel Janík

2.4.15 eats files.  DON'T USE IT.
                  -- "H. Peter Anvin" in LKML

Re: Emacs 21.2 - Garbage collector frenzy :-)

[Stefan Monnier]

>>>>> "François" == François Pinard <pinard@iro.umontreal.ca> writes:
> The problem is that, at regular intervals (maybe once every fifteen
> minutes or so, I did not precisely timed it), Emacs suddenly starts
> burning CPU solidly for about 20 seconds, not responding to commands,
> and in particular, not responding to `C-g's.  This occurs spontaneously,

A shot in the dark: do you happen to use font-lock (with jit-lock,
which is the case by default) and do you happen to have some very
large buffers (a typical case would be a large RMAIL buffer) ?


	Stefan

Re: Emacs 21.2 - Garbage collector frenzy :-)

[Andreas Schwab]

Eli Zaretskii <eliz@is.elta.co.il> writes:

|>   - When the problem happens, interrupt Emacs with "kill -TSTP PID", 
|>     where PID is the Emacs process ID, or by typing "C-c" at the window 
|>     where Emacs is run under GDB.  This should cause GDB to kick in.

Don't use C-c from inside GDB with the default setup, it does not work
(see the comment in .gdbinit).  Use C-z instead.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE GmbH, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Emacs 21.2 - Garbage collector frenzy :-)

[Eli Zaretskii]

On Mon, 22 Apr 2002, Andreas Schwab wrote:

> Eli Zaretskii <eliz@is.elta.co.il> writes:
> 
> |>   - When the problem happens, interrupt Emacs with "kill -TSTP PID", 
> |>     where PID is the Emacs process ID, or by typing "C-c" at the window 
> |>     where Emacs is run under GDB.  This should cause GDB to kick in.
> 
> Don't use C-c from inside GDB with the default setup, it does not work
> (see the comment in .gdbinit).

I meant to type C-c in the window where Emacs was started.  That's the 
window where you type "gdb RET" from the shell prompt, and where you 
eventually type "run" at GDB's prompt.  Doesn't C-c there go to GDB?

Re: Emacs 21.2 - Garbage collector frenzy :-)

[Andreas Schwab]

Eli Zaretskii <eliz@is.elta.co.il> writes:

|> On Mon, 22 Apr 2002, Andreas Schwab wrote:
|> 
|> > Eli Zaretskii <eliz@is.elta.co.il> writes:
|> > 
|> > |>   - When the problem happens, interrupt Emacs with "kill -TSTP PID", 
|> > |>     where PID is the Emacs process ID, or by typing "C-c" at the window 
|> > |>     where Emacs is run under GDB.  This should cause GDB to kick in.
|> > 
|> > Don't use C-c from inside GDB with the default setup, it does not work
|> > (see the comment in .gdbinit).
|> 
|> I meant to type C-c in the window where Emacs was started.  That's the 
|> window where you type "gdb RET" from the shell prompt, and where you 
|> eventually type "run" at GDB's prompt.  Doesn't C-c there go to GDB?

It does, but GDB just passes it along to Emacs, which dies.  This is due
to "handle 2 noprint pass".

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE GmbH, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."