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.