GNU bug report logs - #17986
24.3.92; Evaluating (setq default-directory nil) freezes Emacs

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 17986 in the body.
You can then email your comments to 17986 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.92; Evaluating (setq default-directory nil) freezes Emacs
Date: Thu, 10 Jul 2014 14:27:30 +0200

0. Start Emacs with -Q or -Q -D
1. Type (setq default-directory nil) in *scratch* and evaluate it.
=> Emacs freezes uninterruptibly and uses up to 90% CPU; I have to kill
it from outside.

This happens in both emacs-24 and the trunk.  The C backtrace seems to
differ depending on how quickly I type `z' in gdb and whether I start
Emacs with -Q or with -Q -D.  If no one else can reproduce this, I can
supply backtraces.  So far, I've gotten as the only Lisp backtrace
"redisplay_internal (C function)" (twice with emacs-24 from July 7) and
(after updating to current sources) "command-error-default-function"
(twice with trunk, once with emacs-24).

I know that default-directory is documented as being a string, though
its global value is "nil" (and evaluating (setq-default
default-directory nil) is unproblematic).  Still, Emacs shouldn't just
freeze up.  FWIW, it hit this problem while testing code that sets
default-directory to the value of a variable, which in the course of
testing at one point happened to be nil.

In GNU Emacs 24.3.92.7 (x86_64-suse-linux-gnu, GTK+ Version 3.10.4)
 of 2014-07-10 on rosalinde
Repository revision: 117368 monnier <at> iro.umontreal.ca-20140709185406-m0q0fjepl42pcrqx
Windowing system distributor `The X.Org Foundation', version 11.0.11403901
System Description:	openSUSE 13.1 (Bottle) (x86_64)

Configured using:
 `configure --without-toolkit-scroll-bars CFLAGS=-g3'

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Memory information:
((conses 16 363760 33883)
 (symbols 48 50640 0)
 (miscs 40 392 740)
 (strings 32 91952 9976)
 (string-bytes 1 3053626)
 (vectors 16 39068)
 (vector-slots 8 1553444 171631)
 (floats 8 853 677)
 (intervals 56 16382 141)
 (buffers 960 38)
 (heap 1024 52675 1862))

Message #8 received at 17986 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 17986 <at> debbugs.gnu.org
Subject: Re: bug#17986: 24.3.92;
 Evaluating (setq default-directory nil) freezes Emacs
Date: Sun, 13 Jul 2014 17:54:35 +0300

> From: Stephen Berman <stephen.berman <at> gmx.net>
> Date: Thu, 10 Jul 2014 14:27:30 +0200
> 
> 0. Start Emacs with -Q or -Q -D
> 1. Type (setq default-directory nil) in *scratch* and evaluate it.
> => Emacs freezes uninterruptibly and uses up to 90% CPU; I have to kill
> it from outside.

Should be fixed in revision 117376 on the emacs-24 branch.

> This happens in both emacs-24 and the trunk.  The C backtrace seems to
> differ depending on how quickly I type `z' in gdb and whether I start
> Emacs with -Q or with -Q -D.  If no one else can reproduce this, I can
> supply backtraces.  So far, I've gotten as the only Lisp backtrace
> "redisplay_internal (C function)" (twice with emacs-24 from July 7) and
> (after updating to current sources) "command-error-default-function"
> (twice with trunk, once with emacs-24).

When Emacs becomes unresponsive, it is best to attach a debugger to a
running Emacs process, and then use the procedure described in
etc/DEBUG (under "If the symptom of the bug is that Emacs fails to
respond") to find out which function infloops; then include this
information in the bug report.

Thanks.

Message #13 received at 17986 <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 17986 <at> debbugs.gnu.org
Subject: Re: bug#17986: 24.3.92;
 Evaluating (setq default-directory nil) freezes Emacs
Date: Tue, 15 Jul 2014 13:41:02 +0200

On Sun, 13 Jul 2014 17:54:35 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:

>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Date: Thu, 10 Jul 2014 14:27:30 +0200
>> 
>> 0. Start Emacs with -Q or -Q -D
>> 1. Type (setq default-directory nil) in *scratch* and evaluate it.
>> => Emacs freezes uninterruptibly and uses up to 90% CPU; I have to kill
>> it from outside.
>
> Should be fixed in revision 117376 on the emacs-24 branch.

For the record, I confirm that this fixes it; thanks.

> When Emacs becomes unresponsive, it is best to attach a debugger to a
> running Emacs process, and then use the procedure described in
> etc/DEBUG (under "If the symptom of the bug is that Emacs fails to
> respond") to find out which function infloops; then include this
> information in the bug report.

I tried doing this, but neither with `s' nor with `f' did gdb show what
I could recognize as an infloop (`f' always went straight to frame #0,
and `s' never got to a loop, though I entered it very many times).  Is
there something more specific I could do the next time?

Steve Berman

Message #16 received at 17986 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 17986 <at> debbugs.gnu.org
Subject: Re: bug#17986: 24.3.92;
 Evaluating (setq default-directory nil) freezes Emacs
Date: Tue, 15 Jul 2014 17:27:48 +0300

> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: 17986 <at> debbugs.gnu.org
> Date: Tue, 15 Jul 2014 13:41:02 +0200
> 
> On Sun, 13 Jul 2014 17:54:35 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
> >> From: Stephen Berman <stephen.berman <at> gmx.net>
> >> Date: Thu, 10 Jul 2014 14:27:30 +0200
> >> 
> >> 0. Start Emacs with -Q or -Q -D
> >> 1. Type (setq default-directory nil) in *scratch* and evaluate it.
> >> => Emacs freezes uninterruptibly and uses up to 90% CPU; I have to kill
> >> it from outside.
> >
> > Should be fixed in revision 117376 on the emacs-24 branch.
> 
> For the record, I confirm that this fixes it; thanks.

Thanks for verification.

> > When Emacs becomes unresponsive, it is best to attach a debugger to a
> > running Emacs process, and then use the procedure described in
> > etc/DEBUG (under "If the symptom of the bug is that Emacs fails to
> > respond") to find out which function infloops; then include this
> > information in the bug report.
> 
> I tried doing this, but neither with `s' nor with `f' did gdb show what
> I could recognize as an infloop (`f' always went straight to frame #0,
> and `s' never got to a loop, though I entered it very many times).  Is
> there something more specific I could do the next time?

etc/DEBUG doesn't say to use `s' and `f', it says to use 'finish' and
'next'.  'f' is not an abbreviation of 'finish', it is an abbreviation
of 'frame'.  Also, 'step', or 's', is not useful in this situation,
because it simply undoes what you did with 'finish', by getting you
deeper and deeper into the code from which you just emerged.

The idea of that procedure is to first find the function where Emacs
loops, by repeated 'finish' commands until 'finish' doesn't return,
i.e. does not print a higher frame number and the value returned by
the lower frame.  Then step with 'next' through the looping function
and see why it loops, i.e. why it fails to return.  (In this case, it
failed to return because displaying the mode line signaled an error,
which immediately triggered another redisplay.)

Message #19 received at 17986 <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 17986 <at> debbugs.gnu.org
Subject: Re: bug#17986: 24.3.92;
 Evaluating (setq default-directory nil) freezes Emacs
Date: Tue, 15 Jul 2014 20:49:52 +0200

On Tue, 15 Jul 2014 17:27:48 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:

>> I tried doing this, but neither with `s' nor with `f' did gdb show what
>> I could recognize as an infloop (`f' always went straight to frame #0,
>> and `s' never got to a loop, though I entered it very many times).  Is
>> there something more specific I could do the next time?
>
> etc/DEBUG doesn't say to use `s' and `f', it says to use 'finish' and
> 'next'.  'f' is not an abbreviation of 'finish', it is an abbreviation
> of 'frame'.  Also, 'step', or 's', is not useful in this situation,
> because it simply undoes what you did with 'finish', by getting you
> deeper and deeper into the code from which you just emerged.

Oh, dear.  I apologize for my hasty and careless reading of etc/DEBUG.

> The idea of that procedure is to first find the function where Emacs
> loops, by repeated 'finish' commands until 'finish' doesn't return,
> i.e. does not print a higher frame number and the value returned by
> the lower frame.  Then step with 'next' through the looping function
> and see why it loops, i.e. why it fails to return.  (In this case, it
> failed to return because displaying the mode line signaled an error,
> which immediately triggered another redisplay.)

Thanks for the elucidation; I'll try to remember to apply it the next time.

Steve Berman

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.