On Fri, Nov 17, 2017 at 2:47 PM Eli Zaretskii <eliz@gnu.org> wrote:

> Also by running the gdb in the src/ dir, the backtrace looks a bit different (instead of SIGABRT plus putting out
> core dump in gdb, this time the error is concise and code is SIG_DFL
> instead)

No, it's still SIGABRT:

> Thread 1 "emacs" hit Breakpoint 1, terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:364
^^^^^^^

"sig=6" means SIGABRT (you can see that in your system's header files,
probably in /usr/include/bits/signum.h).

> 364 signal (sig, SIG_DFL);

This just shows the source line where Emacs stopped due to the fatal
signal. It has nothing to do with the signal itself.

Thanks for that explanation.

Thanks, I installed a change which should fix this. Please try the
latest release branch.

That's a bulls-eye fix! Rebuilt from emacs-26 HEAD, and now C-x ; causes no more crashes in that test file.

Thanks!

Org copies the snippet to a separate buffer, turns on nim-mode in that
buffer, then indents the text, and finally copies the text back. The
problem happened because the window-start position was not updated
during this dance, and still had the value suitable to the Org buffer,
which is outside of the valid positions in the temporary edit buffer.

I would have thought it is quite common to comment this way in src blocks in Org files.. also what's surprising that this crash happened only when doing C-x ; after a particular line.. and that "particular line" happens to be after Org fontification regexp starts misbehaving[1]. So I am not sure that that Org fontification bug had anything to do with this crash.

I am closing this bug as DONE; thanks again! But I'd love to learn more on the above mystery.. on why this crash just showed up and why it's not common.

[1]: http://lists.gnu.org/archive/html/emacs-orgmode/2017-11/msg00202.html