bug#70059: 30.0.50; c-ts-mode crashes emacs

bug#70059: 30.0.50; c-ts-mode crashes emacs

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

I can reproduce it like this:
run 'emacs -Q'
open a C source file.
M-x c-ts-mode
wait a few seconds, and emacs crashes.


In GNU Emacs 30.0.50 (build 4, x86_64-pc-linux-gnu, GTK+ Version
 3.24.41, cairo version 1.18.0) of 2024-03-28
Repository revision: de9e913f9e2a1e01e5d091a553e98d75404a2246
Repository branch: makepkg
System Description: Arch Linux

Configured using:
 'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
 --localstatedir=/var --mandir=/usr/share/man --with-gameuser=:games
 --with-modules --without-m17n-flt --without-gconf --enable-autodepend
 --enable-link-time-optimization --with-native-compilation=yes
 --with-xinput2 --with-pgtk --without-xaw3d --with-cairo-xcb
 --with-sound=no --with-xwidgets --with-tree-sitter --without-gpm
 --without-compress-install
 '--program-transform-name=s/\([ec]tags\)/\1.emacs/'
 'CFLAGS=-march=native -mtune=generic -O3 -pipe -fno-plt -fexceptions
 -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security
 -fstack-clash-protection -fcf-protection'
 LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LCMS2 LIBOTF LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY
PDUMPER PGTK PNG RSVG SECCOMP SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS
TREE_SITTER WEBP XIM XWIDGETS GTK3 ZLIB

Important settings:
  value of $LANG: de_DE.UTF-8
  locale-coding-system: utf-8


output of 'bt full':
#0  0x0000723f6094e32c in ??? () at /usr/lib/libc.so.6
#1  0x0000723f608fd6c8 in raise () at /usr/lib/libc.so.6
#2  0x000062534cfba3f2 in terminate_due_to_signal ()
#3  0x000062534cff3ee3 in emacs_abort ()
#4  0x000062534d0a9ec8 in signal_or_quit ()
#5  0x000062534d0a9082 in Fsignal ()
#6  0x000062534d0a9061 in xsignal ()
#7  0x000062534d0a76f2 in xsignal2 ()
#8  0x000062534d080376 in wrong_type_argument ()
#9  0x000062534d02578f in Fexpand_file_name ()
#10 0x000062534d208d00 in Fdo_auto_save.8209 ()
#11 0x000062534cfba688 in shut_down_emacs ()
#12 0x000062534cfba3ba in terminate_due_to_signal ()
#13 0x000062534cff5be4 in handle_sigsegv ()
#14 0x0000723f608fd770 in <signal handler called> () at /usr/lib/libc.so.6
#15 0x000062534d063429 in process_mark_stack ()
#16 0x000062534d1649f1 in traverse_intervals_noorder ()
#17 0x000062534d063e5e in process_mark_stack ()
#18 0x000062534d063ceb in process_mark_stack ()
#19 0x000062534d063ceb in process_mark_stack ()
#20 0x000062534d064fab in mark_char_table ()
#21 0x000062534d0650f6 in mark_char_table ()
#22 0x000062534d063c0c in process_mark_stack ()
#23 0x000062534d063ceb in process_mark_stack ()
#24 0x000062534d063ceb in process_mark_stack ()
#25 0x000062534d063ceb in process_mark_stack ()
#26 0x000062534d0663be in garbage_collect ()
#27 0x000062534d11e30b in exec_byte_code ()
#28 0x000062534d0a5406 in Ffuncall ()
#29 0x000062534d0a58df in Fapply ()
#30 0x000062534d137961 in read_process_output_call ()
#31 0x000062534d0ae619 in internal_condition_case_1 ()
#32 0x000062534d137820 in exec_sentinel ()
#33 0x000062534d135d2f in status_notify ()
#34 0x000062534d13b00c in wait_reading_process_output ()
#35 0x000062534cfce3bf in kbd_buffer_get_event ()
#36 0x000062534cfca560 in read_char ()
#37 0x000062534cfc4c1b in read_key_sequence ()
#38 0x000062534cfc2829 in command_loop_1 ()
#39 0x000062534d0ae597 in internal_condition_case ()
#40 0x000062534cfc168e in command_loop_2 ()
#41 0x000062534d0ad451 in internal_catch ()
#42 0x000062534cfc163c in command_loop ()
#43 0x000062534cfc14a6 in recursive_edit_1 ()
#44 0x000062534cfd8707 in Frecursive_edit ()
#45 0x000062534cfbf419 in main ()

bug#70059: 30.0.50; c-ts-mode crashes emacs

[Eli Zaretskii]

> Date: Thu, 28 Mar 2024 21:36:54 +0100
> From:  Felix via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> 
> I can reproduce it like this:
> run 'emacs -Q'
> open a C source file.
> M-x c-ts-mode
> wait a few seconds, and emacs crashes.

Doesn't happen here, but see below.

> In GNU Emacs 30.0.50 (build 4, x86_64-pc-linux-gnu, GTK+ Version
>  3.24.41, cairo version 1.18.0) of 2024-03-28
> Repository revision: de9e913f9e2a1e01e5d091a553e98d75404a2246
> Repository branch: makepkg
                     ^^^^^^^
What is this branch?  I don't see such a branch in the Emacs Git
repository; did I miss something?  If this is your local branch, does
it have any local changes which could affect this issue?

> System Description: Arch Linux
> 
> Configured using:
>  'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
>  --localstatedir=/var --mandir=/usr/share/man --with-gameuser=:games
>  --with-modules --without-m17n-flt --without-gconf --enable-autodepend
>  --enable-link-time-optimization --with-native-compilation=yes
>  --with-xinput2 --with-pgtk --without-xaw3d --with-cairo-xcb
>  --with-sound=no --with-xwidgets --with-tree-sitter --without-gpm
>  --without-compress-install
>  '--program-transform-name=s/\([ec]tags\)/\1.emacs/'
>  'CFLAGS=-march=native -mtune=generic -O3 -pipe -fno-plt -fexceptions
>  -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security
>  -fstack-clash-protection -fcf-protection'
>  LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now'
> 
> Configured features:
> ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
> LCMS2 LIBOTF LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY
> PDUMPER PGTK PNG RSVG SECCOMP SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS
> TREE_SITTER WEBP XIM XWIDGETS GTK3 ZLIB

I see your build is with native-compilation; mine is without.  The
backtrace you posted:

> #11 0x000062534cfba688 in shut_down_emacs ()
> #12 0x000062534cfba3ba in terminate_due_to_signal ()
> #13 0x000062534cff5be4 in handle_sigsegv ()
> #14 0x0000723f608fd770 in <signal handler called> () at /usr/lib/libc.so.6
> #15 0x000062534d063429 in process_mark_stack ()
> #16 0x000062534d1649f1 in traverse_intervals_noorder ()
> #17 0x000062534d063e5e in process_mark_stack ()
> #18 0x000062534d063ceb in process_mark_stack ()
> #19 0x000062534d063ceb in process_mark_stack ()
> #20 0x000062534d064fab in mark_char_table ()
> #21 0x000062534d0650f6 in mark_char_table ()
> #22 0x000062534d063c0c in process_mark_stack ()
> #23 0x000062534d063ceb in process_mark_stack ()
> #24 0x000062534d063ceb in process_mark_stack ()
> #25 0x000062534d063ceb in process_mark_stack ()
> #26 0x000062534d0663be in garbage_collect ()
> #27 0x000062534d11e30b in exec_byte_code ()
> #28 0x000062534d0a5406 in Ffuncall ()
> #29 0x000062534d0a58df in Fapply ()
> #30 0x000062534d137961 in read_process_output_call ()
> #31 0x000062534d0ae619 in internal_condition_case_1 ()
> #32 0x000062534d137820 in exec_sentinel ()
> #33 0x000062534d135d2f in status_notify ()
> #34 0x000062534d13b00c in wait_reading_process_output ()

indicates that Emacs crashed after some sub-process exited, the
process sentinel was called, and that caused us to run some Lips and
perform GC.  Any idea what that subprocess was? could it be the async
native-compilation of some Lisp file?  Can you try building without
native-compilation and see if the problem happens there as well?

Also, do you see c-ts-mode's .eln file in your eln-cache directory?

Andrea, can you try reproducing this?

bug#70059: 30.0.50; c-ts-mode crashes emacs

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

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Thu, 28 Mar 2024 21:36:54 +0100
>> From:  Felix via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>>
>>
>> I can reproduce it like this:
>> run 'emacs -Q'
>> open a C source file.
>> M-x c-ts-mode
>> wait a few seconds, and emacs crashes.
>
> Doesn't happen here, but see below.
>
>> In GNU Emacs 30.0.50 (build 4, x86_64-pc-linux-gnu, GTK+ Version
>>  3.24.41, cairo version 1.18.0) of 2024-03-28
>> Repository revision: de9e913f9e2a1e01e5d091a553e98d75404a2246
>> Repository branch: makepkg
>                      ^^^^^^^
> What is this branch?  I don't see such a branch in the Emacs Git
> repository; did I miss something?  If this is your local branch, does
> it have any local changes which could affect this issue?
>

I build emacs from the arch linux AUR, it's not differrent from the master branch


>> System Description: Arch Linux
>>
>> Configured using:
>>  'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
>>  --localstatedir=/var --mandir=/usr/share/man --with-gameuser=:games
>>  --with-modules --without-m17n-flt --without-gconf --enable-autodepend
>>  --enable-link-time-optimization --with-native-compilation=yes
>>  --with-xinput2 --with-pgtk --without-xaw3d --with-cairo-xcb
>>  --with-sound=no --with-xwidgets --with-tree-sitter --without-gpm
>>  --without-compress-install
>>  '--program-transform-name=s/\([ec]tags\)/\1.emacs/'
>>  'CFLAGS=-march=native -mtune=generic -O3 -pipe -fno-plt -fexceptions
>>  -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security
>>  -fstack-clash-protection -fcf-protection'
>>  LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now'
>>
>> Configured features:
>> ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
>> LCMS2 LIBOTF LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY
>> PDUMPER PGTK PNG RSVG SECCOMP SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS
>> TREE_SITTER WEBP XIM XWIDGETS GTK3 ZLIB
>
> I see your build is with native-compilation; mine is without.  The
> backtrace you posted:
>
>> #11 0x000062534cfba688 in shut_down_emacs ()
>> #12 0x000062534cfba3ba in terminate_due_to_signal ()
>> #13 0x000062534cff5be4 in handle_sigsegv ()
>> #14 0x0000723f608fd770 in <signal handler called> () at /usr/lib/libc.so.6
>> #15 0x000062534d063429 in process_mark_stack ()
>> #16 0x000062534d1649f1 in traverse_intervals_noorder ()
>> #17 0x000062534d063e5e in process_mark_stack ()
>> #18 0x000062534d063ceb in process_mark_stack ()
>> #19 0x000062534d063ceb in process_mark_stack ()
>> #20 0x000062534d064fab in mark_char_table ()
>> #21 0x000062534d0650f6 in mark_char_table ()
>> #22 0x000062534d063c0c in process_mark_stack ()
>> #23 0x000062534d063ceb in process_mark_stack ()
>> #24 0x000062534d063ceb in process_mark_stack ()
>> #25 0x000062534d063ceb in process_mark_stack ()
>> #26 0x000062534d0663be in garbage_collect ()
>> #27 0x000062534d11e30b in exec_byte_code ()
>> #28 0x000062534d0a5406 in Ffuncall ()
>> #29 0x000062534d0a58df in Fapply ()
>> #30 0x000062534d137961 in read_process_output_call ()
>> #31 0x000062534d0ae619 in internal_condition_case_1 ()
>> #32 0x000062534d137820 in exec_sentinel ()
>> #33 0x000062534d135d2f in status_notify ()
>> #34 0x000062534d13b00c in wait_reading_process_output ()



>
> indicates that Emacs crashed after some sub-process exited, the
> process sentinel was called, and that caused us to run some Lips and
> perform GC.  Any idea what that subprocess was? could it be the async
> native-compilation of some Lisp file?  Can you try building without
> native-compilation and see if the problem happens there as well?


I rebuild it without native-compilation, and it still crashes.
Backtrace:

#0  0x000077b79c65c32c in ??? () at /usr/lib/libc.so.6
#1  0x000077b79c60b6c8 in raise () at /usr/lib/libc.so.6
#2  0x00005a5a428f94a2 in terminate_due_to_signal ()
#3  0x00005a5a42933c23 in emacs_abort ()
#4  0x00005a5a429ec268 in signal_or_quit ()
#5  0x00005a5a429eb422 in Fsignal ()
#6  0x00005a5a429eb401 in xsignal ()
#7  0x00005a5a429e9aa2 in xsignal2 ()
#8  0x00005a5a429c0865 in wrong_type_argument ()
#9  0x00005a5a42965e1f in Fexpand_file_name ()
#10 0x00005a5a42b3d200 in Fdo_auto_save.7873 ()
#11 0x00005a5a428f9738 in shut_down_emacs ()
#12 0x00005a5a428f946a in terminate_due_to_signal ()
#13 0x00005a5a42935924 in handle_sigsegv ()
#14 0x000077b79c60b770 in <signal handler called> () at /usr/lib/libc.so.6
#15 0x00005a5a429a57f6 in process_mark_stack ()
#16 0x00005a5a429a677b in mark_char_table ()
#17 0x00005a5a429a68c6 in mark_char_table ()
#18 0x00005a5a429a55bd in process_mark_stack ()
#19 0x00005a5a429a677b in mark_char_table ()
#20 0x00005a5a429a68c6 in mark_char_table ()
#21 0x00005a5a429a55bd in process_mark_stack ()
#22 0x00005a5a429a677b in mark_char_table ()
#23 0x00005a5a429a68c6 in mark_char_table ()
#24 0x00005a5a429a55bd in process_mark_stack ()
#25 0x00005a5a429a677b in mark_char_table ()
#26 0x00005a5a429a68c6 in mark_char_table ()
#27 0x00005a5a429a55bd in process_mark_stack ()
#28 0x00005a5a429a569b in process_mark_stack ()
#29 0x00005a5a429a569b in process_mark_stack ()
#30 0x00005a5a429a569b in process_mark_stack ()
#31 0x00005a5a429a7b8e in garbage_collect ()
#32 0x00005a5a429e76e7 in Ffuncall ()
#33 0x00005a5a42a094f7 in mapcar1 ()
#34 0x00005a5a42a091bf in Fmapconcat ()
#35 0x00005a5a42ac9d90 in Ftreesit_pattern_expand ()
#36 0x00005a5a429e87b3 in funcall_subr ()
#37 0x00005a5a429e77f6 in Ffuncall ()
#38 0x00005a5a42a094f7 in mapcar1 ()
#39 0x00005a5a42a091bf in Fmapconcat ()
#40 0x00005a5a42ac9d90 in Ftreesit_pattern_expand ()
#41 0x00005a5a429e87b3 in funcall_subr ()
#42 0x00005a5a429e77f6 in Ffuncall ()
#43 0x00005a5a42a094f7 in mapcar1 ()
#44 0x00005a5a42a091bf in Fmapconcat ()
#45 0x00005a5a42aca243 in treesit_ensure_query_compiled ()
#46 0x00005a5a42aca5c0 in Ftreesit_query_capture ()
#47 0x00005a5a429e880a in funcall_subr ()
#48 0x00005a5a42a606de in exec_byte_code ()
#49 0x00005a5a429e77f6 in Ffuncall ()
#50 0x00005a5a429f1f5c in Frun_hook_wrapped ()
#51 0x00005a5a42a606de in exec_byte_code ()
#52 0x00005a5a429e77f6 in Ffuncall ()
#53 0x00005a5a429f0ad7 in internal_condition_case_n ()
#54 0x00005a5a427f2ef7 in handle_stop ()
#55 0x00005a5a42803822 in start_display ()
#56 0x00005a5a4282b922 in try_window ()
#57 0x00005a5a42826f1a in redisplay_window ()
#58 0x00005a5a4283a927 in redisplay_window_0 ()
#59 0x00005a5a429f09b9 in internal_condition_case_1 ()
#60 0x00005a5a42821a55 in redisplay_windows ()
#61 0x00005a5a42819a36 in redisplay_internal ()
#62 0x00005a5a42907548 in read_char ()
#63 0x00005a5a42903deb in read_key_sequence ()
#64 0x00005a5a429019f9 in command_loop_1 ()
#65 0x00005a5a429f0937 in internal_condition_case ()
#66 0x00005a5a4290085e in command_loop_2 ()
#67 0x00005a5a429ef7f1 in internal_catch ()
#68 0x00005a5a4290080c in command_loop ()
#69 0x00005a5a42900676 in recursive_edit_1 ()
#70 0x00005a5a429178d7 in Frecursive_edit ()
#71 0x00005a5a428fe4fa in main ()
>
> Also, do you see c-ts-mode's .eln file in your eln-cache directory?

Yes it's there when emacs is compiled with native-compilation

>
> Andrea, can you try reproducing this?

bug#70059: 30.0.50; c-ts-mode crashes emacs

[Eli Zaretskii]

> From: Felix <felix.dick@web.de>
> Cc: Andrea Corallo <acorallo@gnu.org>,  70059@debbugs.gnu.org
> Date: Fri, 29 Mar 2024 11:51:06 +0100
> 
> I rebuild it without native-compilation, and it still crashes.
> Backtrace:
> 
> #0  0x000077b79c65c32c in ??? () at /usr/lib/libc.so.6
> #1  0x000077b79c60b6c8 in raise () at /usr/lib/libc.so.6
> #2  0x00005a5a428f94a2 in terminate_due_to_signal ()
> #3  0x00005a5a42933c23 in emacs_abort ()
> #4  0x00005a5a429ec268 in signal_or_quit ()
> #5  0x00005a5a429eb422 in Fsignal ()
> #6  0x00005a5a429eb401 in xsignal ()
> #7  0x00005a5a429e9aa2 in xsignal2 ()
> #8  0x00005a5a429c0865 in wrong_type_argument ()
> #9  0x00005a5a42965e1f in Fexpand_file_name ()
> #10 0x00005a5a42b3d200 in Fdo_auto_save.7873 ()
> #11 0x00005a5a428f9738 in shut_down_emacs ()
> #12 0x00005a5a428f946a in terminate_due_to_signal ()
> #13 0x00005a5a42935924 in handle_sigsegv ()
> #14 0x000077b79c60b770 in <signal handler called> () at /usr/lib/libc.so.6
> #15 0x00005a5a429a57f6 in process_mark_stack ()
> #16 0x00005a5a429a677b in mark_char_table ()
> #17 0x00005a5a429a68c6 in mark_char_table ()
> #18 0x00005a5a429a55bd in process_mark_stack ()
> #19 0x00005a5a429a677b in mark_char_table ()
> #20 0x00005a5a429a68c6 in mark_char_table ()
> #21 0x00005a5a429a55bd in process_mark_stack ()
> #22 0x00005a5a429a677b in mark_char_table ()
> #23 0x00005a5a429a68c6 in mark_char_table ()
> #24 0x00005a5a429a55bd in process_mark_stack ()
> #25 0x00005a5a429a677b in mark_char_table ()
> #26 0x00005a5a429a68c6 in mark_char_table ()
> #27 0x00005a5a429a55bd in process_mark_stack ()
> #28 0x00005a5a429a569b in process_mark_stack ()
> #29 0x00005a5a429a569b in process_mark_stack ()
> #30 0x00005a5a429a569b in process_mark_stack ()
> #31 0x00005a5a429a7b8e in garbage_collect ()
> #32 0x00005a5a429e76e7 in Ffuncall ()
> #33 0x00005a5a42a094f7 in mapcar1 ()
> #34 0x00005a5a42a091bf in Fmapconcat ()
> #35 0x00005a5a42ac9d90 in Ftreesit_pattern_expand ()
> #36 0x00005a5a429e87b3 in funcall_subr ()
> #37 0x00005a5a429e77f6 in Ffuncall ()
> #38 0x00005a5a42a094f7 in mapcar1 ()
> #39 0x00005a5a42a091bf in Fmapconcat ()
> #40 0x00005a5a42ac9d90 in Ftreesit_pattern_expand ()
> #41 0x00005a5a429e87b3 in funcall_subr ()
> #42 0x00005a5a429e77f6 in Ffuncall ()
> #43 0x00005a5a42a094f7 in mapcar1 ()
> #44 0x00005a5a42a091bf in Fmapconcat ()
> #45 0x00005a5a42aca243 in treesit_ensure_query_compiled ()
> #46 0x00005a5a42aca5c0 in Ftreesit_query_capture ()

Then it's strange, since it doesn't happen here.  Does it happen for
you with any C source file, including those in the Emacs source tree?
If this happens only for some files, can you post one such file?

Also, what version of the tree-sitter library are you using, and what
version of the C grammar library?

If you can build the emacs-29 branch, can you try reproducing there?

Yuan, any ideas, based on the backtrace?

bug#70059: 30.0.50; c-ts-mode crashes emacs

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

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Felix <felix.dick@web.de>
>> Cc: Andrea Corallo <acorallo@gnu.org>,  70059@debbugs.gnu.org
>> Date: Fri, 29 Mar 2024 11:51:06 +0100
>>
>> I rebuild it without native-compilation, and it still crashes.
>> Backtrace:
>>
>> #0  0x000077b79c65c32c in ??? () at /usr/lib/libc.so.6
>> #1  0x000077b79c60b6c8 in raise () at /usr/lib/libc.so.6
>> #2  0x00005a5a428f94a2 in terminate_due_to_signal ()
>> #3  0x00005a5a42933c23 in emacs_abort ()
>> #4  0x00005a5a429ec268 in signal_or_quit ()
>> #5  0x00005a5a429eb422 in Fsignal ()
>> #6  0x00005a5a429eb401 in xsignal ()
>> #7  0x00005a5a429e9aa2 in xsignal2 ()
>> #8  0x00005a5a429c0865 in wrong_type_argument ()
>> #9  0x00005a5a42965e1f in Fexpand_file_name ()
>> #10 0x00005a5a42b3d200 in Fdo_auto_save.7873 ()
>> #11 0x00005a5a428f9738 in shut_down_emacs ()
>> #12 0x00005a5a428f946a in terminate_due_to_signal ()
>> #13 0x00005a5a42935924 in handle_sigsegv ()
>> #14 0x000077b79c60b770 in <signal handler called> () at /usr/lib/libc.so.6
>> #15 0x00005a5a429a57f6 in process_mark_stack ()
>> #16 0x00005a5a429a677b in mark_char_table ()
>> #17 0x00005a5a429a68c6 in mark_char_table ()
>> #18 0x00005a5a429a55bd in process_mark_stack ()
>> #19 0x00005a5a429a677b in mark_char_table ()
>> #20 0x00005a5a429a68c6 in mark_char_table ()
>> #21 0x00005a5a429a55bd in process_mark_stack ()
>> #22 0x00005a5a429a677b in mark_char_table ()
>> #23 0x00005a5a429a68c6 in mark_char_table ()
>> #24 0x00005a5a429a55bd in process_mark_stack ()
>> #25 0x00005a5a429a677b in mark_char_table ()
>> #26 0x00005a5a429a68c6 in mark_char_table ()
>> #27 0x00005a5a429a55bd in process_mark_stack ()
>> #28 0x00005a5a429a569b in process_mark_stack ()
>> #29 0x00005a5a429a569b in process_mark_stack ()
>> #30 0x00005a5a429a569b in process_mark_stack ()
>> #31 0x00005a5a429a7b8e in garbage_collect ()
>> #32 0x00005a5a429e76e7 in Ffuncall ()
>> #33 0x00005a5a42a094f7 in mapcar1 ()
>> #34 0x00005a5a42a091bf in Fmapconcat ()
>> #35 0x00005a5a42ac9d90 in Ftreesit_pattern_expand ()
>> #36 0x00005a5a429e87b3 in funcall_subr ()
>> #37 0x00005a5a429e77f6 in Ffuncall ()
>> #38 0x00005a5a42a094f7 in mapcar1 ()
>> #39 0x00005a5a42a091bf in Fmapconcat ()
>> #40 0x00005a5a42ac9d90 in Ftreesit_pattern_expand ()
>> #41 0x00005a5a429e87b3 in funcall_subr ()
>> #42 0x00005a5a429e77f6 in Ffuncall ()
>> #43 0x00005a5a42a094f7 in mapcar1 ()
>> #44 0x00005a5a42a091bf in Fmapconcat ()
>> #45 0x00005a5a42aca243 in treesit_ensure_query_compiled ()
>> #46 0x00005a5a42aca5c0 in Ftreesit_query_capture ()
>
> Then it's strange, since it doesn't happen here.  Does it happen for
> you with any C source file, including those in the Emacs source tree?
> If this happens only for some files, can you post one such file?
>
> Also, what version of the tree-sitter library are you using, and what
> version of the C grammar library?
>
> If you can build the emacs-29 branch, can you try reproducing there?
>
> Yuan, any ideas, based on the backtrace?

I was using tree-sitter build from the git repository, when i use it
from the official arch linux repos, it doesn't crash (at least until
now).
I think this is tree-sitter related, but it shouldn't be able to crash
emacs, should it?
Depending on the answer this report could be closed.

bug#70059: 30.0.50; c-ts-mode crashes emacs

[Eli Zaretskii]

> From: Felix <felix.dick@web.de>
> Cc: Yuan Fu <casouri@gmail.com>,  70059@debbugs.gnu.org
> Date: Fri, 29 Mar 2024 12:37:03 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Felix <felix.dick@web.de>
> >> Cc: Andrea Corallo <acorallo@gnu.org>,  70059@debbugs.gnu.org
> >> Date: Fri, 29 Mar 2024 11:51:06 +0100
> >>
> >> I rebuild it without native-compilation, and it still crashes.
> >> Backtrace:
> >>
> >> #0  0x000077b79c65c32c in ??? () at /usr/lib/libc.so.6
> >> #1  0x000077b79c60b6c8 in raise () at /usr/lib/libc.so.6
> >> #2  0x00005a5a428f94a2 in terminate_due_to_signal ()
> >> #3  0x00005a5a42933c23 in emacs_abort ()
> >> #4  0x00005a5a429ec268 in signal_or_quit ()
> >> #5  0x00005a5a429eb422 in Fsignal ()
> >> #6  0x00005a5a429eb401 in xsignal ()
> >> #7  0x00005a5a429e9aa2 in xsignal2 ()
> >> #8  0x00005a5a429c0865 in wrong_type_argument ()
> >> #9  0x00005a5a42965e1f in Fexpand_file_name ()
> >> #10 0x00005a5a42b3d200 in Fdo_auto_save.7873 ()
> >> #11 0x00005a5a428f9738 in shut_down_emacs ()
> >> #12 0x00005a5a428f946a in terminate_due_to_signal ()
> >> #13 0x00005a5a42935924 in handle_sigsegv ()
> >> #14 0x000077b79c60b770 in <signal handler called> () at /usr/lib/libc.so.6
> >> #15 0x00005a5a429a57f6 in process_mark_stack ()
> >> #16 0x00005a5a429a677b in mark_char_table ()
> >> #17 0x00005a5a429a68c6 in mark_char_table ()
> >> #18 0x00005a5a429a55bd in process_mark_stack ()
> >> #19 0x00005a5a429a677b in mark_char_table ()
> >> #20 0x00005a5a429a68c6 in mark_char_table ()
> >> #21 0x00005a5a429a55bd in process_mark_stack ()
> >> #22 0x00005a5a429a677b in mark_char_table ()
> >> #23 0x00005a5a429a68c6 in mark_char_table ()
> >> #24 0x00005a5a429a55bd in process_mark_stack ()
> >> #25 0x00005a5a429a677b in mark_char_table ()
> >> #26 0x00005a5a429a68c6 in mark_char_table ()
> >> #27 0x00005a5a429a55bd in process_mark_stack ()
> >> #28 0x00005a5a429a569b in process_mark_stack ()
> >> #29 0x00005a5a429a569b in process_mark_stack ()
> >> #30 0x00005a5a429a569b in process_mark_stack ()
> >> #31 0x00005a5a429a7b8e in garbage_collect ()
> >> #32 0x00005a5a429e76e7 in Ffuncall ()
> >> #33 0x00005a5a42a094f7 in mapcar1 ()
> >> #34 0x00005a5a42a091bf in Fmapconcat ()
> >> #35 0x00005a5a42ac9d90 in Ftreesit_pattern_expand ()
> >> #36 0x00005a5a429e87b3 in funcall_subr ()
> >> #37 0x00005a5a429e77f6 in Ffuncall ()
> >> #38 0x00005a5a42a094f7 in mapcar1 ()
> >> #39 0x00005a5a42a091bf in Fmapconcat ()
> >> #40 0x00005a5a42ac9d90 in Ftreesit_pattern_expand ()
> >> #41 0x00005a5a429e87b3 in funcall_subr ()
> >> #42 0x00005a5a429e77f6 in Ffuncall ()
> >> #43 0x00005a5a42a094f7 in mapcar1 ()
> >> #44 0x00005a5a42a091bf in Fmapconcat ()
> >> #45 0x00005a5a42aca243 in treesit_ensure_query_compiled ()
> >> #46 0x00005a5a42aca5c0 in Ftreesit_query_capture ()
> >
> > Then it's strange, since it doesn't happen here.  Does it happen for
> > you with any C source file, including those in the Emacs source tree?
> > If this happens only for some files, can you post one such file?
> >
> > Also, what version of the tree-sitter library are you using, and what
> > version of the C grammar library?
> >
> > If you can build the emacs-29 branch, can you try reproducing there?
> >
> > Yuan, any ideas, based on the backtrace?
> 
> I was using tree-sitter build from the git repository, when i use it
> from the official arch linux repos, it doesn't crash (at least until
> now).
> I think this is tree-sitter related, but it shouldn't be able to crash
> emacs, should it?

It shouldn't, unless there's some memory-related snafu (which could
explain why the crash is always in GC).  I hope Yuan will be able to
tell.

bug#70059: 30.0.50; c-ts-mode crashes emacs

[Yuan Fu]

> On Mar 29, 2024, at 5:08 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Felix <felix.dick@web.de>
>> Cc: Yuan Fu <casouri@gmail.com>,  70059@debbugs.gnu.org
>> Date: Fri, 29 Mar 2024 12:37:03 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>>>> From: Felix <felix.dick@web.de>
>>>> Cc: Andrea Corallo <acorallo@gnu.org>,  70059@debbugs.gnu.org
>>>> Date: Fri, 29 Mar 2024 11:51:06 +0100
>>>> 
>>>> I rebuild it without native-compilation, and it still crashes.
>>>> Backtrace:
>>>> 
>>>> #0  0x000077b79c65c32c in ??? () at /usr/lib/libc.so.6
>>>> #1  0x000077b79c60b6c8 in raise () at /usr/lib/libc.so.6
>>>> #2  0x00005a5a428f94a2 in terminate_due_to_signal ()
>>>> #3  0x00005a5a42933c23 in emacs_abort ()
>>>> #4  0x00005a5a429ec268 in signal_or_quit ()
>>>> #5  0x00005a5a429eb422 in Fsignal ()
>>>> #6  0x00005a5a429eb401 in xsignal ()
>>>> #7  0x00005a5a429e9aa2 in xsignal2 ()
>>>> #8  0x00005a5a429c0865 in wrong_type_argument ()
>>>> #9  0x00005a5a42965e1f in Fexpand_file_name ()
>>>> #10 0x00005a5a42b3d200 in Fdo_auto_save.7873 ()
>>>> #11 0x00005a5a428f9738 in shut_down_emacs ()
>>>> #12 0x00005a5a428f946a in terminate_due_to_signal ()
>>>> #13 0x00005a5a42935924 in handle_sigsegv ()
>>>> #14 0x000077b79c60b770 in <signal handler called> () at /usr/lib/libc.so.6
>>>> #15 0x00005a5a429a57f6 in process_mark_stack ()
>>>> #16 0x00005a5a429a677b in mark_char_table ()
>>>> #17 0x00005a5a429a68c6 in mark_char_table ()
>>>> #18 0x00005a5a429a55bd in process_mark_stack ()
>>>> #19 0x00005a5a429a677b in mark_char_table ()
>>>> #20 0x00005a5a429a68c6 in mark_char_table ()
>>>> #21 0x00005a5a429a55bd in process_mark_stack ()
>>>> #22 0x00005a5a429a677b in mark_char_table ()
>>>> #23 0x00005a5a429a68c6 in mark_char_table ()
>>>> #24 0x00005a5a429a55bd in process_mark_stack ()
>>>> #25 0x00005a5a429a677b in mark_char_table ()
>>>> #26 0x00005a5a429a68c6 in mark_char_table ()
>>>> #27 0x00005a5a429a55bd in process_mark_stack ()
>>>> #28 0x00005a5a429a569b in process_mark_stack ()
>>>> #29 0x00005a5a429a569b in process_mark_stack ()
>>>> #30 0x00005a5a429a569b in process_mark_stack ()
>>>> #31 0x00005a5a429a7b8e in garbage_collect ()
>>>> #32 0x00005a5a429e76e7 in Ffuncall ()
>>>> #33 0x00005a5a42a094f7 in mapcar1 ()
>>>> #34 0x00005a5a42a091bf in Fmapconcat ()
>>>> #35 0x00005a5a42ac9d90 in Ftreesit_pattern_expand ()
>>>> #36 0x00005a5a429e87b3 in funcall_subr ()
>>>> #37 0x00005a5a429e77f6 in Ffuncall ()
>>>> #38 0x00005a5a42a094f7 in mapcar1 ()
>>>> #39 0x00005a5a42a091bf in Fmapconcat ()
>>>> #40 0x00005a5a42ac9d90 in Ftreesit_pattern_expand ()
>>>> #41 0x00005a5a429e87b3 in funcall_subr ()
>>>> #42 0x00005a5a429e77f6 in Ffuncall ()
>>>> #43 0x00005a5a42a094f7 in mapcar1 ()
>>>> #44 0x00005a5a42a091bf in Fmapconcat ()
>>>> #45 0x00005a5a42aca243 in treesit_ensure_query_compiled ()
>>>> #46 0x00005a5a42aca5c0 in Ftreesit_query_capture ()
>>> 
>>> Then it's strange, since it doesn't happen here.  Does it happen for
>>> you with any C source file, including those in the Emacs source tree?
>>> If this happens only for some files, can you post one such file?
>>> 
>>> Also, what version of the tree-sitter library are you using, and what
>>> version of the C grammar library?
>>> 
>>> If you can build the emacs-29 branch, can you try reproducing there?
>>> 
>>> Yuan, any ideas, based on the backtrace?
>> 
>> I was using tree-sitter build from the git repository, when i use it
>> from the official arch linux repos, it doesn't crash (at least until
>> now).
>> I think this is tree-sitter related, but it shouldn't be able to crash
>> emacs, should it?
> 
> It shouldn't, unless there's some memory-related snafu (which could
> explain why the crash is always in GC).  I hope Yuan will be able to
> tell.

It’s a bit strange since Ftreesit_pattern_expand doesn’t call tree-sitter function. This function just expands a sexp query like '(function_definition @capture) to a string “(function_definition @capture)”. 

Perhaps something it does triggers GC and GC tries to collect some tree-sitter node or parser, and there’s some problem when freeing the node or parser with that version of tree-sitter library.

Also, I couldn’t reproduce with upstream tree-sitter plus emacs master either. I’m using commit 0b4403294981ffb6a51d153a5509a389b91fed86 for tree-sitter and commit 411f46fd365bc0008c58e1fa6bee6a60d841da75 for emacs. Felix, what commit are you using?

Yuan

bug#70059: 30.0.50; c-ts-mode crashes emacs

[Eli Zaretskii]

> From: Yuan Fu <casouri@gmail.com>
> Date: Sat, 30 Mar 2024 22:52:55 -0700
> Cc: Felix <felix.dick@web.de>,
>  70059@debbugs.gnu.org
> 
> It’s a bit strange since Ftreesit_pattern_expand doesn’t call tree-sitter function. This function just expands a sexp query like '(function_definition @capture) to a string “(function_definition @capture)”. 

I'm not sure I follow: the backtrace shows that
Ftreesit_pattern_expand called Fmapconcat, and I do see a call to
Fmapconcat in Ftreesit_pattern_expand.  So what did you mean by
"Ftreesit_pattern_expand doesn't call tree-sitter function"?

> Perhaps something it does triggers GC and GC tries to collect some tree-sitter node or parser, and there’s some problem when freeing the node or parser with that version of tree-sitter library.

Again, not sure I follow: according to the backtrace, Fmapconcat
called mapconcat1, which called Ffuncall.  And Ffuncall is known to
trigger GC if needed.

bug#70059: 30.0.50; c-ts-mode crashes emacs

[Yuan Fu]

> On Mar 31, 2024, at 12:43 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Yuan Fu <casouri@gmail.com>
>> Date: Sat, 30 Mar 2024 22:52:55 -0700
>> Cc: Felix <felix.dick@web.de>,
>> 70059@debbugs.gnu.org
>> 
>> It’s a bit strange since Ftreesit_pattern_expand doesn’t call tree-sitter function. This function just expands a sexp query like '(function_definition @capture) to a string “(function_definition @capture)”. 
> 
> I'm not sure I follow: the backtrace shows that
> Ftreesit_pattern_expand called Fmapconcat, and I do see a call to
> Fmapconcat in Ftreesit_pattern_expand.  So what did you mean by
> "Ftreesit_pattern_expand doesn't call tree-sitter function"?

I should've been more precise, I mean it doesn’t call functions from tree-sitter library.

> 
>> Perhaps something it does triggers GC and GC tries to collect some tree-sitter node or parser, and there’s some problem when freeing the node or parser with that version of tree-sitter library.
> 
> Again, not sure I follow: according to the backtrace, Fmapconcat
> called mapconcat1, which called Ffuncall.  And Ffuncall is known to
> trigger GC if needed.

Ah, I didn’t know it, thanks for explaining that.

Yuan

bug#70059: 30.0.50; c-ts-mode crashes emacs

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

Yuan Fu <casouri@gmail.com> writes:

>> On Mar 29, 2024, at 5:08 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>>
>>> From: Felix <felix.dick@web.de>
>>> Cc: Yuan Fu <casouri@gmail.com>,  70059@debbugs.gnu.org
>>> Date: Fri, 29 Mar 2024 12:37:03 +0100
>>>
>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>
>>>>> From: Felix <felix.dick@web.de>
>>>>> Cc: Andrea Corallo <acorallo@gnu.org>,  70059@debbugs.gnu.org
>>>>> Date: Fri, 29 Mar 2024 11:51:06 +0100
>>>>>
>>>>> I rebuild it without native-compilation, and it still crashes.
>>>>> Backtrace:
>>>>>
>>>>> #0  0x000077b79c65c32c in ??? () at /usr/lib/libc.so.6
>>>>> #1  0x000077b79c60b6c8 in raise () at /usr/lib/libc.so.6
>>>>> #2  0x00005a5a428f94a2 in terminate_due_to_signal ()
>>>>> #3  0x00005a5a42933c23 in emacs_abort ()
>>>>> #4  0x00005a5a429ec268 in signal_or_quit ()
>>>>> #5  0x00005a5a429eb422 in Fsignal ()
>>>>> #6  0x00005a5a429eb401 in xsignal ()
>>>>> #7  0x00005a5a429e9aa2 in xsignal2 ()
>>>>> #8  0x00005a5a429c0865 in wrong_type_argument ()
>>>>> #9  0x00005a5a42965e1f in Fexpand_file_name ()
>>>>> #10 0x00005a5a42b3d200 in Fdo_auto_save.7873 ()
>>>>> #11 0x00005a5a428f9738 in shut_down_emacs ()
>>>>> #12 0x00005a5a428f946a in terminate_due_to_signal ()
>>>>> #13 0x00005a5a42935924 in handle_sigsegv ()
>>>>> #14 0x000077b79c60b770 in <signal handler called> () at /usr/lib/libc.so.6
>>>>> #15 0x00005a5a429a57f6 in process_mark_stack ()
>>>>> #16 0x00005a5a429a677b in mark_char_table ()
>>>>> #17 0x00005a5a429a68c6 in mark_char_table ()
>>>>> #18 0x00005a5a429a55bd in process_mark_stack ()
>>>>> #19 0x00005a5a429a677b in mark_char_table ()
>>>>> #20 0x00005a5a429a68c6 in mark_char_table ()
>>>>> #21 0x00005a5a429a55bd in process_mark_stack ()
>>>>> #22 0x00005a5a429a677b in mark_char_table ()
>>>>> #23 0x00005a5a429a68c6 in mark_char_table ()
>>>>> #24 0x00005a5a429a55bd in process_mark_stack ()
>>>>> #25 0x00005a5a429a677b in mark_char_table ()
>>>>> #26 0x00005a5a429a68c6 in mark_char_table ()
>>>>> #27 0x00005a5a429a55bd in process_mark_stack ()
>>>>> #28 0x00005a5a429a569b in process_mark_stack ()
>>>>> #29 0x00005a5a429a569b in process_mark_stack ()
>>>>> #30 0x00005a5a429a569b in process_mark_stack ()
>>>>> #31 0x00005a5a429a7b8e in garbage_collect ()
>>>>> #32 0x00005a5a429e76e7 in Ffuncall ()
>>>>> #33 0x00005a5a42a094f7 in mapcar1 ()
>>>>> #34 0x00005a5a42a091bf in Fmapconcat ()
>>>>> #35 0x00005a5a42ac9d90 in Ftreesit_pattern_expand ()
>>>>> #36 0x00005a5a429e87b3 in funcall_subr ()
>>>>> #37 0x00005a5a429e77f6 in Ffuncall ()
>>>>> #38 0x00005a5a42a094f7 in mapcar1 ()
>>>>> #39 0x00005a5a42a091bf in Fmapconcat ()
>>>>> #40 0x00005a5a42ac9d90 in Ftreesit_pattern_expand ()
>>>>> #41 0x00005a5a429e87b3 in funcall_subr ()
>>>>> #42 0x00005a5a429e77f6 in Ffuncall ()
>>>>> #43 0x00005a5a42a094f7 in mapcar1 ()
>>>>> #44 0x00005a5a42a091bf in Fmapconcat ()
>>>>> #45 0x00005a5a42aca243 in treesit_ensure_query_compiled ()
>>>>> #46 0x00005a5a42aca5c0 in Ftreesit_query_capture ()
>>>>
>>>> Then it's strange, since it doesn't happen here.  Does it happen for
>>>> you with any C source file, including those in the Emacs source tree?
>>>> If this happens only for some files, can you post one such file?
>>>>
>>>> Also, what version of the tree-sitter library are you using, and what
>>>> version of the C grammar library?
>>>>
>>>> If you can build the emacs-29 branch, can you try reproducing there?
>>>>
>>>> Yuan, any ideas, based on the backtrace?
>>>
>>> I was using tree-sitter build from the git repository, when i use it
>>> from the official arch linux repos, it doesn't crash (at least until
>>> now).
>>> I think this is tree-sitter related, but it shouldn't be able to crash
>>> emacs, should it?
>>
>> It shouldn't, unless there's some memory-related snafu (which could
>> explain why the crash is always in GC).  I hope Yuan will be able to
>> tell.
>
> It’s a bit strange since Ftreesit_pattern_expand doesn’t call
> tree-sitter function. This function just expands a sexp query like
> '(function_definition @capture) to a string “(function_definition
> @capture)”.
>
> Perhaps something it does triggers GC and GC tries to collect some tree-sitter node or parser, and there’s some problem when freeing the node or parser with that version of tree-sitter library.
>
> Also, I couldn’t reproduce with upstream tree-sitter plus emacs master
> either. I’m using commit 0b4403294981ffb6a51d153a5509a389b91fed86 for
> tree-sitter and commit 411f46fd365bc0008c58e1fa6bee6a60d841da75 for
> emacs. Felix, what commit are you using?
>
> Yuan

It still crashes on my computer if i use:
GNU Emacs 30.0.50 (build 11, x86_64-pc-linux-gnu, GTK+ Version 3.24.41, cairo version 1.18.0) of 2024-03-31
and
tree-sitter 0.22.2 (fc15f621334a262039ffaded5937e2844f88da61)

But as i wrote, it doesn't crash with tree-sitter from the official arch
linux repos, and because i program in C every day, i switched to the
stable tree-sitter and had no problems since.

That's why i asked if a faulty tree-sitter should be able to crash
emacs. If that is acceptable, this bug report can be closed.

bug#70059: 30.0.50; c-ts-mode crashes emacs

[Yuan Fu]

> On Mar 31, 2024, at 1:09 AM, Felix <felix.dick@web.de> wrote:
> 
> Yuan Fu <casouri@gmail.com> writes:
> 
>>> On Mar 29, 2024, at 5:08 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>>> 
>>>> From: Felix <felix.dick@web.de>
>>>> Cc: Yuan Fu <casouri@gmail.com>,  70059@debbugs.gnu.org
>>>> Date: Fri, 29 Mar 2024 12:37:03 +0100
>>>> 
>>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>> 
>>>>>> From: Felix <felix.dick@web.de>
>>>>>> Cc: Andrea Corallo <acorallo@gnu.org>,  70059@debbugs.gnu.org
>>>>>> Date: Fri, 29 Mar 2024 11:51:06 +0100
>>>>>> 
>>>>>> I rebuild it without native-compilation, and it still crashes.
>>>>>> Backtrace:
>>>>>> 
>>>>>> #0  0x000077b79c65c32c in ??? () at /usr/lib/libc.so.6
>>>>>> #1  0x000077b79c60b6c8 in raise () at /usr/lib/libc.so.6
>>>>>> #2  0x00005a5a428f94a2 in terminate_due_to_signal ()
>>>>>> #3  0x00005a5a42933c23 in emacs_abort ()
>>>>>> #4  0x00005a5a429ec268 in signal_or_quit ()
>>>>>> #5  0x00005a5a429eb422 in Fsignal ()
>>>>>> #6  0x00005a5a429eb401 in xsignal ()
>>>>>> #7  0x00005a5a429e9aa2 in xsignal2 ()
>>>>>> #8  0x00005a5a429c0865 in wrong_type_argument ()
>>>>>> #9  0x00005a5a42965e1f in Fexpand_file_name ()
>>>>>> #10 0x00005a5a42b3d200 in Fdo_auto_save.7873 ()
>>>>>> #11 0x00005a5a428f9738 in shut_down_emacs ()
>>>>>> #12 0x00005a5a428f946a in terminate_due_to_signal ()
>>>>>> #13 0x00005a5a42935924 in handle_sigsegv ()
>>>>>> #14 0x000077b79c60b770 in <signal handler called> () at /usr/lib/libc.so.6
>>>>>> #15 0x00005a5a429a57f6 in process_mark_stack ()
>>>>>> #16 0x00005a5a429a677b in mark_char_table ()
>>>>>> #17 0x00005a5a429a68c6 in mark_char_table ()
>>>>>> #18 0x00005a5a429a55bd in process_mark_stack ()
>>>>>> #19 0x00005a5a429a677b in mark_char_table ()
>>>>>> #20 0x00005a5a429a68c6 in mark_char_table ()
>>>>>> #21 0x00005a5a429a55bd in process_mark_stack ()
>>>>>> #22 0x00005a5a429a677b in mark_char_table ()
>>>>>> #23 0x00005a5a429a68c6 in mark_char_table ()
>>>>>> #24 0x00005a5a429a55bd in process_mark_stack ()
>>>>>> #25 0x00005a5a429a677b in mark_char_table ()
>>>>>> #26 0x00005a5a429a68c6 in mark_char_table ()
>>>>>> #27 0x00005a5a429a55bd in process_mark_stack ()
>>>>>> #28 0x00005a5a429a569b in process_mark_stack ()
>>>>>> #29 0x00005a5a429a569b in process_mark_stack ()
>>>>>> #30 0x00005a5a429a569b in process_mark_stack ()
>>>>>> #31 0x00005a5a429a7b8e in garbage_collect ()
>>>>>> #32 0x00005a5a429e76e7 in Ffuncall ()
>>>>>> #33 0x00005a5a42a094f7 in mapcar1 ()
>>>>>> #34 0x00005a5a42a091bf in Fmapconcat ()
>>>>>> #35 0x00005a5a42ac9d90 in Ftreesit_pattern_expand ()
>>>>>> #36 0x00005a5a429e87b3 in funcall_subr ()
>>>>>> #37 0x00005a5a429e77f6 in Ffuncall ()
>>>>>> #38 0x00005a5a42a094f7 in mapcar1 ()
>>>>>> #39 0x00005a5a42a091bf in Fmapconcat ()
>>>>>> #40 0x00005a5a42ac9d90 in Ftreesit_pattern_expand ()
>>>>>> #41 0x00005a5a429e87b3 in funcall_subr ()
>>>>>> #42 0x00005a5a429e77f6 in Ffuncall ()
>>>>>> #43 0x00005a5a42a094f7 in mapcar1 ()
>>>>>> #44 0x00005a5a42a091bf in Fmapconcat ()
>>>>>> #45 0x00005a5a42aca243 in treesit_ensure_query_compiled ()
>>>>>> #46 0x00005a5a42aca5c0 in Ftreesit_query_capture ()
>>>>> 
>>>>> Then it's strange, since it doesn't happen here.  Does it happen for
>>>>> you with any C source file, including those in the Emacs source tree?
>>>>> If this happens only for some files, can you post one such file?
>>>>> 
>>>>> Also, what version of the tree-sitter library are you using, and what
>>>>> version of the C grammar library?
>>>>> 
>>>>> If you can build the emacs-29 branch, can you try reproducing there?
>>>>> 
>>>>> Yuan, any ideas, based on the backtrace?
>>>> 
>>>> I was using tree-sitter build from the git repository, when i use it
>>>> from the official arch linux repos, it doesn't crash (at least until
>>>> now).
>>>> I think this is tree-sitter related, but it shouldn't be able to crash
>>>> emacs, should it?
>>> 
>>> It shouldn't, unless there's some memory-related snafu (which could
>>> explain why the crash is always in GC).  I hope Yuan will be able to
>>> tell.
>> 
>> It’s a bit strange since Ftreesit_pattern_expand doesn’t call
>> tree-sitter function. This function just expands a sexp query like
>> '(function_definition @capture) to a string “(function_definition
>> @capture)”.
>> 
>> Perhaps something it does triggers GC and GC tries to collect some tree-sitter node or parser, and there’s some problem when freeing the node or parser with that version of tree-sitter library.
>> 
>> Also, I couldn’t reproduce with upstream tree-sitter plus emacs master
>> either. I’m using commit 0b4403294981ffb6a51d153a5509a389b91fed86 for
>> tree-sitter and commit 411f46fd365bc0008c58e1fa6bee6a60d841da75 for
>> emacs. Felix, what commit are you using?
>> 
>> Yuan
> 
> It still crashes on my computer if i use:
> GNU Emacs 30.0.50 (build 11, x86_64-pc-linux-gnu, GTK+ Version 3.24.41, cairo version 1.18.0) of 2024-03-31
> and
> tree-sitter 0.22.2 (fc15f621334a262039ffaded5937e2844f88da61)
> 
> But as i wrote, it doesn't crash with tree-sitter from the official arch
> linux repos, and because i program in C every day, i switched to the
> stable tree-sitter and had no problems since.
> 
> That's why i asked if a faulty tree-sitter should be able to crash
> emacs. If that is acceptable, this bug report can be closed.

I mean tree-sitter (the library) runs in the main thread, if it triggers a segfault, AFAIK Emacs currently can’t really do anything. Is that right Eli?

Yuan

bug#70059: 30.0.50; c-ts-mode crashes emacs

[Eli Zaretskii]

> From: Yuan Fu <casouri@gmail.com>
> Date: Tue, 2 Apr 2024 11:22:44 -0700
> Cc: Eli Zaretskii <eliz@gnu.org>,
>  70059@debbugs.gnu.org
> 
> > But as i wrote, it doesn't crash with tree-sitter from the official arch
> > linux repos, and because i program in C every day, i switched to the
> > stable tree-sitter and had no problems since.
> > 
> > That's why i asked if a faulty tree-sitter should be able to crash
> > emacs. If that is acceptable, this bug report can be closed.
> 
> I mean tree-sitter (the library) runs in the main thread, if it triggers a segfault, AFAIK Emacs currently can’t really do anything. Is that right Eli?

You are right.  But these crashes seem to be inside GC, which
processes our objects, so if tree-sitter somehow causes us to create
invalid Lisp objects, it's our fault, at least to some extent.

bug#70059: 30.0.50; c-ts-mode crashes emacs

[Yuan Fu]

> On Apr 2, 2024, at 11:34 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Yuan Fu <casouri@gmail.com>
>> Date: Tue, 2 Apr 2024 11:22:44 -0700
>> Cc: Eli Zaretskii <eliz@gnu.org>,
>> 70059@debbugs.gnu.org
>> 
>>> But as i wrote, it doesn't crash with tree-sitter from the official arch
>>> linux repos, and because i program in C every day, i switched to the
>>> stable tree-sitter and had no problems since.
>>> 
>>> That's why i asked if a faulty tree-sitter should be able to crash
>>> emacs. If that is acceptable, this bug report can be closed.
>> 
>> I mean tree-sitter (the library) runs in the main thread, if it triggers a segfault, AFAIK Emacs currently can’t really do anything. Is that right Eli?
> 
> You are right.  But these crashes seem to be inside GC, which
> processes our objects, so if tree-sitter somehow causes us to create
> invalid Lisp objects, it's our fault, at least to some extent.

If the crash happens in ts_node_delete, ts_parser_delete or ts_tree_delete, would the backtrace record that? (Given that the tree-sitter library probably isn’g compile with symbols.) If the crash happens in those functions I think it’s not our fault.

Yuan

bug#70059: 30.0.50; c-ts-mode crashes emacs

[Eli Zaretskii]

> From: Yuan Fu <casouri@gmail.com>
> Date: Sun, 7 Apr 2024 23:32:01 -0700
> Cc: Felix <felix.dick@web.de>,
>  70059@debbugs.gnu.org
> 
> > On Apr 2, 2024, at 11:34 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> > 
> >> I mean tree-sitter (the library) runs in the main thread, if it triggers a segfault, AFAIK Emacs currently can’t really do anything. Is that right Eli?
> > 
> > You are right.  But these crashes seem to be inside GC, which
> > processes our objects, so if tree-sitter somehow causes us to create
> > invalid Lisp objects, it's our fault, at least to some extent.
> 
> If the crash happens in ts_node_delete, ts_parser_delete or ts_tree_delete, would the backtrace record that? (Given that the tree-sitter library probably isn’g compile with symbols.) If the crash happens in those functions I think it’s not our fault.

Even if tree-sitter was not compiled with debug symbols, we'd see the
library name in the backtrace.  Like here:

  #14 0x0000723f608fd770 in <signal handler called> () at /usr/lib/libc.so.6
  #15 0x000062534d063429 in process_mark_stack ()
  #16 0x000062534d1649f1 in traverse_intervals_noorder ()
  #17 0x000062534d063e5e in process_mark_stack ()
  #18 0x000062534d063ceb in process_mark_stack ()
  #19 0x000062534d063ceb in process_mark_stack ()
  #20 0x000062534d064fab in mark_char_table ()
  #21 0x000062534d0650f6 in mark_char_table ()

As you see, the fact that the crash happened in libc is shown, even
though we have no symbols for libc.

Looking at the two backtraces posted in this bug, I see that each time
the crashes were while processing some char-table.  I don't think
treesit-related code manipulates char-table's, does it?  So I don't
think treesit-related code is to blame here, it just so happened that
calling treesit-pattern-expand triggered GC; the invalid object was
probably created by some unrelated code.

bug#70059: 30.0.50; c-ts-mode crashes emacs

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

I think this problem posted on reddit might be related to this issue:
https://www.reddit.com/r/emacs/comments/1c3wpbt/emacs_crashes_with_treesitter_update/


Eli Zaretskii <eliz@gnu.org> writes:

>> From: Yuan Fu <casouri@gmail.com>
>> Date: Sun, 7 Apr 2024 23:32:01 -0700
>> Cc: Felix <felix.dick@web.de>,
>>  70059@debbugs.gnu.org
>> 
>> > On Apr 2, 2024, at 11:34 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> > 
>> >> I mean tree-sitter (the library) runs in the main thread, if it triggers a segfault, AFAIK Emacs currently can’t really do anything. Is that right Eli?
>> > 
>> > You are right.  But these crashes seem to be inside GC, which
>> > processes our objects, so if tree-sitter somehow causes us to create
>> > invalid Lisp objects, it's our fault, at least to some extent.
>> 
>> If the crash happens in ts_node_delete, ts_parser_delete or
>> ts_tree_delete, would the backtrace record that? (Given that the
>> tree-sitter library probably isn’g compile with symbols.) If the
>> crash happens in those functions I think it’s not our fault.
>
> Even if tree-sitter was not compiled with debug symbols, we'd see the
> library name in the backtrace.  Like here:
>
>   #14 0x0000723f608fd770 in <signal handler called> () at /usr/lib/libc.so.6
>   #15 0x000062534d063429 in process_mark_stack ()
>   #16 0x000062534d1649f1 in traverse_intervals_noorder ()
>   #17 0x000062534d063e5e in process_mark_stack ()
>   #18 0x000062534d063ceb in process_mark_stack ()
>   #19 0x000062534d063ceb in process_mark_stack ()
>   #20 0x000062534d064fab in mark_char_table ()
>   #21 0x000062534d0650f6 in mark_char_table ()
>
> As you see, the fact that the crash happened in libc is shown, even
> though we have no symbols for libc.
>
> Looking at the two backtraces posted in this bug, I see that each time
> the crashes were while processing some char-table.  I don't think
> treesit-related code manipulates char-table's, does it?  So I don't
> think treesit-related code is to blame here, it just so happened that
> calling treesit-pattern-expand triggered GC; the invalid object was
> probably created by some unrelated code.

bug#70059: 30.0.50; c-ts-mode crashes emacs

[Eli Zaretskii]

> From: Felix <felix.dick@web.de>
> Cc: Yuan Fu <casouri@gmail.com>,  70059@debbugs.gnu.org
> Date: Wed, 17 Apr 2024 15:13:30 +0200
> 
> 
> I think this problem posted on reddit might be related to this issue:
> https://www.reddit.com/r/emacs/comments/1c3wpbt/emacs_crashes_with_treesitter_update/

Thanks, but that discussion doesn't add any useful information,
unfortunately.

bug#70059: 30.0.50; c-ts-mode crashes emacs

[Andrea Corallo]

Felix via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs@gnu.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Felix <felix.dick@web.de>
>>> Cc: Andrea Corallo <acorallo@gnu.org>,  70059@debbugs.gnu.org
>>> Date: Fri, 29 Mar 2024 11:51:06 +0100
>>>
>>> I rebuild it without native-compilation, and it still crashes.
>>> Backtrace:
>>>
>>> #0  0x000077b79c65c32c in ??? () at /usr/lib/libc.so.6
>>> #1  0x000077b79c60b6c8 in raise () at /usr/lib/libc.so.6
>>> #2  0x00005a5a428f94a2 in terminate_due_to_signal ()
>>> #3  0x00005a5a42933c23 in emacs_abort ()
>>> #4  0x00005a5a429ec268 in signal_or_quit ()
>>> #5  0x00005a5a429eb422 in Fsignal ()
>>> #6  0x00005a5a429eb401 in xsignal ()
>>> #7  0x00005a5a429e9aa2 in xsignal2 ()
>>> #8  0x00005a5a429c0865 in wrong_type_argument ()
>>> #9  0x00005a5a42965e1f in Fexpand_file_name ()
>>> #10 0x00005a5a42b3d200 in Fdo_auto_save.7873 ()
>>> #11 0x00005a5a428f9738 in shut_down_emacs ()
>>> #12 0x00005a5a428f946a in terminate_due_to_signal ()
>>> #13 0x00005a5a42935924 in handle_sigsegv ()
>>> #14 0x000077b79c60b770 in <signal handler called> () at /usr/lib/libc.so.6
>>> #15 0x00005a5a429a57f6 in process_mark_stack ()
>>> #16 0x00005a5a429a677b in mark_char_table ()
>>> #17 0x00005a5a429a68c6 in mark_char_table ()
>>> #18 0x00005a5a429a55bd in process_mark_stack ()
>>> #19 0x00005a5a429a677b in mark_char_table ()
>>> #20 0x00005a5a429a68c6 in mark_char_table ()
>>> #21 0x00005a5a429a55bd in process_mark_stack ()
>>> #22 0x00005a5a429a677b in mark_char_table ()
>>> #23 0x00005a5a429a68c6 in mark_char_table ()
>>> #24 0x00005a5a429a55bd in process_mark_stack ()
>>> #25 0x00005a5a429a677b in mark_char_table ()
>>> #26 0x00005a5a429a68c6 in mark_char_table ()
>>> #27 0x00005a5a429a55bd in process_mark_stack ()
>>> #28 0x00005a5a429a569b in process_mark_stack ()
>>> #29 0x00005a5a429a569b in process_mark_stack ()
>>> #30 0x00005a5a429a569b in process_mark_stack ()
>>> #31 0x00005a5a429a7b8e in garbage_collect ()
>>> #32 0x00005a5a429e76e7 in Ffuncall ()
>>> #33 0x00005a5a42a094f7 in mapcar1 ()
>>> #34 0x00005a5a42a091bf in Fmapconcat ()
>>> #35 0x00005a5a42ac9d90 in Ftreesit_pattern_expand ()
>>> #36 0x00005a5a429e87b3 in funcall_subr ()
>>> #37 0x00005a5a429e77f6 in Ffuncall ()
>>> #38 0x00005a5a42a094f7 in mapcar1 ()
>>> #39 0x00005a5a42a091bf in Fmapconcat ()
>>> #40 0x00005a5a42ac9d90 in Ftreesit_pattern_expand ()
>>> #41 0x00005a5a429e87b3 in funcall_subr ()
>>> #42 0x00005a5a429e77f6 in Ffuncall ()
>>> #43 0x00005a5a42a094f7 in mapcar1 ()
>>> #44 0x00005a5a42a091bf in Fmapconcat ()
>>> #45 0x00005a5a42aca243 in treesit_ensure_query_compiled ()
>>> #46 0x00005a5a42aca5c0 in Ftreesit_query_capture ()
>>
>> Then it's strange, since it doesn't happen here.  Does it happen for
>> you with any C source file, including those in the Emacs source tree?
>> If this happens only for some files, can you post one such file?
>>
>> Also, what version of the tree-sitter library are you using, and what
>> version of the C grammar library?
>>
>> If you can build the emacs-29 branch, can you try reproducing there?
>>
>> Yuan, any ideas, based on the backtrace?
>
> I was using tree-sitter build from the git repository, when i use it
> from the official arch linux repos, it doesn't crash (at least until
> now).
> I think this is tree-sitter related, but it shouldn't be able to crash
> emacs, should it?

I should not but it could.

I used my distro's tree-sitter and could not reproduced.

  Andrea

bug#70059: 30.0.50; c-ts-mode crashes emacs

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Thu, 28 Mar 2024 21:36:54 +0100
>> From:  Felix via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>> 
>> 
>> I can reproduce it like this:
>> run 'emacs -Q'
>> open a C source file.
>> M-x c-ts-mode
>> wait a few seconds, and emacs crashes.
>
> Doesn't happen here, but see below.
>
>> In GNU Emacs 30.0.50 (build 4, x86_64-pc-linux-gnu, GTK+ Version
>>  3.24.41, cairo version 1.18.0) of 2024-03-28
>> Repository revision: de9e913f9e2a1e01e5d091a553e98d75404a2246
>> Repository branch: makepkg
>                      ^^^^^^^
> What is this branch?  I don't see such a branch in the Emacs Git
> repository; did I miss something?  If this is your local branch, does
> it have any local changes which could affect this issue?
>
>> System Description: Arch Linux
>> 
>> Configured using:
>>  'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
>>  --localstatedir=/var --mandir=/usr/share/man --with-gameuser=:games
>>  --with-modules --without-m17n-flt --without-gconf --enable-autodepend
>>  --enable-link-time-optimization --with-native-compilation=yes
>>  --with-xinput2 --with-pgtk --without-xaw3d --with-cairo-xcb
>>  --with-sound=no --with-xwidgets --with-tree-sitter --without-gpm
>>  --without-compress-install
>>  '--program-transform-name=s/\([ec]tags\)/\1.emacs/'
>>  'CFLAGS=-march=native -mtune=generic -O3 -pipe -fno-plt -fexceptions
>>  -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security
>>  -fstack-clash-protection -fcf-protection'
>>  LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now'
>> 
>> Configured features:
>> ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
>> LCMS2 LIBOTF LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY
>> PDUMPER PGTK PNG RSVG SECCOMP SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS
>> TREE_SITTER WEBP XIM XWIDGETS GTK3 ZLIB
>
> I see your build is with native-compilation; mine is without.  The
> backtrace you posted:
>
>> #11 0x000062534cfba688 in shut_down_emacs ()
>> #12 0x000062534cfba3ba in terminate_due_to_signal ()
>> #13 0x000062534cff5be4 in handle_sigsegv ()
>> #14 0x0000723f608fd770 in <signal handler called> () at /usr/lib/libc.so.6
>> #15 0x000062534d063429 in process_mark_stack ()
>> #16 0x000062534d1649f1 in traverse_intervals_noorder ()
>> #17 0x000062534d063e5e in process_mark_stack ()
>> #18 0x000062534d063ceb in process_mark_stack ()
>> #19 0x000062534d063ceb in process_mark_stack ()
>> #20 0x000062534d064fab in mark_char_table ()
>> #21 0x000062534d0650f6 in mark_char_table ()
>> #22 0x000062534d063c0c in process_mark_stack ()
>> #23 0x000062534d063ceb in process_mark_stack ()
>> #24 0x000062534d063ceb in process_mark_stack ()
>> #25 0x000062534d063ceb in process_mark_stack ()
>> #26 0x000062534d0663be in garbage_collect ()
>> #27 0x000062534d11e30b in exec_byte_code ()
>> #28 0x000062534d0a5406 in Ffuncall ()
>> #29 0x000062534d0a58df in Fapply ()
>> #30 0x000062534d137961 in read_process_output_call ()
>> #31 0x000062534d0ae619 in internal_condition_case_1 ()
>> #32 0x000062534d137820 in exec_sentinel ()
>> #33 0x000062534d135d2f in status_notify ()
>> #34 0x000062534d13b00c in wait_reading_process_output ()
>
> indicates that Emacs crashed after some sub-process exited, the
> process sentinel was called, and that caused us to run some Lips and
> perform GC.  Any idea what that subprocess was? could it be the async
> native-compilation of some Lisp file?  Can you try building without
> native-compilation and see if the problem happens there as well?
>
> Also, do you see c-ts-mode's .eln file in your eln-cache directory?
>
> Andrea, can you try reproducing this?

Hi Eli,

here my datapoint, on current master (87be53846bf) compiled with native
compilation and tree sitter I can't reproduce this opening comp.c.

  Andrea