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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 29326 in the body.
You can then email your comments to 29326 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Kaushal Modi <kaushal.modi <at> gmail.com>
To: "bug-gnu-emacs <at> gnu.org" <bug-gnu-emacs <at> gnu.org>
Subject: 26.0.90; Emacs crash on running comment-dwim
Date: Thu, 16 Nov 2017 19:43:00 +0000

[Message part 1 (text/plain, inline)]

Hello,

All of a sudden I can get emacs to crash consistently because of some rogue
font lock regexp parsing between Org mode and nim-mode[1].

I have attached a test file (that's the smallest I can get to from
originally ~1000 line file). I can make the crash happen on doing M-x
comment-dwim on line 69 (in the test.org file) but not on line 52 and
earlier lines for example.

[1]: https://github.com/nim-lang/nim-mode

It will be tricky to get an emacs -Q recipe with org and nim-mode
dependencies. So while I work on getting that recipe, does the below
backtrace help?

=====
Thread 1 "emacs" received signal SIGABRT, Aborted.
0x00000033e380f6ab in raise () from /lib64/libpthread.so.0
(gdb) bt
#0  0x00000033e380f6ab in raise () from /lib64/libpthread.so.0
#1  0x000000000058c8f4 in terminate_due_to_signal (sig=6,
backtrace_limit=2147483647) at emacs.c:394
#2  0x00000000006232d5 in die (msg=0x723428 "charpos < 0 || (charpos >=
BUF_BEG (current_buffer) && charpos <= ZV)", file=0x72313d "xdisp.c",
line=2752) at alloc.c:7419
#3  0x0000000000449caa in init_iterator (it=0x7fffffff22f0, w=0x888fb60,
charpos=9982, bytepos=9982, row=0x7d9e430, base_face_id=DEFAULT_FACE_ID) at
xdisp.c:2751
#4  0x000000000044af1b in start_display (it=0x7fffffff22f0, w=0x888fb60,
pos=...) at xdisp.c:3060
#5  0x00000000005f8e41 in line_number_display_width (w=0x888fb60,
width=0x7fffffff366c, pixel_width=0x7fffffff3668) at indent.c:1976
#6  0x00000000005f8efa in Fline_number_display_width (pixelwise=...) at
indent.c:2007
#7  0x000000000064ab54 in funcall_subr (subr=0x9dca60
<Sline_number_display_width>, numargs=1, args=0x7fffffff37f0) at eval.c:2841
#8  0x000000000064a6ab in Ffuncall (nargs=2, args=0x7fffffff37e8) at
eval.c:2766
#9  0x000000000069f6c7 in exec_byte_code (bytestr=..., vector=...,
maxdepth=..., args_template=..., nargs=2, args=0x7fffffff4050) at
bytecode.c:629
#10 0x000000000064b2bd in funcall_lambda (fun=..., nargs=2,
arg_vector=0x7fffffff4040) at eval.c:2967
#11 0x000000000064a6ef in Ffuncall (nargs=3, args=0x7fffffff4038) at
eval.c:2768
#12 0x000000000069f6c7 in exec_byte_code (bytestr=..., vector=...,
maxdepth=..., args_template=..., nargs=2, args=0x7fffffff47a0) at
bytecode.c:629
#13 0x000000000064b2bd in funcall_lambda (fun=..., nargs=2,
arg_vector=0x7fffffff4790) at eval.c:2967
#14 0x000000000064aef9 in apply_lambda (fun=..., args=..., count=58) at
eval.c:2903
#15 0x000000000064910b in eval_sub (form=...) at eval.c:2276
#16 0x00000000006439af in Fprogn (body=...) at eval.c:455
#17 0x0000000000645977 in Flet (args=...) at eval.c:969
#18 0x0000000000648ae4 in eval_sub (form=...) at eval.c:2183
#19 0x0000000000646801 in internal_lisp_condition_case (var=...,
bodyform=..., handlers=...) at eval.c:1303
#20 0x0000000000646293 in Fcondition_case (args=...) at eval.c:1227
#21 0x0000000000648ae4 in eval_sub (form=...) at eval.c:2183
#22 0x00000000006439af in Fprogn (body=...) at eval.c:455
#23 0x000000000064b729 in funcall_lambda (fun=..., nargs=1, arg_vector=0x0)
at eval.c:3042
#24 0x000000000064aef9 in apply_lambda (fun=..., args=..., count=53) at
eval.c:2903
#25 0x0000000000649312 in eval_sub (form=...) at eval.c:2306
#26 0x0000000000648e44 in eval_sub (form=...) at eval.c:2219
#27 0x00000000006436f6 in Fif (args=...) at eval.c:407
#28 0x0000000000648ae4 in eval_sub (form=...) at eval.c:2183
#29 0x00000000006439af in Fprogn (body=...) at eval.c:455
#30 0x0000000000648ae4 in eval_sub (form=...) at eval.c:2183
#31 0x0000000000643754 in Fif (args=...) at eval.c:410
#32 0x0000000000648ae4 in eval_sub (form=...) at eval.c:2183
#33 0x00000000006439af in Fprogn (body=...) at eval.c:455
#34 0x00000000006323d0 in Fsave_excursion (args=...) at editfns.c:1050
#35 0x0000000000648ae4 in eval_sub (form=...) at eval.c:2183
#36 0x00000000006439af in Fprogn (body=...) at eval.c:455
#37 0x0000000000645dd1 in internal_catch (tag=..., func=0x64390f <Fprogn>,
arg=...) at eval.c:1097
#38 0x0000000000645d85 in Fcatch (args=...) at eval.c:1074
#39 0x0000000000648ae4 in eval_sub (form=...) at eval.c:2183
#40 0x00000000006439af in Fprogn (body=...) at eval.c:455
#41 0x000000000064b729 in funcall_lambda (fun=..., nargs=1, arg_vector=0x0)
at eval.c:3042
#42 0x000000000064aef9 in apply_lambda (fun=..., args=..., count=44) at
eval.c:2903
#43 0x0000000000649312 in eval_sub (form=...) at eval.c:2306
#44 0x00000000006435a3 in For (args=...) at eval.c:368
#45 0x0000000000648ae4 in eval_sub (form=...) at eval.c:2183
#46 0x00000000006436f6 in Fif (args=...) at eval.c:407
#47 0x0000000000648ae4 in eval_sub (form=...) at eval.c:2183
#48 0x00000000006439af in Fprogn (body=...) at eval.c:455
#49 0x0000000000645977 in Flet (args=...) at eval.c:969
#50 0x0000000000648ae4 in eval_sub (form=...) at eval.c:2183
#51 0x00000000006439af in Fprogn (body=...) at eval.c:455
#52 0x00000000006323d0 in Fsave_excursion (args=...) at editfns.c:1050
#53 0x0000000000648ae4 in eval_sub (form=...) at eval.c:2183
#54 0x00000000006439af in Fprogn (body=...) at eval.c:455
#55 0x000000000064b729 in funcall_lambda (fun=..., nargs=0, arg_vector=0x0)
at eval.c:3042
#56 0x000000000064aef9 in apply_lambda (fun=..., args=..., count=37) at
eval.c:2903
#57 0x0000000000649312 in eval_sub (form=...) at eval.c:2306
#58 0x0000000000648e44 in eval_sub (form=...) at eval.c:2219
#59 0x0000000000648cda in eval_sub (form=...) at eval.c:2197
#60 0x0000000000643c68 in Fsetq (args=...) at eval.c:513
#61 0x0000000000648ae4 in eval_sub (form=...) at eval.c:2183
#62 0x00000000006439af in Fprogn (body=...) at eval.c:455
---Type <return> to continue, or q <return> to quit---
#63 0x000000000064b729 in funcall_lambda (fun=..., nargs=0, arg_vector=0x0)
at eval.c:3042
#64 0x000000000064aef9 in apply_lambda (fun=..., args=..., count=32) at
eval.c:2903
#65 0x0000000000649312 in eval_sub (form=...) at eval.c:2306
#66 0x0000000000643679 in Fand (args=...) at eval.c:389
#67 0x0000000000648ae4 in eval_sub (form=...) at eval.c:2183
#68 0x0000000000645243 in FletX (args=...) at eval.c:876
#69 0x0000000000648ae4 in eval_sub (form=...) at eval.c:2183
#70 0x00000000006439af in Fprogn (body=...) at eval.c:455
#71 0x000000000064b729 in funcall_lambda (fun=..., nargs=1, arg_vector=0x0)
at eval.c:3042
#72 0x000000000064aef9 in apply_lambda (fun=..., args=..., count=28) at
eval.c:2903
#73 0x0000000000649312 in eval_sub (form=...) at eval.c:2306
#74 0x0000000000643679 in Fand (args=...) at eval.c:389
#75 0x0000000000648ae4 in eval_sub (form=...) at eval.c:2183
#76 0x0000000000645243 in FletX (args=...) at eval.c:876
#77 0x0000000000648ae4 in eval_sub (form=...) at eval.c:2183
#78 0x00000000006439af in Fprogn (body=...) at eval.c:455
#79 0x00000000006323d0 in Fsave_excursion (args=...) at editfns.c:1050
#80 0x0000000000648ae4 in eval_sub (form=...) at eval.c:2183
#81 0x00000000006439af in Fprogn (body=...) at eval.c:455
#82 0x0000000000645977 in Flet (args=...) at eval.c:969
#83 0x0000000000648ae4 in eval_sub (form=...) at eval.c:2183
#84 0x00000000006439af in Fprogn (body=...) at eval.c:455
#85 0x000000000064b729 in funcall_lambda (fun=..., nargs=1, arg_vector=0x0)
at eval.c:3042
#86 0x000000000064aef9 in apply_lambda (fun=..., args=..., count=20) at
eval.c:2903
#87 0x0000000000649312 in eval_sub (form=...) at eval.c:2306
#88 0x00000000006439af in Fprogn (body=...) at eval.c:455
#89 0x000000000064b729 in funcall_lambda (fun=..., nargs=0, arg_vector=0x0)
at eval.c:3042
#90 0x000000000064a7f1 in Ffuncall (nargs=1, args=0x7fffffff8658) at
eval.c:2780
#91 0x000000000069f6c7 in exec_byte_code (bytestr=..., vector=...,
maxdepth=..., args_template=..., nargs=0, args=0x7fffffff8db0) at
bytecode.c:629
#92 0x000000000064b2bd in funcall_lambda (fun=..., nargs=0,
arg_vector=0x7fffffff8db0) at eval.c:2967
#93 0x000000000064a6ef in Ffuncall (nargs=1, args=0x7fffffff8da8) at
eval.c:2768
#94 0x000000000069f6c7 in exec_byte_code (bytestr=..., vector=...,
maxdepth=..., args_template=..., nargs=1, args=0x7fffffff9658) at
bytecode.c:629
#95 0x000000000064b2bd in funcall_lambda (fun=..., nargs=1,
arg_vector=0x7fffffff9650) at eval.c:2967
#96 0x000000000064a6ef in Ffuncall (nargs=2, args=0x7fffffff9648) at
eval.c:2768
#97 0x00000000006403df in Ffuncall_interactively (nargs=2,
args=0x7fffffff9648) at callint.c:252
#98 0x000000000064aa62 in funcall_subr (subr=0xd84260
<Sfuncall_interactively>, numargs=2, args=0x7fffffff9648) at eval.c:2821
#99 0x000000000064a6ab in Ffuncall (nargs=3, args=0x7fffffff9640) at
eval.c:2766
#100 0x0000000000642951 in Fcall_interactively (function=...,
record_flag=..., keys=...) at callint.c:841
#101 0x000000000064aba1 in funcall_subr (subr=0xd842a0
<Scall_interactively>, numargs=1, args=0x7fffffff9b08) at eval.c:2846
#102 0x000000000064a6ab in Ffuncall (nargs=2, args=0x7fffffff9b00) at
eval.c:2766
#103 0x000000000069f6c7 in exec_byte_code (bytestr=..., vector=...,
maxdepth=..., args_template=..., nargs=1, args=0x7fffffffa378) at
bytecode.c:629
#104 0x000000000064b2bd in funcall_lambda (fun=..., nargs=1,
arg_vector=0x7fffffffa370) at eval.c:2967
#105 0x000000000064a6ef in Ffuncall (nargs=2, args=0x7fffffffa368) at
eval.c:2768
#106 0x00000000006403df in Ffuncall_interactively (nargs=2,
args=0x7fffffffa368) at callint.c:252
#107 0x000000000064aa62 in funcall_subr (subr=0xd84260
<Sfuncall_interactively>, numargs=2, args=0x7fffffffa368) at eval.c:2821
#108 0x000000000064a6ab in Ffuncall (nargs=3, args=0x7fffffffa360) at
eval.c:2766
#109 0x0000000000642951 in Fcall_interactively (function=...,
record_flag=..., keys=...) at callint.c:841
#110 0x000000000064aba1 in funcall_subr (subr=0xd842a0
<Scall_interactively>, numargs=3, args=0x7fffffffa850) at eval.c:2846
#111 0x000000000064a6ab in Ffuncall (nargs=4, args=0x7fffffffa848) at
eval.c:2766
#112 0x000000000069f6c7 in exec_byte_code (bytestr=..., vector=...,
maxdepth=..., args_template=..., nargs=1, args=0x7fffffffb040) at
bytecode.c:629
#113 0x000000000064b2bd in funcall_lambda (fun=..., nargs=1,
arg_vector=0x7fffffffb038) at eval.c:2967
#114 0x000000000064a6ef in Ffuncall (nargs=2, args=0x7fffffffb030) at
eval.c:2768
#115 0x0000000000649fa8 in call1 (fn=..., arg1=...) at eval.c:2617
#116 0x0000000000591dad in command_loop_1 () at keyboard.c:1482
#117 0x000000000064689d in internal_condition_case (bfun=0x5915d0
<command_loop_1>, handlers=..., hfun=0x590c26 <cmd_error>) at eval.c:1332
#118 0x00000000005911d5 in command_loop_2 (ignore=...) at keyboard.c:1110
#119 0x0000000000645dd1 in internal_catch (tag=..., func=0x5911ac
<command_loop_2>, arg=...) at eval.c:1097
#120 0x0000000000591177 in command_loop () at keyboard.c:1089
#121 0x000000000059073b in recursive_edit_1 () at keyboard.c:695
#122 0x000000000059091a in Frecursive_edit () at keyboard.c:766
#123 0x000000000058e617 in main (argc=1, argv=0x7fffffffb538) at
emacs.c:1713
=====

In GNU Emacs 26.0.90 (build 13, x86_64-pc-linux-gnu, GTK+ Version 2.24.23)
 of 2017-11-16
Repository revision: 720322aab8cd8ffc24481f280c3acf60efdbc28b
Windowing system distributor 'The X.Org Foundation', version 11.0.60900000
System Description: Red Hat Enterprise Linux Workstation release 6.6
(Santiago)

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
GNU Emacs 26.0.90 (build 13, x86_64-pc-linux-gnu, GTK+ Version 2.24.23) of
2017-11-16

Configured using:
 'configure --with-modules
 --prefix=/home/kmodi/usr_local/apps/6/emacs/emacs-26
 '--program-transform-name=s/^ctags$/ctags_emacs/'
 --enable-checking=yes,glyphs --enable-check-lisp-object-type
 'CPPFLAGS=-I/home/kmodi/usr_local/6/include -I/usr/include/freetype2
 -I/usr/include' 'CFLAGS=-ggdb3 -O0' 'CXXFLAGS=-ggdb3 -O0'
 'LDFLAGS=-L/home/kmodi/usr_local/6/lib -L/home/kmodi/usr_local/6/lib64
 -ggdb3''

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS NOTIFY
ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK2 X11 MODULES

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=none
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny seq byte-opt gv
bytecomp byte-compile cconv cl-loaddefs cl-lib dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg
epg-config gnus-util rmail rmail-loaddefs mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils elec-pair time-date
mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode elisp-mode lisp-mode prog-mode register page menu-bar
rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core term/tty-colors frame cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote dbusbind inotify
dynamic-setting system-font-setting font-render-setting move-toolbar gtk
x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 96668 5900)
 (symbols 48 20863 1)
 (miscs 40 42 94)
 (strings 32 28740 1175)
 (string-bytes 1 765224)
 (vectors 16 14889)
 (vector-slots 8 511550 7362)
 (floats 8 49 68)
 (intervals 56 233 0)
 (buffers 992 11)
 (heap 1024 35228 805))

-- 

Kaushal Modi

[Message part 2 (text/html, inline)]

[test.org (application/octet-stream, attachment)]

Message #8 received at 29326 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kaushal Modi <kaushal.modi <at> gmail.com>
Cc: 29326 <at> debbugs.gnu.org
Subject: Re: bug#29326: 26.0.90; Emacs crash on running comment-dwim
Date: Fri, 17 Nov 2017 09:03:52 +0200

> From: Kaushal Modi <kaushal.modi <at> gmail.com>
> Date: Thu, 16 Nov 2017 19:43:00 +0000
> 
> All of a sudden I can get emacs to crash consistently because of some rogue font lock regexp parsing
> between Org mode and nim-mode[1].
> 
> I have attached a test file (that's the smallest I can get to from originally ~1000 line file). I can make the crash
> happen on doing M-x comment-dwim on line 69 (in the test.org file) but not on line 52 and earlier lines for
> example.
> 
> [1]: https://github.com/nim-lang/nim-mode
> 
> It will be tricky to get an emacs -Q recipe with org and nim-mode dependencies. So while I work on getting
> that recipe, does the below backtrace help?

The backtrace says that some Lisp changed the buffer contents in a
way that caused the window-start to become outside the accessible
portion of the buffer.

> Thread 1 "emacs" received signal SIGABRT, Aborted.
> 0x00000033e380f6ab in raise () from /lib64/libpthread.so.0
> (gdb) bt
> #0  0x00000033e380f6ab in raise () from /lib64/libpthread.so.0
> #1  0x000000000058c8f4 in terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:394
> #2  0x00000000006232d5 in die (msg=0x723428 "charpos < 0 || (charpos >= BUF_BEG (current_buffer) &&
> charpos <= ZV)", file=0x72313d "xdisp.c", line=2752) at alloc.c:7419
> #3  0x0000000000449caa in init_iterator (it=0x7fffffff22f0, w=0x888fb60, charpos=9982, bytepos=9982,
> row=0x7d9e430, base_face_id=DEFAULT_FACE_ID) at xdisp.c:2751

In this call frame #3, what is the value of ZV?

Message #11 received at 29326 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: kaushal.modi <at> gmail.com
Cc: 29326 <at> debbugs.gnu.org
Subject: Re: bug#29326: 26.0.90; Emacs crash on running comment-dwim
Date: Fri, 17 Nov 2017 09:45:52 +0200

> Date: Fri, 17 Nov 2017 09:03:52 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 29326 <at> debbugs.gnu.org
> 
> > Thread 1 "emacs" received signal SIGABRT, Aborted.
> > 0x00000033e380f6ab in raise () from /lib64/libpthread.so.0
> > (gdb) bt
> > #0  0x00000033e380f6ab in raise () from /lib64/libpthread.so.0
> > #1  0x000000000058c8f4 in terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:394
> > #2  0x00000000006232d5 in die (msg=0x723428 "charpos < 0 || (charpos >= BUF_BEG (current_buffer) &&
> > charpos <= ZV)", file=0x72313d "xdisp.c", line=2752) at alloc.c:7419
> > #3  0x0000000000449caa in init_iterator (it=0x7fffffff22f0, w=0x888fb60, charpos=9982, bytepos=9982,
> > row=0x7d9e430, base_face_id=DEFAULT_FACE_ID) at xdisp.c:2751
> 
> In this call frame #3, what is the value of ZV?

Same question about the value of Z.

Message #14 received at 29326 <at> debbugs.gnu.org (full text, mbox):

From: Kaushal Modi <kaushal.modi <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 29326 <at> debbugs.gnu.org
Subject: Re: bug#29326: 26.0.90; Emacs crash on running comment-dwim
Date: Fri, 17 Nov 2017 17:11:53 +0000

[Message part 1 (text/plain, inline)]

On Fri, Nov 17, 2017 at 2:46 AM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > In this call frame #3, what is the value of ZV?
>
> Same question about the value of Z.
>

(gdb) f 2
#2  0x00000000006232d5 in die (msg=0x723428 "charpos < 0 || (charpos >=
BUF_BEG (current_buffer) && charpos <= ZV)",
    file=0x72313d "xdisp.c", line=2752) at alloc.c:7419
7419      terminate_due_to_signal (SIGABRT, INT_MAX);
(gdb) p ZV
$1 = 263
(gdb) p charpos
No symbol "charpos" in current context.
(gdb) f 2
#2  0x00000000006232d5 in die (msg=0x723428 "charpos < 0 || (charpos >=
BUF_BEG (current_buffer) && charpos <= ZV)",
    file=0x72313d "xdisp.c", line=2752) at alloc.c:7419
7419      terminate_due_to_signal (SIGABRT, INT_MAX);
(gdb) p charpos
No symbol "charpos" in current context.

(gdb) f 3
#3  0x0000000000449caa in init_iterator (it=0x7fffffff22f0, w=0x1593770,
charpos=360, bytepos=360, row=0x7511660,
    base_face_id=DEFAULT_FACE_ID) at xdisp.c:2751
2751      eassert (charpos < 0 || (charpos >= BUF_BEG (current_buffer)
(gdb) p ZV
$2 = 263
(gdb) p Z
$3 = 263
(gdb)
-- 

Kaushal Modi

[Message part 2 (text/html, inline)]

Message #17 received at 29326 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kaushal Modi <kaushal.modi <at> gmail.com>
Cc: 29326 <at> debbugs.gnu.org
Subject: Re: bug#29326: 26.0.90; Emacs crash on running comment-dwim
Date: Fri, 17 Nov 2017 20:06:52 +0200

> From: Kaushal Modi <kaushal.modi <at> gmail.com>
> Date: Fri, 17 Nov 2017 17:11:53 +0000
> Cc: 29326 <at> debbugs.gnu.org
> 
>  > In this call frame #3, what is the value of ZV?
> 
>  Same question about the value of Z.
> 
> (gdb) f 2
> #2  0x00000000006232d5 in die (msg=0x723428 "charpos < 0 || (charpos >= BUF_BEG (current_buffer) &&
> charpos <= ZV)",
>     file=0x72313d "xdisp.c", line=2752) at alloc.c:7419
> 7419      terminate_due_to_signal (SIGABRT, INT_MAX);
> (gdb) p ZV
> $1 = 263
> (gdb) p charpos
> No symbol "charpos" in current context.
> (gdb) f 2
> #2  0x00000000006232d5 in die (msg=0x723428 "charpos < 0 || (charpos >= BUF_BEG (current_buffer) &&
> charpos <= ZV)",
>     file=0x72313d "xdisp.c", line=2752) at alloc.c:7419
> 7419      terminate_due_to_signal (SIGABRT, INT_MAX);
> (gdb) p charpos
> No symbol "charpos" in current context.
> 
> (gdb) f 3
> #3  0x0000000000449caa in init_iterator (it=0x7fffffff22f0, w=0x1593770, charpos=360, bytepos=360,
> row=0x7511660,
>     base_face_id=DEFAULT_FACE_ID) at xdisp.c:2751
> 2751      eassert (charpos < 0 || (charpos >= BUF_BEG (current_buffer)
> (gdb) p ZV
> $2 = 263
> (gdb) p Z
> $3 = 263
> (gdb) 

Thanks, I need to see the results of xbacktrace, please.

Message #20 received at 29326 <at> debbugs.gnu.org (full text, mbox):

From: Kaushal Modi <kaushal.modi <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 29326 <at> debbugs.gnu.org
Subject: Re: bug#29326: 26.0.90; Emacs crash on running comment-dwim
Date: Fri, 17 Nov 2017 18:08:48 +0000

[Message part 1 (text/plain, inline)]

On Fri, Nov 17, 2017 at 1:07 PM Eli Zaretskii <eliz <at> gnu.org> wrote:

>
> Thanks, I need to see the results of xbacktrace, please.
>

Was I supposed to type in exactly that in the gdb? It says "Undefined
command".

(gdb) p Z
$3 = 263
(gdb) xbacktrace
Undefined command: "xbacktrace".  Try "help".
(gdb)
-- 

Kaushal Modi

[Message part 2 (text/html, inline)]

Message #23 received at 29326 <at> debbugs.gnu.org (full text, mbox):

From: Kaushal Modi <kaushal.modi <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 29326 <at> debbugs.gnu.org
Subject: Re: bug#29326: 26.0.90; Emacs crash on running comment-dwim
Date: Fri, 17 Nov 2017 18:13:21 +0000

[Message part 1 (text/plain, inline)]

On Fri, Nov 17, 2017 at 1:08 PM Kaushal Modi <kaushal.modi <at> gmail.com> wrote:

> (gdb) xbacktrace
> Undefined command: "xbacktrace".  Try "help".
> (gdb)
>

Looks like that *is* the command.

Then is it possible it's related to
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29332? Let me rebuild with
http://git.savannah.gnu.org/cgit/emacs.git/commit/?h=emacs-26&id=648c128b5f5eb8988aabcc2073b706d2561acd15
..
just in case.

-- 

Kaushal Modi

[Message part 2 (text/html, inline)]

Message #26 received at 29326 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Kaushal Modi <kaushal.modi <at> gmail.com>
Cc: 29326 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#29326: 26.0.90; Emacs crash on running comment-dwim
Date: Fri, 17 Nov 2017 13:16:13 -0500

On Fri, Nov 17, 2017 at 1:13 PM, Kaushal Modi <kaushal.modi <at> gmail.com> wrote:
> On Fri, Nov 17, 2017 at 1:08 PM Kaushal Modi <kaushal.modi <at> gmail.com> wrote:
>>
>> (gdb) xbacktrace
>> Undefined command: "xbacktrace".  Try "help".
>> (gdb)
>
>
> Looks like that *is* the command.
>
> Then is it possible it's related to
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29332? Let me rebuild with
> http://git.savannah.gnu.org/cgit/emacs.git/commit/?h=emacs-26&id=648c128b5f5eb8988aabcc2073b706d2561acd15
> .. just in case.

You probably just need to do

   source src/.gdbinit

first.  See also "Configuring GDB" in etc/DEBUG.

Message #29 received at 29326 <at> debbugs.gnu.org (full text, mbox):

From: Kaushal Modi <kaushal.modi <at> gmail.com>
To: Noam Postavsky <npostavs <at> users.sourceforge.net>
Cc: 29326 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#29326: 26.0.90; Emacs crash on running comment-dwim
Date: Fri, 17 Nov 2017 18:18:51 +0000

[Message part 1 (text/plain, inline)]

On Fri, Nov 17, 2017 at 1:16 PM Noam Postavsky <
npostavs <at> users.sourceforge.net> wrote:

> You probably just need to do
>
>    source src/.gdbinit
>
> first.  See also "Configuring GDB" in etc/DEBUG.
>

Yes, I realized that.. a bit late.. I already killed that gdb session and
started emacs rebuild.

While that was going on, I happened to read:

> It is important for the directory ‘src’ to be current so that GDB will
read the
     ‘.gdbinit’ file in this directory.

in (emacs) Checklist (from here:
https://lists.gnu.org/archive/html/bug-gnu-emacs/2009-07/msg00178.html ).

Lesson learned: "gdb ./src/emacs" is not the same as "cd src; gdb ./emacs".


-- 

Kaushal Modi

[Message part 2 (text/html, inline)]

Message #32 received at 29326 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#29326: 26.0.90; Emacs crash on running comment-dwim
Date: Fri, 17 Nov 2017 20:29:52 +0200

> From: Kaushal Modi <kaushal.modi <at> gmail.com>
> Date: Fri, 17 Nov 2017 18:18:51 +0000
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 29326 <at> debbugs.gnu.org
> 
> Yes, I realized that.. a bit late.. I already killed that gdb session and started emacs rebuild.

That was a mistake, on two counts: first, you didn't need to kill the
GDB session; and second, the changes I made to fix the problem
reported by Richard didn't need Emacs to be rebuilt, because .gdbinit
does not affect the build in any way.

> Lesson learned: "gdb ./src/emacs" is not the same as "cd src; gdb ./emacs".

I think there's a more important lesson here: please do not rush to
conclusions in these matters, especially when you have a crashed Emacs
session in GDB and bump into unexpected behavior you don't understand.
Please ask your questions when things don't work as expected, and then
please wait patiently until you receive the answers, before you act.
No one expects you to do this stuff at once, and nothing bad will ever
happen if you refrain from acting until you understand completely what
you should do and how.

TIA

Message #35 received at 29326 <at> debbugs.gnu.org (full text, mbox):

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

[Message part 1 (text/plain, inline)]

On Fri, Nov 17, 2017 at 1:18 PM Kaushal Modi <kaushal.modi <at> gmail.com> wrote:

>
> Lesson learned: "gdb ./src/emacs" is not the same as "cd src; gdb ./emacs".
>

OK, with the latest emacs-26 build, I still see the same crash (which is
good.. repeatable issue).

-->> Before proceeding, I'd like to correct myself that I am using
org-comment-dwim to reproduce this error (not comment-dwim).. well the Lisp
backtrace also tells that. <<--

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), but definitely more
informative.

=====
[New Thread 0x7fffed33f700 (LWP 3158)]

(emacs:3153): GLib-GIO-CRITICAL **: g_settings_schema_source_lookup:
assertion 'source != NULL' failed

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
364       signal (sig, SIG_DFL);
(gdb) bt
#0  terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at
emacs.c:364
#1  0x00000000006232d5 in die (msg=0x723428 "charpos < 0 || (charpos >=
BUF_BEG (current_buffer) && charpos <= ZV)",
    file=0x72313d "xdisp.c", line=2752) at alloc.c:7419
#2  0x0000000000449caa in init_iterator (it=0x7fffffff22e0, w=0x1593770,
charpos=1021, bytepos=1021, row=0x654be20,
    base_face_id=DEFAULT_FACE_ID) at xdisp.c:2751
#3  0x000000000044af1b in start_display (it=0x7fffffff22e0, w=0x1593770,
pos=...) at xdisp.c:3060
#4  0x00000000005f8e41 in line_number_display_width (w=0x1593770,
width=0x7fffffff365c, pixel_width=0x7fffffff3658) at indent.c:1976
#5  0x00000000005f8efa in Fline_number_display_width
(pixelwise=XIL(0xc270)) at indent.c:2007
#6  0x000000000064ab54 in funcall_subr (subr=0x9dca60
<Sline_number_display_width>, numargs=1, args=0x7fffffff37e0) at eval.c:2841
#7  0x000000000064a6ab in Ffuncall (nargs=2, args=0x7fffffff37d8) at
eval.c:2766
#8  0x000000000069f6c7 in exec_byte_code (bytestr=XIL(0xaab99c),
vector=XIL(0xaab9bd), maxdepth=make_number(12),
    args_template=make_number(513), nargs=2, args=0x7fffffff4040) at
bytecode.c:629
#9  0x000000000064b2bd in funcall_lambda (fun=XIL(0xaab96d), nargs=2,
arg_vector=0x7fffffff4030) at eval.c:2967
#10 0x000000000064a6ef in Ffuncall (nargs=3, args=0x7fffffff4028) at
eval.c:2768
#11 0x000000000069f6c7 in exec_byte_code (bytestr=XIL(0xaab84c),
vector=XIL(0xaab86d), maxdepth=make_number(13),
    args_template=make_number(1025), nargs=2, args=0x7fffffff4790) at
bytecode.c:629
#12 0x000000000064b2bd in funcall_lambda (fun=XIL(0xaab81d), nargs=2,
arg_vector=0x7fffffff4780) at eval.c:2967
#13 0x000000000064aef9 in apply_lambda (fun=XIL(0xaab81d),
args=XIL(0x2b90163), count=58) at eval.c:2903
#14 0x000000000064910b in eval_sub (form=XIL(0x2b90173)) at eval.c:2276
#15 0x00000000006439af in Fprogn (body=XIL(0x2b90053)) at eval.c:455
#16 0x0000000000645977 in Flet (args=XIL(0x2b90183)) at eval.c:969
#17 0x0000000000648ae4 in eval_sub (form=XIL(0x2b901d3)) at eval.c:2183
#18 0x0000000000646801 in internal_lisp_condition_case (var=XIL(0),
bodyform=XIL(0x2b901d3), handlers=XIL(0x2b90013)) at eval.c:1303
#19 0x0000000000646293 in Fcondition_case (args=XIL(0x2b901e3)) at
eval.c:1227
#20 0x0000000000648ae4 in eval_sub (form=XIL(0x2b901f3)) at eval.c:2183
#21 0x00000000006439af in Fprogn (body=XIL(0)) at eval.c:455
#22 0x000000000064b729 in funcall_lambda (fun=XIL(0x2b8cd53), nargs=1,
arg_vector=0x0) at eval.c:3042
#23 0x000000000064aef9 in apply_lambda (fun=XIL(0x2b8cd43),
args=XIL(0x3d38dd3), count=53) at eval.c:2903
#24 0x0000000000649312 in eval_sub (form=XIL(0x3d38de3)) at eval.c:2306
#25 0x0000000000648e44 in eval_sub (form=XIL(0x3d38df3)) at eval.c:2219
#26 0x00000000006436f6 in Fif (args=XIL(0x3d381f3)) at eval.c:407
#27 0x0000000000648ae4 in eval_sub (form=XIL(0x3d381e3)) at eval.c:2183
#28 0x00000000006439af in Fprogn (body=XIL(0)) at eval.c:455
#29 0x0000000000648ae4 in eval_sub (form=XIL(0x3d38143)) at eval.c:2183
#30 0x0000000000643754 in Fif (args=XIL(0x3d380f3)) at eval.c:410
#31 0x0000000000648ae4 in eval_sub (form=XIL(0x3d38103)) at eval.c:2183
---Type <return> to continue, or q <return> to quit---
#32 0x00000000006439af in Fprogn (body=XIL(0x28602c3)) at eval.c:455
#33 0x00000000006323d0 in Fsave_excursion (args=XIL(0x3d38063)) at
editfns.c:1050
#34 0x0000000000648ae4 in eval_sub (form=XIL(0x3d380d3)) at eval.c:2183
#35 0x00000000006439af in Fprogn (body=XIL(0)) at eval.c:455
#36 0x0000000000645dd1 in internal_catch (tag=XIL(0x5790), func=0x64390f
<Fprogn>, arg=XIL(0x2860283)) at eval.c:1097
#37 0x0000000000645d85 in Fcatch (args=XIL(0x2860293)) at eval.c:1074
#38 0x0000000000648ae4 in eval_sub (form=XIL(0x28602a3)) at eval.c:2183
#39 0x00000000006439af in Fprogn (body=XIL(0)) at eval.c:455
#40 0x000000000064b729 in funcall_lambda (fun=XIL(0x28601c3), nargs=1,
arg_vector=0x0) at eval.c:3042
#41 0x000000000064aef9 in apply_lambda (fun=XIL(0x28601b3),
args=XIL(0x520b603), count=44) at eval.c:2903
#42 0x0000000000649312 in eval_sub (form=XIL(0x520b613)) at eval.c:2306
#43 0x00000000006435a3 in For (args=XIL(0x5211883)) at eval.c:368
#44 0x0000000000648ae4 in eval_sub (form=XIL(0x52118a3)) at eval.c:2183
#45 0x00000000006436f6 in Fif (args=XIL(0x5211863)) at eval.c:407
#46 0x0000000000648ae4 in eval_sub (form=XIL(0x5211873)) at eval.c:2183
#47 0x00000000006439af in Fprogn (body=XIL(0)) at eval.c:455
#48 0x0000000000645977 in Flet (args=XIL(0x52109e3)) at eval.c:969
#49 0x0000000000648ae4 in eval_sub (form=XIL(0x5210973)) at eval.c:2183
#50 0x00000000006439af in Fprogn (body=XIL(0)) at eval.c:455
#51 0x00000000006323d0 in Fsave_excursion (args=XIL(0x52108f3)) at
editfns.c:1050
#52 0x0000000000648ae4 in eval_sub (form=XIL(0x5210963)) at eval.c:2183
#53 0x00000000006439af in Fprogn (body=XIL(0)) at eval.c:455
#54 0x000000000064b729 in funcall_lambda (fun=XIL(0x5210763), nargs=0,
arg_vector=0x0) at eval.c:3042
#55 0x000000000064aef9 in apply_lambda (fun=XIL(0x5210733), args=XIL(0),
count=37) at eval.c:2903
#56 0x0000000000649312 in eval_sub (form=XIL(0x5210463)) at eval.c:2306
#57 0x0000000000648e44 in eval_sub (form=XIL(0x52104e3)) at eval.c:2219
#58 0x0000000000648cda in eval_sub (form=XIL(0x52105b3)) at eval.c:2197
#59 0x0000000000643c68 in Fsetq (args=XIL(0x52106a3)) at eval.c:513
#60 0x0000000000648ae4 in eval_sub (form=XIL(0x52106b3)) at eval.c:2183
#61 0x00000000006439af in Fprogn (body=XIL(0x5212d83)) at eval.c:455
#62 0x000000000064b729 in funcall_lambda (fun=XIL(0x5212c83), nargs=0,
arg_vector=0x0) at eval.c:3042
#63 0x000000000064aef9 in apply_lambda (fun=XIL(0x5212c73), args=XIL(0),
count=32) at eval.c:2903
#64 0x0000000000649312 in eval_sub (form=XIL(0x5212513)) at eval.c:2306
#65 0x0000000000643679 in Fand (args=XIL(0)) at eval.c:389
#66 0x0000000000648ae4 in eval_sub (form=XIL(0x5216d53)) at eval.c:2183
#67 0x0000000000645243 in FletX (args=XIL(0x52168f3)) at eval.c:876
#68 0x0000000000648ae4 in eval_sub (form=XIL(0x52168e3)) at eval.c:2183
#69 0x00000000006439af in Fprogn (body=XIL(0)) at eval.c:455
#70 0x000000000064b729 in funcall_lambda (fun=XIL(0x521e7d3), nargs=1,
arg_vector=0x0) at eval.c:3042
#71 0x000000000064aef9 in apply_lambda (fun=XIL(0x521e7c3),
args=XIL(0x5208673), count=28) at eval.c:2903
#72 0x0000000000649312 in eval_sub (form=XIL(0x5208683)) at eval.c:2306
#73 0x0000000000643679 in Fand (args=XIL(0)) at eval.c:389
#74 0x0000000000648ae4 in eval_sub (form=XIL(0x520c783)) at eval.c:2183
#75 0x0000000000645243 in FletX (args=XIL(0x520c513)) at eval.c:876
#76 0x0000000000648ae4 in eval_sub (form=XIL(0x520c483)) at eval.c:2183
#77 0x00000000006439af in Fprogn (body=XIL(0)) at eval.c:455
#78 0x00000000006323d0 in Fsave_excursion (args=XIL(0x520c213)) at
editfns.c:1050
#79 0x0000000000648ae4 in eval_sub (form=XIL(0x520c223)) at eval.c:2183
#80 0x00000000006439af in Fprogn (body=XIL(0x520c103)) at eval.c:455
#81 0x0000000000645977 in Flet (args=XIL(0x520c0d3)) at eval.c:969
#82 0x0000000000648ae4 in eval_sub (form=XIL(0x520c0c3)) at eval.c:2183
#83 0x00000000006439af in Fprogn (body=XIL(0)) at eval.c:455
#84 0x000000000064b729 in funcall_lambda (fun=XIL(0x520bf53), nargs=1,
arg_vector=0x0) at eval.c:3042
#85 0x000000000064aef9 in apply_lambda (fun=XIL(0x520bf03),
args=XIL(0x520bc13), count=20) at eval.c:2903
#86 0x0000000000649312 in eval_sub (form=XIL(0x520bd33)) at eval.c:2306
#87 0x00000000006439af in Fprogn (body=XIL(0)) at eval.c:455
#88 0x000000000064b729 in funcall_lambda (fun=XIL(0x520b833), nargs=0,
arg_vector=0x0) at eval.c:3042
#89 0x000000000064a7f1 in Ffuncall (nargs=1, args=0x7fffffff8648) at
eval.c:2780
#90 0x000000000069f6c7 in exec_byte_code (bytestr=XIL(0xad4a14),
vector=XIL(0xad4a35), maxdepth=make_number(3),
args_template=make_number(0), nargs=0, args=0x7fffffff8da0) at
bytecode.c:629
#91 0x000000000064b2bd in funcall_lambda (fun=XIL(0xad49d5), nargs=0,
arg_vector=0x7fffffff8da0) at eval.c:2967
#92 0x000000000064a6ef in Ffuncall (nargs=1, args=0x7fffffff8d98) at
eval.c:2768
#93 0x000000000069f6c7 in exec_byte_code (bytestr=XIL(0xb41b5c),
vector=XIL(0xb41b7d), maxdepth=make_number(5),
args_template=make_number(257), nargs=1, args=0x7fffffff9648) at
bytecode.c:629
#94 0x000000000064b2bd in funcall_lambda (fun=XIL(0xb41b1d), nargs=1,
arg_vector=0x7fffffff9640) at eval.c:2967
---Type <return> to continue, or q <return> to quit---
#95 0x000000000064a6ef in Ffuncall (nargs=2, args=0x7fffffff9638) at
eval.c:2768
#96 0x00000000006403df in Ffuncall_interactively (nargs=2,
args=0x7fffffff9638) at callint.c:252
#97 0x000000000064aa62 in funcall_subr (subr=0xd84260
<Sfuncall_interactively>, numargs=2, args=0x7fffffff9638) at eval.c:2821
#98 0x000000000064a6ab in Ffuncall (nargs=3, args=0x7fffffff9630) at
eval.c:2766
#99 0x0000000000642951 in Fcall_interactively (function=XIL(0x43c240),
record_flag=XIL(0), keys=XIL(0x7235985)) at callint.c:841
#100 0x000000000064aba1 in funcall_subr (subr=0xd842a0
<Scall_interactively>, numargs=1, args=0x7fffffff9af8) at eval.c:2846
#101 0x000000000064a6ab in Ffuncall (nargs=2, args=0x7fffffff9af0) at
eval.c:2766
#102 0x000000000069f6c7 in exec_byte_code (bytestr=XIL(0x6631ff4),
vector=XIL(0x6632775), maxdepth=make_number(3),
args_template=make_number(257), nargs=1, args=0x7fffffffa368) at
bytecode.c:629
#103 0x000000000064b2bd in funcall_lambda (fun=XIL(0x66327c5), nargs=1,
arg_vector=0x7fffffffa360) at eval.c:2967
#104 0x000000000064a6ef in Ffuncall (nargs=2, args=0x7fffffffa358) at
eval.c:2768
#105 0x00000000006403df in Ffuncall_interactively (nargs=2,
args=0x7fffffffa358) at callint.c:252
#106 0x000000000064aa62 in funcall_subr (subr=0xd84260
<Sfuncall_interactively>, numargs=2, args=0x7fffffffa358) at eval.c:2821
#107 0x000000000064a6ab in Ffuncall (nargs=3, args=0x7fffffffa350) at
eval.c:2766
#108 0x0000000000642951 in Fcall_interactively (function=XIL(0x57f97a0),
record_flag=XIL(0), keys=XIL(0x7235985)) at callint.c:841
#109 0x000000000064aba1 in funcall_subr (subr=0xd842a0
<Scall_interactively>, numargs=3, args=0x7fffffffa840) at eval.c:2846
#110 0x000000000064a6ab in Ffuncall (nargs=4, args=0x7fffffffa838) at
eval.c:2766
#111 0x000000000069f6c7 in exec_byte_code (bytestr=XIL(0xaa1dac),
vector=XIL(0xaa1dcd), maxdepth=make_number(13),
args_template=make_number(1025), nargs=1, args=0x7fffffffb030) at
bytecode.c:629
#112 0x000000000064b2bd in funcall_lambda (fun=XIL(0xaa1d7d), nargs=1,
arg_vector=0x7fffffffb028) at eval.c:2967
#113 0x000000000064a6ef in Ffuncall (nargs=2, args=0x7fffffffb020) at
eval.c:2768
#114 0x0000000000649fa8 in call1 (fn=XIL(0x3f00), arg1=XIL(0x57f97a0)) at
eval.c:2617
#115 0x0000000000591dad in command_loop_1 () at keyboard.c:1482
#116 0x000000000064689d in internal_condition_case (bfun=0x5915d0
<command_loop_1>, handlers=XIL(0x5250), hfun=0x590c26 <cmd_error>) at
eval.c:1332
#117 0x00000000005911d5 in command_loop_2 (ignore=XIL(0)) at keyboard.c:1110
#118 0x0000000000645dd1 in internal_catch (tag=XIL(0xc8d0), func=0x5911ac
<command_loop_2>, arg=XIL(0)) at eval.c:1097
#119 0x0000000000591177 in command_loop () at keyboard.c:1089
#120 0x000000000059073b in recursive_edit_1 () at keyboard.c:695
#121 0x000000000059091a in Frecursive_edit () at keyboard.c:766
#122 0x000000000058e617 in main (argc=1, argv=0x7fffffffb528) at
emacs.c:1713

Lisp Backtrace:
"line-number-display-width" (0xffff37e0)
"line-move-visual" (0xffff4030)
"line-move" (0xffff4780)
"let" (0xffff4b80)
"condition-case" (0xffff4e70)
"nim-line-move" (0xffff5030)
"not" (0xffff5300)
"if" (0xffff54a0)
"progn" (0xffff5640)
"if" (0xffff57e0)
"save-excursion" (0xffff59c0)
"catch" (0xffff5be0)
"nim-line-empty-p" (0xffff5da0)
"or" (0xffff60c0)
"if" (0xffff6260)
"let" (0xffff64f0)
"save-excursion" (0xffff66d0)
"nim-get-empty-line-indent" (0xffff6890)
"cons" (0xffff6b50)
"list" (0xffff6ce0)
"setq" (0xffff6ed0)
"nim-smie-indent-calculate" (0xffff7090)
"and" (0xffff73a0)
"let*" (0xffff7590)
"nim-indent-calculate-indentation" (0xffff7750)
"and" (0xffff7a70)
"let*" (0xffff7c60)
"save-excursion" (0xffff7e40)
"let" (0xffff80d0)
"nim--indent-line-core" (0xffff8290)
"nim-indent-line" (0xffff8650)
"indent-according-to-mode" (0xffff8da0)
"comment-dwim" (0xffff9640)
---Type <return> to continue, or q <return> to quit---
"funcall-interactively" (0xffff9638)
"call-interactively" (0xffff9af8)
"org-comment-dwim" (0xffffa360)
"funcall-interactively" (0xffffa358)
"call-interactively" (0xffffa840)
"command-execute" (0xffffb028)
=====

This time, frame#2 looks same as frame#3 in the earlier backtrace, so
here's the same info for f 2.. and the values are the same:

(gdb) f 2
#2  0x0000000000449caa in init_iterator (it=0x7fffffff22e0, w=0x1593770,
charpos=1021, bytepos=1021, row=0x654be20, base_face_id=DEFAULT_FACE_ID) at
xdisp.c:2751
2751      eassert (charpos < 0 || (charpos >= BUF_BEG (current_buffer)
(gdb) p ZV
$1 = 263
(gdb) p Z
$2 = 263
(gdb)

It might be evident from the Lisp backtrace, but I have the native line
numbers enabled for nim-mode, but disabled for org.

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).

-- 

Kaushal Modi

[Message part 2 (text/html, inline)]

Message #38 received at 29326 <at> debbugs.gnu.org (full text, mbox):

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: Re: 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.

Message #43 received at 29326-done <at> debbugs.gnu.org (full text, mbox):

From: Kaushal Modi <kaushal.modi <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 29326-done <at> debbugs.gnu.org, npostavs <at> users.sourceforge.net
Subject: Re: bug#29326: 26.0.90; Emacs crash on running comment-dwim
Date: Fri, 17 Nov 2017 20:04:06 +0000

[Message part 1 (text/plain, inline)]

On Fri, Nov 17, 2017 at 2:47 PM Eli Zaretskii <eliz <at> 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

[Message part 2 (text/html, inline)]

Message #46 received at 29326 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#29326: 26.0.90; Emacs crash on running comment-dwim
Date: Fri, 17 Nov 2017 22:24:09 +0200

> From: Kaushal Modi <kaushal.modi <at> gmail.com>
> Date: Fri, 17 Nov 2017 20:04:06 +0000
> Cc: npostavs <at> users.sourceforge.net, 29326-done <at> debbugs.gnu.org
> 
>  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 for testing.

> 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.

The trigger was the call to line-move-visual in nim-mode.  So you need
to do something that causes that function to be called by nim-mode,
when Org does the indent thing.  I think this doesn't happen
frequently because most modes used in source snippets in Org buffers
don't call line-move-visual (why would they? that function is for
interactively moving cursor vertically).

Message #49 received at 29326 <at> debbugs.gnu.org (full text, mbox):

From: Kaushal Modi <kaushal.modi <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 29326 <at> debbugs.gnu.org, npostavs <at> users.sourceforge.net
Subject: Re: bug#29326: 26.0.90; Emacs crash on running comment-dwim
Date: Fri, 17 Nov 2017 20:29:26 +0000

[Message part 1 (text/plain, inline)]

On Fri, Nov 17, 2017 at 3:24 PM Eli Zaretskii <eliz <at> gnu.org> wrote:

> The trigger was the call to line-move-visual in nim-mode.  So you need
> to do something that causes that function to be called by nim-mode,
> when Org does the indent thing.  I think this doesn't happen
> frequently because most modes used in source snippets in Org buffers
> don't call line-move-visual (why would they? that function is for
> interactively moving cursor vertically).
>

Makes sense.. I'll open an issue on nim-mode repo. Thanks.
-- 

Kaushal Modi

[Message part 2 (text/html, inline)]

Previous Next

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