GNU bug report logs - #24692
25.1; simple, reproducible Emacs 25.1 crash on MS Windows

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 24692 in the body.
You can then email your comments to 24692 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: Drew Adams <drew.adams <at> oracle.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 25.1; simple, reproducible Emacs 25.1 crash on MS Windows
Date: Fri, 14 Oct 2016 09:39:29 -0700 (PDT)

[Message part 1 (text/plain, inline)]

I hope this is responsible for the frequent crashes I get with Emacs 25,
or at least most of them.

I spent many hours narrowing this down.  I'm hoping that that time won't
have been wasted. ;-)

Recipe:

1. Save the attached file, `e25-crash.el'.

2. runemacs.exe -Q --debug-init -l "/YOUR/PATH/TO/e25-crash.el

You will get two frames, one with buffer *scratch*, the other with the
minibuffer, buffer *Minibuf-0*.

3. Click the title bar of the frame having buffer *scratch*, to raise
and select it.

4. `C-h f prefix-command-preserve-state RET'.

5. Click `mouse-2' on the file name `simple.el' in buffer `*Help*'.

CRASH!

Note that using a different command for `C-h f', which is not in
`simple.el', might not crash Emacs.  A guess is that the (now)
large size of `simple.el' contributes to the problem.

In GNU Emacs 25.1.1 (x86_64-w64-mingw32)
 of 2016-09-17
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --without-dbus --without-compress-install CFLAGS=-static'

[e25-crash.el (application/octet-stream, attachment)]

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

From: martin rudalics <rudalics <at> gmx.at>
To: Drew Adams <drew.adams <at> oracle.com>, 24692 <at> debbugs.gnu.org
Subject: Re: bug#24692: 25.1; simple, reproducible Emacs 25.1 crash on MS
 Windows
Date: Fri, 14 Oct 2016 19:13:03 +0200

> Recipe:
>
> 1. Save the attached file, `e25-crash.el'.
>
> 2. runemacs.exe -Q --debug-init -l "/YOUR/PATH/TO/e25-crash.el
>
> You will get two frames, one with buffer *scratch*, the other with the
> minibuffer, buffer *Minibuf-0*.
>
> 3. Click the title bar of the frame having buffer *scratch*, to raise
> and select it.
>
> 4. `C-h f prefix-command-preserve-state RET'.
>
> 5. Click `mouse-2' on the file name `simple.el' in buffer `*Help*'.
>
> CRASH!

No crash here, just takes some time to execute.  Tested with release and
master.  The recipe seems contrived.  ‘fit-frame-same-row-windows’ and
‘fit-frame-same-column-windows’ are nowhere used, IIUC.  All you do is
find the number of lines and the maximum number of columns of any line
of simple.el.  Why on earth should that crash?

martin

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 24692 <at> debbugs.gnu.org
Subject: Re: bug#24692: 25.1;
 simple, reproducible Emacs 25.1 crash on MS Windows
Date: Fri, 14 Oct 2016 20:20:34 +0300

> Date: Fri, 14 Oct 2016 09:39:29 -0700 (PDT)
> From: Drew Adams <drew.adams <at> oracle.com>
> 
> I spent many hours narrowing this down.  I'm hoping that that time won't
> have been wasted. ;-)

Thank you for your efforts.

> 1. Save the attached file, `e25-crash.el'.
> 
> 2. runemacs.exe -Q --debug-init -l "/YOUR/PATH/TO/e25-crash.el
> 
> You will get two frames, one with buffer *scratch*, the other with the
> minibuffer, buffer *Minibuf-0*.
> 
> 3. Click the title bar of the frame having buffer *scratch*, to raise
> and select it.
> 
> 4. `C-h f prefix-command-preserve-state RET'.
> 
> 5. Click `mouse-2' on the file name `simple.el' in buffer `*Help*'.
> 
> CRASH!

It doesn't crash for me here, but my build is a 32-bit build.  Can
anyone else reproduce this?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 24692 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#24692: 25.1;
 simple, reproducible Emacs 25.1 crash on MS Windows
Date: Fri, 14 Oct 2016 20:26:16 +0300

> Date: Fri, 14 Oct 2016 19:13:03 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> 
> No crash here, just takes some time to execute.  Tested with release and
> master.

Same here.

But isn't it strange that it takes so long to show the source after
the mouse-2 click?  If you do the same in "emacs -Q", the source comes
up much faster.  Does the code in e25-crash explain that?

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

From: Drew Adams <drew.adams <at> oracle.com>
To: martin rudalics <rudalics <at> gmx.at>, 24692 <at> debbugs.gnu.org
Subject: RE: bug#24692: 25.1; simple, reproducible Emacs 25.1 crash on MS
 Windows
Date: Fri, 14 Oct 2016 10:51:15 -0700 (PDT)

> No crash here, just takes some time to execute.  Tested with release and
> master.  The recipe seems contrived.  ‘fit-frame-same-row-windows’ and
> ‘fit-frame-same-column-windows’ are nowhere used, IIUC.  All you do is
> find the number of lines and the maximum number of columns of any line
> of simple.el.  Why on earth should that crash?

The recipe seems "contrived"?  Of course it is contrived.
I narrowed down tons of code to this simple recipe.

And yes, I forgot to finally remove those two functions, when
I had it narrowed down.  As you noted, you can completely
remove them.  This is thus sufficient to crash Emacs 100% of
the time (on my system):

(defun fit-frame (frame)
  (save-window-excursion
    (select-frame frame)
    (let ((win-cons (fit-frame-max-window-size (selected-window))))
      (cons (car win-cons) (cdr win-cons)))))

(defun fit-frame-max-window-size (window)
  (select-window window)
  (let ((max-win-width  0)
        (max-win-height 1))
    (save-excursion
      (set-buffer (window-buffer))
      (goto-char (point-min))
      (while (not (eobp))
        (end-of-line)
        (setq max-win-width  (max (current-column) max-win-width))
        (when (zerop (forward-line 1))
          (setq max-win-height  (1+ max-win-height)))))
    (cons max-win-width max-win-height)))

(setq pop-up-frames  t)
(let ((after-make-frame-functions  ())) (make-frame '((minibuffer . only))))
(add-hook 'after-make-frame-functions 'fit-frame)

As for "Why on earth should that crash?"  Why indeed?  The answer
seems to be "Because Emacs 25" - it does not crash in Emacs 20
through 24.5.

You can use a different command, such as `digit-argument', for
`C-h f', since `prefix-command-preserve-state' does not exist
in previous releases.  (`digit-argument' will also crash Emacs
25.)  Note, BTW, that even though Emacs 24.5 does not crash, it
does take a long time to show `simple.el'.

Note too that the time it takes Emacs 25 to crash, after clicking
`simple.el', seems variable - but it always crashes.  There is
always a period when you see a blank `simple.el' frame, before
the crash, but sometimes the crash comes more quickly than other
times.

This makes me think that the actual crash occurs elsewhere from
where the bug is manifested - e.g. eventually trying to access
an improper memory location.  (Just a hunch, and likely not very
helpful.)

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24692 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#24692: 25.1; simple, reproducible Emacs 25.1 crash on MS
 Windows
Date: Fri, 14 Oct 2016 19:52:47 +0200

> But isn't it strange that it takes so long to show the source after
> the mouse-2 click?  If you do the same in "emacs -Q", the source comes
> up much faster.  Does the code in e25-crash explain that?

Scanning simple.el as ‘fit-frame-max-window-size’ does takes about 30
seconds here - with a "cold cache" (font-locking).

martin

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24692 <at> debbugs.gnu.org
Subject: RE: bug#24692: 25.1; simple, reproducible Emacs 25.1 crash on MS
 Windows
Date: Fri, 14 Oct 2016 10:57:39 -0700 (PDT)

> It doesn't crash for me here, but my build is a 32-bit build.  Can
> anyone else reproduce this?

It crashes for me systematically also with a 32-bit Emacs 25
build, such as this one (the most recent one I have):

In GNU Emacs 25.0.94.2 (x86_64-w64-mingw32)
 of 2016-05-25 built on KAEL
Windowing system distributor 'Microsoft Corp.', version 6.1.7601
Configured using:
 'configure --prefix=/tmp/emacs --without-imagemagick 'CFLAGS=-O2
 -fomit-frame-pointer -g0''

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

From: martin rudalics <rudalics <at> gmx.at>
To: Drew Adams <drew.adams <at> oracle.com>, 24692 <at> debbugs.gnu.org
Subject: Re: bug#24692: 25.1; simple, reproducible Emacs 25.1 crash on MS
 Windows
Date: Fri, 14 Oct 2016 20:05:25 +0200

> The recipe seems "contrived"?  Of course it is contrived.
> I narrowed down tons of code to this simple recipe.

A simple recipe would be to run

(defun foo ()
  ""
  (interactive)
  (let ((max-win-width  0)
        (max-win-height 1))
    (save-excursion
      (goto-char (point-min))
      (while (not (eobp))
        (end-of-line)
        (setq max-win-width  (max (current-column) max-win-width))
        (when (zerop (forward-line 1))
          (setq max-win-height  (1+ max-win-height)))))
    (cons max-win-width max-win-height)))

on simple.el.  Does that crash?

> As for "Why on earth should that crash?"  Why indeed?  The answer
> seems to be "Because Emacs 25" - it does not crash in Emacs 20
> through 24.5.
>
> You can use a different command, such as `digit-argument', for
> `C-h f', since `prefix-command-preserve-state' does not exist
> in previous releases.  (`digit-argument' will also crash Emacs
> 25.)  Note, BTW, that even though Emacs 24.5 does not crash, it
> does take a long time to show `simple.el'.

Scanning simple.el takes its time.

> Note too that the time it takes Emacs 25 to crash, after clicking
> `simple.el', seems variable - but it always crashes.  There is
> always a period when you see a blank `simple.el' frame, before
> the crash, but sometimes the crash comes more quickly than other
> times.
>
> This makes me think that the actual crash occurs elsewhere from
> where the bug is manifested - e.g. eventually trying to access
> an improper memory location.  (Just a hunch, and likely not very
> helpful.)

The only way to find out is to use the debugger.  You could try to find
out where by simply displaying the current line count during scanning.
If it always crashes at the same line, there might be a clue.  And you
could try finding simple.el _before_ evaluating your code and look what
happens.

martin

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 24692 <at> debbugs.gnu.org
Subject: RE: bug#24692: 25.1; simple, reproducible Emacs 25.1 crash on MS
 Windows
Date: Fri, 14 Oct 2016 11:07:35 -0700 (PDT)

Here's some more info, regarding thoughts that the file size
is the problem:

1. It crashes also if I do `M-x find-library simple', so
   the crash does not seem to have anything to do with
   clicking the link in *Help*.  I should have mentioned
   this earlier.

2. It does not crash if I use another large library, such
   as `icicles-cmd1.el'.  That library has nearly twice as
   many lines as `simple.el' and 10918 lines instead of
   8699 for `simple.el'.

A guess (without yet looking) might be that there are some
special chars in `simple.el' that slow things down?

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

From: Drew Adams <drew.adams <at> oracle.com>
To: martin rudalics <rudalics <at> gmx.at>, 24692 <at> debbugs.gnu.org
Subject: RE: bug#24692: 25.1; simple, reproducible Emacs 25.1 crash on MS
 Windows
Date: Fri, 14 Oct 2016 11:10:30 -0700 (PDT)

> A simple recipe would be to run
> 
> (defun foo ()
>    ""
>    (interactive)
>    (let ((max-win-width  0)
>          (max-win-height 1))
>      (save-excursion
>        (goto-char (point-min))
>        (while (not (eobp))
>          (end-of-line)
>          (setq max-win-width  (max (current-column) max-win-width))
>          (when (zerop (forward-line 1))
>            (setq max-win-height  (1+ max-win-height)))))
>      (cons max-win-width max-win-height)))
> 
> on simple.el.  Does that crash?

Yes.

With emacs -Q, I visit simple.el and M-x foo crashes.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Drew Adams <drew.adams <at> oracle.com>, 24692 <at> debbugs.gnu.org
Subject: Re: bug#24692: 25.1; simple, reproducible Emacs 25.1 crash on MS
 Windows
Date: Fri, 14 Oct 2016 20:16:08 +0200

>> A simple recipe would be to run
>>
>> (defun foo ()
>>     ""
>>     (interactive)
>>     (let ((max-win-width  0)
>>           (max-win-height 1))
>>       (save-excursion
>>         (goto-char (point-min))
>>         (while (not (eobp))

Then put a message reporting ‘max-win-height’ in here.

>>           (end-of-line)
>>           (setq max-win-width  (max (current-column) max-win-width))
>>           (when (zerop (forward-line 1))
>>             (setq max-win-height  (1+ max-win-height)))))
>>       (cons max-win-width max-win-height)))
>>
>> on simple.el.  Does that crash?
>
> Yes.
>
> With emacs -Q, I visit simple.el and M-x foo crashes.

martin

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Drew Adams <drew.adams <at> oracle.com>, martin rudalics <rudalics <at> gmx.at>,
 24692 <at> debbugs.gnu.org
Subject: RE: bug#24692: 25.1; simple, reproducible Emacs 25.1 crash on MS
 Windows
Date: Fri, 14 Oct 2016 11:24:07 -0700 (PDT)

emacs -Q
M-x find-library simple
M-x goto-line 3000
Then use down arrow to move to the next line, 3001.
Repeat, keeping an eye on the line # in the mode line.
Emacs crashes after 3032 (i.e., for line 3033).

(Also, if at step 3 you try goto-line 3020 it crashes.)

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

From: Drew Adams <drew.adams <at> oracle.com>
To: martin rudalics <rudalics <at> gmx.at>, 24692 <at> debbugs.gnu.org
Subject: RE: bug#24692: 25.1; simple, reproducible Emacs 25.1 crash on MS
 Windows
Date: Fri, 14 Oct 2016 11:28:03 -0700 (PDT)

> put a message reporting ‘max-win-height’ in here.

Last message before the crash shows 3036.
(I did the same using a line counter, too.)

See my previous message, which seems to point to line 3033.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: rudalics <at> gmx.at, 24692 <at> debbugs.gnu.org
Subject: Re: bug#24692: 25.1;
 simple, reproducible Emacs 25.1 crash on MS Windows
Date: Fri, 14 Oct 2016 21:51:10 +0300

> Date: Fri, 14 Oct 2016 11:24:07 -0700 (PDT)
> From: Drew Adams <drew.adams <at> oracle.com>
> 
> emacs -Q
> M-x find-library simple
> M-x goto-line 3000
> Then use down arrow to move to the next line, 3001.
> Repeat, keeping an eye on the line # in the mode line.
> Emacs crashes after 3032 (i.e., for line 3033).
> 
> (Also, if at step 3 you try goto-line 3020 it crashes.)

Then it's just another manifestation of bug#23935, which was left
unsolved because no one else was able/willing to reproduce it under a
debugger and present the debugging data.  The
password-word-equivalents defcustom has a bunch of fancy Unicode
characters, which probably cause the same problem as "C-h H" did on
your system.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: rudalics <at> gmx.at, 24692 <at> debbugs.gnu.org
Subject: Re: bug#24692: 25.1;
 simple, reproducible Emacs 25.1 crash on MS Windows
Date: Fri, 14 Oct 2016 22:04:45 +0300

> Date: Fri, 14 Oct 2016 11:28:03 -0700 (PDT)
> From: Drew Adams <drew.adams <at> oracle.com>
> 
> > put a message reporting ‘max-win-height’ in here.
> 
> Last message before the crash shows 3036.
> (I did the same using a line counter, too.)
> 
> See my previous message, which seems to point to line 3033.

No, the problematic part for you starts on line 3094.  It's just that
moving past line 3032 causes Emacs to display the portion of the
buffer that includes the problematic part.  IOW, the crash is
something caused by redisplay.

Previous Next

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