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