bug#17986: 24.3.92; Evaluating (setq default-directory nil) freezes Emacs

bug#17986: 24.3.92; Evaluating (setq default-directory nil) freezes Emacs

[Stephen Berman]

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@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))

bug#17986: 24.3.92; Evaluating (setq default-directory nil) freezes Emacs

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@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.

bug#17986: 24.3.92; Evaluating (setq default-directory nil) freezes Emacs

[Stephen Berman]

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

>> From: Stephen Berman <stephen.berman@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

bug#17986: 24.3.92; Evaluating (setq default-directory nil) freezes Emacs

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: 17986@debbugs.gnu.org
> Date: Tue, 15 Jul 2014 13:41:02 +0200
> 
> On Sun, 13 Jul 2014 17:54:35 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
> 
> >> From: Stephen Berman <stephen.berman@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.)

bug#17986: 24.3.92; Evaluating (setq default-directory nil) freezes Emacs

[Stephen Berman]

On Tue, 15 Jul 2014 17:27:48 +0300 Eli Zaretskii <eliz@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