bug#59703: 29.0.50; Emacs crashes when turning treesit-explore-mode on with some C++ code

bug#59703: 29.0.50; Emacs crashes when turning treesit-explore-mode on with some C++ code

[Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Steps to reproduce the problem:

emacs -Q
C-x b sample.cpp RET

Paste the following code:

class OFFICE_EXPORT Sample : public Base, public WeakObservable<SampleObserver> {
public:    
   void getFoo();
private:
   mutable std::weak_ptr<Foo> m_Foo;
};

M-x c++-ts-mode RET
M-x treesit-explore-mode RET
M-<

Emacs crashes with the following backtrace:

* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x100100005530847)
  * frame #0: 0x0000000101365fc8 libtree-sitter.0.dylib`ts_node_field_name_for_child + 24
    frame #1: 0x00000001003b0a8c emacs`Ftreesit_node_field_name_for_child(node=0x00000001059f7575, n=(EMACS_INT) $329 = 0) at treesit.c:1868:7
    frame #2: 0x00000001002c2cd4 emacs`funcall_subr(subr=0x00000001005028c8, numargs=2, args=(struct Lisp_Symbol *) $332 = 0x0000000100b32ec0) at eval.c:3036:15
    frame #3: 0x000000010033bde4 emacs`exec_byte_code(fun=(struct Lisp_Vector *) $337 = 0x0000000103872e98, args_template=513, nargs=1, args=(struct Lisp_Symbol *) $340 = 0x0000000100b32ec0) at bytecode.c:809:14
    frame #4: 0x00000001002c8054 emacs`fetch_and_exec_byte_code(fun=(struct Lisp_Vector *) $345 = 0x0000000135009550, args_template=0, nargs=0, args=(struct Lisp_Symbol *) $348 = 0x0000000100b32ec0) at eval.c:3081:10
    frame #5: 0x00000001002c3300 emacs`funcall_lambda(fun=(struct Lisp_Vector *) $353 = 0x0000000135009550, nargs=0, arg_vector=(struct Lisp_Symbol *) $356 = 0x0000000100b32ec0) at eval.c:3153:9
    frame #6: 0x00000001002c2914 emacs`funcall_general(fun=(struct Lisp_Vector *) $361 = 0x0000000135009550, numargs=0, args=(struct Lisp_Symbol *) $364 = 0x0000000100b32ec0) at eval.c:2945:12
    frame #7: 0x00000001002bc8e0 emacs`Ffuncall(nargs=1, args=(struct Lisp_Symbol *) $367 = 0x0000000100b32ec0) at eval.c:2995:21
    frame #8: 0x00000001002c1224 emacs`Fapply(nargs=2, args=(struct Lisp_Symbol *) $370 = 0x0000000100b32ec0) at eval.c:2619:12
    frame #9: 0x00000001002c2e9c emacs`funcall_subr(subr=0x00000001004fca48, numargs=2, args=(struct Lisp_Symbol *) $373 = 0x0000000100b32ec0) at eval.c:3059:9
    frame #10: 0x000000010033bde4 emacs`exec_byte_code(fun=(struct Lisp_Vector *) $378 = 0x00000001044e6b58, args_template=257, nargs=1, args=(struct Lisp_Symbol *) $381 = 0x0000000100b32ec0) at bytecode.c:809:14
    frame #11: 0x00000001002c8054 emacs`fetch_and_exec_byte_code(fun=(struct Lisp_Vector *) $386 = 0x0000000104ae6e70, args_template=257, nargs=1, args=(struct Lisp_Symbol *) $389 = 0x0000000100b32ec0) at eval.c:3081:10
    frame #12: 0x00000001002c3300 emacs`funcall_lambda(fun=(struct Lisp_Vector *) $394 = 0x0000000104ae6e70, nargs=1, arg_vector=(struct Lisp_Symbol *) $397 = 0x0000000100b32ec0) at eval.c:3153:9
    frame #13: 0x00000001002c2914 emacs`funcall_general(fun=(struct Lisp_Vector *) $402 = 0x0000000104ae6e70, numargs=1, args=(struct Lisp_Symbol *) $405 = 0x0000000100b32ec0) at eval.c:2945:12
    frame #14: 0x00000001002bc8e0 emacs`Ffuncall(nargs=2, args=(struct Lisp_Symbol *) $408 = 0x0000000100b32ec0) at eval.c:2995:21
    frame #15: 0x00000001001a6da0 emacs`call1(fn=(struct Lisp_Symbol *) $411 = 0x0000000100b41f20, arg1=(struct Lisp_Vector *) $415 = 0x000000013500bc20) at lisp.h:3247:10
    frame #16: 0x00000001001b058c emacs`timer_check_2(timers=(struct Lisp_Cons *) $417 = 0x0000000105972560, idle_timers=(struct Lisp_Cons *) $419 = 0x0000000105972570) at keyboard.c:4681:8
    frame #17: 0x00000001001afc58 emacs`timer_check at keyboard.c:4747:18
    frame #18: 0x00000001001ac6b4 emacs`readable_events(flags=1) at keyboard.c:3524:5
    frame #19: 0x00000001001afae4 emacs`get_input_pending(flags=1) at keyboard.c:7367:42
    frame #20: 0x00000001001aac68 emacs`detect_input_pending_run_timers(do_display=true) at keyboard.c:10897:5
    frame #21: 0x0000000100350bec emacs`wait_reading_process_output(time_limit=30, nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=(struct Lisp_Symbol *) $422 = 0x0000000100b32ec0, wait_proc=0x0000000000000000, just_wait_proc=0) at process.c:5779:8
    frame #22: 0x000000010000c54c emacs`sit_for(timeout=(EMACS_INT) $424 = 30, reading=true, display_option=1) at dispnew.c:6252:7
    frame #23: 0x00000001001a8a74 emacs`read_char(commandflag=1, map=(struct Lisp_Cons *) $426 = 0x000000010595beb0, prev_event=(struct Lisp_Symbol *) $429 = 0x0000000100b32ec0, used_mouse_menu=0x000000016fdfe837, end_time=0x0000000000000000) at keyboard.c:2872:11
    frame #24: 0x00000001001a3a6c emacs`read_key_sequence(keybuf=(struct Lisp_Symbol *) $432 = 0x0000000100b32ec0, prompt=(struct Lisp_Symbol *) $435 = 0x0000000100b32ec0, dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:10074:12
    frame #25: 0x00000001001a1d84 emacs`command_loop_1 at keyboard.c:1376:15
    frame #26: 0x00000001002bdfd0 emacs`internal_condition_case(bfun=(emacs`command_loop_1 at keyboard.c:1270), handlers=(struct Lisp_Symbol *) $438 = 0x0000000100b32f50, hfun=(emacs`cmd_error at keyboard.c:928)) at eval.c:1474:25
    frame #27: 0x00000001001a1850 emacs`command_loop_2(handlers=(struct Lisp_Symbol *) $441 = 0x0000000100b32f50) at keyboard.c:1125:11
    frame #28: 0x00000001002bd1e8 emacs`internal_catch(tag=(struct Lisp_Symbol *) $444 = 0x0000000100b421f0, func=(emacs`command_loop_2 at keyboard.c:1121), arg=(struct Lisp_Symbol *) $447 = 0x0000000100b32f50) at eval.c:1197:25
    frame #29: 0x00000001001a0844 emacs`command_loop at keyboard.c:1103:2
    frame #30: 0x00000001001a0694 emacs`recursive_edit_1 at keyboard.c:712:9
    frame #31: 0x00000001001a0c68 emacs`Frecursive_edit at keyboard.c:795:3
    frame #32: 0x000000010019d420 emacs`main(argc=2, argv=0x000000016fdff3a0) at emacs.c:2523:3
    frame #33: 0x0000000100d3108c dyld`start + 520

Lisp backtrace:

(unsigned char *) data = 0x00000001004d0dc3 "treesit-node-field-name-for-child"
(unsigned char *) data = 0x0000000103967dc8 "treesit-node-field-name"
(unsigned char *) data = 0x000000010396a700 "treesit--explorer-draw-node"
(unsigned char *) data = 0x000000010396a700 "treesit--explorer-draw-node"
(unsigned char *) data = 0x000000010396a700 "treesit--explorer-draw-node"
(unsigned char *) data = 0x000000010396a700 "treesit--explorer-draw-node"
(unsigned char *) data = 0x000000010396a6b8 "treesit--explorer-refresh"
(unsigned char *) data = 0x00000001004b51f2 "apply"
(unsigned char *) data = 0x00000001004c04f2 "timer-event-handler"

bug#59703: 29.0.50; Emacs crashes when turning treesit-explore-mode on with some C++ code

[Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors]

It doesn't crash here.  I remember there were some crashes with fairly
new versions of tree-sitter.  When I used the version provided in apt
the crashes disappeared.  I have version 20.3 now.

Could that be what's causing this issue?

Theo

bug#59703: 29.0.50; Emacs crashes when turning treesit-explore-mode on with some C++ code

[Yuan Fu]

Theodor Thornhill <theo@thornhill.no> writes:

> It doesn't crash here.  I remember there were some crashes with fairly
> new versions of tree-sitter.  When I used the version provided in apt
> the crashes disappeared.  I have version 20.3 now.
>
> Could that be what's causing this issue?

Could be, since it crashed in the tree-sitter function (IIRC like the
crash someone reported earlier).

Yuan

bug#59703: 29.0.50; Emacs crashes when turning treesit-explore-mode on with some C++ code

[Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Theodor Thornhill <theo@thornhill.no> writes:

> It doesn't crash here.  I remember there were some crashes with fairly
> new versions of tree-sitter.  When I used the version provided in apt
> the crashes disappeared.  I have version 20.3 now.
>
> Could that be what's causing this issue?
>

Did you try to move the point after the last step?  It doesn't crash for
me when I enable treesit-explore-mode, but it does as soon as I move the
point upwards a bit by pressing C-p repeatedly.

I'm using Tree-sitter version 0.20.6.

Here's the full details of my Emacs build:

In GNU Emacs 29.0.60 (build 1, aarch64-apple-darwin21.6.0, NS
 appkit-2113.60 Version 12.6 (Build 21G115)) of 2022-11-29 built on
 Daniels-MacBook-Pro.local
Repository revision: f6aa7c335fb848a27934aa31b2012c511d6f1b19
Repository branch: emacs-29
Windowing system distributor 'Apple', version 10.3.2113
System Description:  macOS 12.6

Configured using:
 'configure -C --enable-checking=yes,glyphs 'CFLAGS=-O0 -gdwarf-4 -g3'
 CPPFLAGS=-I/opt/homebrew/opt/openjdk@11/include'

Configured features:
ACL DBUS GLIB GNUTLS JSON LCMS2 LIBXML2 MODULES NOTIFY KQUEUE NS PDUMPER
PNG RSVG SQLITE3 THREADS TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM ZLIB

Important settings:
  value of $LC_CTYPE: UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-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
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search time-date subr-x mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils rmc iso-transl tooltip cconv eldoc paren electric
uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/ns-win ns-win ucs-normalize mule-util term/common-win tool-bar dnd
fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow
isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine 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 emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind kqueue cocoa ns
lcms2 multi-tty make-network-process emacs)

Memory information:
((conses 16 36829 7587)
 (symbols 48 5070 0)
 (strings 32 12596 1478)
 (string-bytes 1 354146)
 (vectors 16 10262)
 (vector-slots 8 153161 11986)
 (floats 8 21 23)
 (intervals 56 206 0)
 (buffers 992 10))

bug#59703: 29.0.50; Emacs crashes when turning treesit-explore-mode on with some C++ code

[Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Daniel Martín <mardani29@yahoo.es> writes:

> Theodor Thornhill <theo@thornhill.no> writes:
>
>> It doesn't crash here.  I remember there were some crashes with fairly
>> new versions of tree-sitter.  When I used the version provided in apt
>> the crashes disappeared.  I have version 20.3 now.
>>
>> Could that be what's causing this issue?
>>
>
> Did you try to move the point after the last step?  It doesn't crash for
> me when I enable treesit-explore-mode, but it does as soon as I move the
> point upwards a bit by pressing C-p repeatedly.
>

Yeah, and that's what I was experiencing earlier as well.  IIRC the
version I used was a compile from master, and was tagged with 20.7.  So
my 2 cents would be either a bug in treesitter upstream, or some new api
that we don't support yet.  I didn't do too much digging at the time
because I had several other patches in the loop and wanted to continue
working on those:)

Hope this helps,
Theo

bug#59703: 29.0.50; Emacs crashes when turning treesit-explore-mode on with some C++ code

[Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Theodor Thornhill <theo@thornhill.no> writes:

>
> Yeah, and that's what I was experiencing earlier as well.  IIRC the
> version I used was a compile from master, and was tagged with 20.7.  So
> my 2 cents would be either a bug in treesitter upstream, or some new api
> that we don't support yet.  I didn't do too much digging at the time
> because I had several other patches in the loop and wanted to continue
> working on those:)
>

I've upgraded Tree-sitter from 0.20.6 to 0.20.7 and the crash is fixed.
Taking a look at the Tree-sitter changelog, this might be the commit
that fixed the bug: https://github.com/tree-sitter/tree-sitter/pull/1823

So I'm closing this bug.

bug#59703: 29.0.50; Emacs crashes when turning treesit-explore-mode on with some C++ code

[Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Daniel Martín <mardani29@yahoo.es> writes:

> Theodor Thornhill <theo@thornhill.no> writes:
>
>>
>> Yeah, and that's what I was experiencing earlier as well.  IIRC the
>> version I used was a compile from master, and was tagged with 20.7.  So
>> my 2 cents would be either a bug in treesitter upstream, or some new api
>> that we don't support yet.  I didn't do too much digging at the time
>> because I had several other patches in the loop and wanted to continue
>> working on those:)
>>
>
> I've upgraded Tree-sitter from 0.20.6 to 0.20.7 and the crash is fixed.
> Taking a look at the Tree-sitter changelog, this might be the commit
> that fixed the bug: https://github.com/tree-sitter/tree-sitter/pull/1823
>
> So I'm closing this bug.

Nice :)

bug#59703: 29.0.50; Emacs crashes when turning treesit-explore-mode on with some C++ code

[Eli Zaretskii]

> Cc: 59703@debbugs.gnu.org
> Date: Wed, 30 Nov 2022 11:44:43 +0100
> From:  Daniel Martín via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> Theodor Thornhill <theo@thornhill.no> writes:
> 
> > It doesn't crash here.  I remember there were some crashes with fairly
> > new versions of tree-sitter.  When I used the version provided in apt
> > the crashes disappeared.  I have version 20.3 now.
> >
> > Could that be what's causing this issue?
> >
> 
> Did you try to move the point after the last step?  It doesn't crash for
> me when I enable treesit-explore-mode, but it does as soon as I move the
> point upwards a bit by pressing C-p repeatedly.
> 
> I'm using Tree-sitter version 0.20.6.

I use the official 0.20.7 release, and I cannot reproduce the crash,
either.  Not even after C-p or other movements of point.