bug#24692: 25.1; simple, reproducible Emacs 25.1 crash on MS Windows

bug#24692: 25.1; simple, reproducible Emacs 25.1 crash on MS Windows

[Drew Adams]

[-- Attachment #1: Type: text/plain, Size: 1052 bytes --]

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'

[-- Attachment #2: e25-crash.el --]
[-- Type: application/octet-stream, Size: 1662 bytes --]

;; 1. Save attached file `e25-crash.el'.
;; 2. runemacs.exe -Q --debug-init -l "/YOUR/PATH/TO/e25-crash.el
;; 3. `C-h f prefix-command-preserve-state'
;; 4. Click the file name `simple.el' in buffer `*Help*'
;;
;; CRASH!!!!!!!!!!

(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-same-row-windows (wins window exclude)
  ""
  (let ((ref-bottom  (cadr (cddr (window-edges window))))
        (row-wins    ()))
    (dolist (win wins)
      (when (and (not (memq win exclude))  (< (cadr (window-edges win)) ref-bottom))
        (push win row-wins)))
    row-wins))

(defun fit-frame-same-column-windows (wins window exclude)
  ""
  (let ((ref-right  (car (cddr (window-edges window))))
        (col-wins   ()))
    (dolist (win wins)
      (when (and (not (memq win exclude))  (< (car (window-edges win)) ref-right))
        (push win col-wins)))
    col-wins))

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

bug#24692: 25.1; simple, reproducible Emacs 25.1 crash on MS Windows

[martin rudalics]

 > 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

bug#24692: 25.1; simple, reproducible Emacs 25.1 crash on MS Windows

[Eli Zaretskii]

> Date: Fri, 14 Oct 2016 09:39:29 -0700 (PDT)
> From: Drew Adams <drew.adams@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?

bug#24692: 25.1; simple, reproducible Emacs 25.1 crash on MS Windows

[Eli Zaretskii]

> Date: Fri, 14 Oct 2016 19:13:03 +0200
> From: martin rudalics <rudalics@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?

bug#24692: 25.1; simple, reproducible Emacs 25.1 crash on MS Windows

[Drew Adams]

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

bug#24692: 25.1; simple, reproducible Emacs 25.1 crash on MS Windows

[martin rudalics]

 > 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

bug#24692: 25.1; simple, reproducible Emacs 25.1 crash on MS Windows

[Drew Adams]

> 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''

bug#24692: 25.1; simple, reproducible Emacs 25.1 crash on MS Windows

[martin rudalics]

 > 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

bug#24692: 25.1; simple, reproducible Emacs 25.1 crash on MS Windows

[Drew Adams]

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?

bug#24692: 25.1; simple, reproducible Emacs 25.1 crash on MS Windows

[Drew Adams]

> 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.

bug#24692: 25.1; simple, reproducible Emacs 25.1 crash on MS Windows

[martin rudalics]

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

bug#24692: 25.1; simple, reproducible Emacs 25.1 crash on MS Windows

[Drew Adams]

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

bug#24692: 25.1; simple, reproducible Emacs 25.1 crash on MS Windows

[Drew Adams]

> 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.

bug#24692: 25.1; simple, reproducible Emacs 25.1 crash on MS Windows

[Eli Zaretskii]

> Date: Fri, 14 Oct 2016 11:24:07 -0700 (PDT)
> From: Drew Adams <drew.adams@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.

bug#24692: 25.1; simple, reproducible Emacs 25.1 crash on MS Windows

[Eli Zaretskii]

> Date: Fri, 14 Oct 2016 11:28:03 -0700 (PDT)
> From: Drew Adams <drew.adams@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.