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 <(214)%20748-3647>) 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
-- 

Kaushal Modi