GNU bug report logs - #29326
26.0.90; Emacs crash on running comment-dwim

Previous Next

Package: emacs;

Reported by: Kaushal Modi <kaushal.modi <at> gmail.com>

Date: Thu, 16 Nov 2017 19:44:02 UTC

Severity: normal

Found in version 26.0.90

Done: Kaushal Modi <kaushal.modi <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kaushal Modi <kaushal.modi <at> gmail.com>
Cc: 29326 <at> debbugs.gnu.org, npostavs <at> users.sourceforge.net
Subject: bug#29326: 26.0.90; Emacs crash on running comment-dwim
Date: Fri, 17 Nov 2017 21:46:58 +0200
> From: Kaushal Modi <kaushal.modi <at> gmail.com>
> Date: Fri, 17 Nov 2017 18:36:32 +0000
> Cc: 29326 <at> debbugs.gnu.org
> 
> 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:

> xdisp.c:2752: Emacs fatal error: assertion failed: charpos < 0 || (charpos >= BUF_BEG (current_buffer) &&
> charpos <= ZV)
> 
> 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.

> Lisp Backtrace:
> "line-number-display-width" (0xffff37e0)
> "line-move-visual" (0xffff4030)
> "line-move" (0xffff4780)
> "let" (0xffff4b80)
> "condition-case" (0xffff4e70)
> "nim-line-move" (0xffff5030)

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

> Org is displaying the nim-mode buffers in org-mode, but does something like enabling the code block's major
> mode only for that code snippet to do indentation, commenting etc. (the native line number enabling would be
> a part of that I believe).

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.




This bug report was last modified 7 years and 187 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.