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

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 59703 in the body.
You can then email your comments to 59703 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: Daniel Martín <mardani29 <at> yahoo.es>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; Emacs crashes when turning treesit-explore-mode on with
 some C++ code
Date: Wed, 30 Nov 2022 00:06:03 +0100

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"

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

From: Theodor Thornhill <theo <at> thornhill.no>
To: 59703 <at> debbugs.gnu.org
Cc: Daniel Martín <mardani29 <at> yahoo.es>
Subject: 29.0.50; Emacs crashes when turning treesit-explore-mode on with
 some C++ code
Date: Wed, 30 Nov 2022 09:51:15 +0100

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

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

From: Yuan Fu <casouri <at> gmail.com>
To: Theodor Thornhill <theo <at> thornhill.no>
Cc: 59703 <at> debbugs.gnu.org, mardani29 <at> yahoo.es
Subject: Re: bug#59703: 29.0.50; Emacs crashes when turning 
 treesit-explore-mode on with some C++ code
Date: Wed, 30 Nov 2022 02:13:23 -0800

Theodor Thornhill <theo <at> 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

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

From: Daniel Martín <mardani29 <at> yahoo.es>
To: Theodor Thornhill <theo <at> thornhill.no>
Cc: 59703 <at> debbugs.gnu.org
Subject: Re: bug#59703: 29.0.50; Emacs crashes when turning
 treesit-explore-mode on with some C++ code
Date: Wed, 30 Nov 2022 11:44:43 +0100

Theodor Thornhill <theo <at> 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 <at> 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))

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

From: Theodor Thornhill <theo <at> thornhill.no>
To: Daniel Martín <mardani29 <at> yahoo.es>
Cc: 59703 <at> debbugs.gnu.org
Subject: Re: bug#59703: 29.0.50; Emacs crashes when turning
 treesit-explore-mode on with some C++ code
Date: Wed, 30 Nov 2022 11:52:00 +0100

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

> Theodor Thornhill <theo <at> 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

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

From: Daniel Martín <mardani29 <at> yahoo.es>
To: Theodor Thornhill <theo <at> thornhill.no>
Cc: 59703 <at> debbugs.gnu.org, 59703-done <at> debbugs.gnu.org
Subject: Re: bug#59703: 29.0.50; Emacs crashes when turning
 treesit-explore-mode on with some C++ code
Date: Wed, 30 Nov 2022 13:45:41 +0100

Theodor Thornhill <theo <at> 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.

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

From: Theodor Thornhill <theo <at> thornhill.no>
To: Daniel Martín <mardani29 <at> yahoo.es>
Cc: 59703 <at> debbugs.gnu.org, 59703-done <at> debbugs.gnu.org
Subject: Re: bug#59703: 29.0.50; Emacs crashes when turning
 treesit-explore-mode on with some C++ code
Date: Wed, 30 Nov 2022 14:04:41 +0100

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

> Theodor Thornhill <theo <at> 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 :)

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Martín <mardani29 <at> yahoo.es>
Cc: 59703 <at> debbugs.gnu.org, theo <at> thornhill.no
Subject: Re: bug#59703: 29.0.50;
 Emacs crashes when turning treesit-explore-mode on with some C++ code
Date: Wed, 30 Nov 2022 16:13:09 +0200

> Cc: 59703 <at> 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 <at> gnu.org>
> 
> Theodor Thornhill <theo <at> 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.

Previous Next

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