bug#29326: 26.0.90; Emacs crash on running comment-dwim

bug#29326: 26.0.90; Emacs crash on running comment-dwim

[Kaushal Modi]

[-- Attachment #1.1: Type: text/plain, Size: 14129 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 17004 bytes --]

[-- Attachment #2: test.org --]
[-- Type: application/octet-stream, Size: 2461 bytes --]

#+PROPERTY: header-args:nim :exports both :results output

* Nim in Action
** Threads
*** 6.2.1 The =threads= module and GC safety
**** Problematic code
#+BEGIN_SRC nim :flags --threads:on :eval no
var data = "Hello World"

proc showData() {.thread.} =
  echo(data)

var thread: Thread[void]
createThread[void](thread, showData)
joinThread(thread)
#+END_SRC

#+RESULTS:
: nim_src_I3YWGm.nim(6, 6) Error: 'showData' is not GC-safe as it
:  accesses 'data' which is a global using GC'ed memory

/Remove =:eval no= to see the above error./
**** Fixed code
#+BEGIN_SRC nim :flags --threads:on
var data = "Hello World"

proc showData(param: string) {.thread.} =
  echo(param)

var thread: Thread[string]
createThread[string](thread, showData, data)
joinThread(thread)
#+END_SRC

#+RESULTS:
: Hello World
** Parsing
*** 6.3.2 Parsing the Wikipedia page counts format
**** Using regular expressions
#+BEGIN_SRC nim
import re
let pattern = re"([^\s]+)\s([^\s]+)\s(\d+)\s(\d+)"
var line = "en Nim_(programming_language) 1 70231"
var matches: array[4, string]
let start = find(line, pattern, matches)

doAssert start      == 0
doAssert matches[0] == "en"
doAssert matches[1] == "Nim_(programming_language)"
doAssert matches[2] == "1"
doAssert matches[3] == "70231"

echo "Parsed successfully!"
#+END_SRC

#+RESULTS:
: Parsed successfully!

**** Parsing the data manually using =split=
#+BEGIN_SRC nim
import strutils
var line = "en Nim_(programming_language) 1 70231"
var matches = line.split()

doAssert matches[0] == "en"
doAssert matches[1] == "Nim_(programming_language)"
doAssert matches[2] == "1"
doAssert matches[3] == "70231"

echo "Parsed successfully!"
#+END_SRC

#+RESULTS:
: Parsed successfully!

**** Parsing the data manually using =parseutils=
#+BEGIN_SRC nim
import parseutils               # https://nim-lang.org/docs/parseutils.html
var line = "en Nim_(programming_language) 1 70231"

var i = 0
var domainCode = ""
#     parseUntil(s, token, until, start)
#       returns the number of parsed characters
i.inc parseUntil(line, domainCode, {' '}, i)
i.inc
var pageTitle = ""
i.inc parseUntil(line, pageTitle, {' '}, i)
i.inc
var countViews = 0
i.inc parseInt(line, countViews, i)
i.inc
var totalSize = 0
i.inc parseInt(line, totalSize, i)
i.inc

doAssert domainCode == "en"
doAssert pageTitle  == "Nim_(programming_language)"
doAssert countViews == 1
doAssert totalSize  == 70231

echo "Parsed successfully!"
#+END_SRC

#+RESULTS:
: Parsed successfully!

bug#29326: 26.0.90; Emacs crash on running comment-dwim

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@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?

bug#29326: 26.0.90; Emacs crash on running comment-dwim

[Eli Zaretskii]

> Date: Fri, 17 Nov 2017 09:03:52 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 29326@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.

bug#29326: 26.0.90; Emacs crash on running comment-dwim

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 1079 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1811 bytes --]

bug#29326: 26.0.90; Emacs crash on running comment-dwim

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Fri, 17 Nov 2017 17:11:53 +0000
> Cc: 29326@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.

bug#29326: 26.0.90; Emacs crash on running comment-dwim

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 320 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 785 bytes --]

bug#29326: 26.0.90; Emacs crash on running comment-dwim

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 442 bytes --]

On Fri, Nov 17, 2017 at 1:08 PM Kaushal Modi <kaushal.modi@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

[-- Attachment #2: Type: text/html, Size: 1217 bytes --]

bug#29326: 26.0.90; Emacs crash on running comment-dwim

[Noam Postavsky]

On Fri, Nov 17, 2017 at 1:13 PM, Kaushal Modi <kaushal.modi@gmail.com> wrote:
> On Fri, Nov 17, 2017 at 1:08 PM Kaushal Modi <kaushal.modi@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.

bug#29326: 26.0.90; Emacs crash on running comment-dwim

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 710 bytes --]

On Fri, Nov 17, 2017 at 1:16 PM Noam Postavsky <
npostavs@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

[-- Attachment #2: Type: text/html, Size: 1340 bytes --]

bug#29326: 26.0.90; Emacs crash on running comment-dwim

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Fri, 17 Nov 2017 18:18:51 +0000
> Cc: Eli Zaretskii <eliz@gnu.org>, 29326@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

bug#29326: 26.0.90; Emacs crash on running comment-dwim

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 14333 bytes --]

On Fri, Nov 17, 2017 at 1:18 PM Kaushal Modi <kaushal.modi@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

[-- Attachment #2: Type: text/html, Size: 17604 bytes --]

bug#29326: 26.0.90; Emacs crash on running comment-dwim

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Fri, 17 Nov 2017 18:36:32 +0000
> Cc: 29326@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.

bug#29326: 26.0.90; Emacs crash on running comment-dwim

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 1991 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 3131 bytes --]

bug#29326: 26.0.90; Emacs crash on running comment-dwim

[Eli Zaretskii]

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

bug#29326: 26.0.90; Emacs crash on running comment-dwim

[Kaushal Modi]

[-- Attachment #1: Type: text/plain, Size: 537 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 932 bytes --]