GNU bug report logs -
#71012
30.0.50; tree-sitter crash
Previous Next
Reported by: Helmut Eller <eller.helmut <at> gmail.com>
Date: Fri, 17 May 2024 13:40:01 UTC
Severity: normal
Found in version 30.0.50
Done: Yuan Fu <casouri <at> gmail.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your bug report
#71012: 30.0.50; tree-sitter crash
which was filed against the emacs package, has been closed.
The explanation is attached below, along with your original report.
If you require more details, please reply to 71012 <at> debbugs.gnu.org.
--
71012: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=71012
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
> On Jun 1, 2024, at 10:43 AM, Yuan Fu <casouri <at> gmail.com> wrote:
>
>
>
>> On Jun 1, 2024, at 10:15 AM, Yuan Fu <casouri <at> gmail.com> wrote:
>>
>>
>>
>>> On May 29, 2024, at 5:28 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>>>
>>>> From: Yuan Fu <casouri <at> gmail.com>
>>>> Date: Tue, 28 May 2024 22:15:05 -0700
>>>> Cc: Helmut Eller <eller.helmut <at> gmail.com>,
>>>> 71012 <at> debbugs.gnu.org
>>>>
>>>> From what I can gather, the crash seems to be because the temp buffer is garbage collected—the inserted lisp.h is a large file, so the temp buffer is probably immediately collected, before Emacs tries to print the node in the next line. I replaced the insert-file-content with some smaller file and it didn’t crash.
>>>
>>> It is unthinkable that a buffer is GC'ed while it is being used.
>>>
>>>> But that theory has critical flaws: a) Emacs certainly doesn't collect the temp buffer before the with-temp-buffer form returns; b) I can’t crash Emacs in my non-debug build by inserting (garbage-collect) in front of the message line in the example; c) debug build Emacs still crashes even if I enlarge gc-cons-threshold.
>>>>
>>>> Eli, is there anything different regarding temp buffers in debug builds?
>>>
>>> No.
>>>
>>> But note that there are _two_ temporary buffers involved here: one is
>>> created in ts-bug.el, and it remains intact and valid; the other is
>>> the temporary buffer created by treesit-parse-string. That one is
>>> killed by the time treesit-parse-string returns, so treesit-node-start
>>> attempts to access positions of a killed buffer!
>>>
>>> So I think this is a bug in treesit-parse-string: it cannot use
>>> with-temp-buffer; instead, it should make the buffer into which it
>>> inserts the string part of the parser, so that the buffer is killed
>>> and GC'ed only when the parser is no longer referenced. Otherwise the
>>> syntax tree returned by treesit-parse-string is unsafe to use.
>>
>> I see, you’re absolutely right, thanks for the analysis! On top of that I need to make sure all the treesit function checks for buffer liveness before accessing the buffer. I was under the impression that a killed buffer would keep its content around until it’s collected. Turns out that wasn’t the case.
>>
>> Yuan
>
> Pushed the fix to emacs-29.
>
> Yuan
>
The fix works for me so I’m closing this report. Feel free to followup if new problems occur :-)
Yuan
[Message part 3 (message/rfc822, inline)]
[Message part 4 (text/plain, inline)]
The code in the attached file tries to parse src/lisp.h but crashes
while printing the result: emacs --batch -l ts-bug.el
[ts-bug.el (application/emacs-lisp, attachment)]
[Message part 6 (text/plain, inline)]
Program received signal SIGSEGV, Segmentation fault.
0x000055555575c33a in buf_bytepos_to_charpos (b=0x555556074c60, bytepos=1)
at marker.c:343
343 eassert (bytepos >= BUF_Z_BYTE (b)
(gdb) ba 10
#0 0x000055555575c33a in buf_bytepos_to_charpos (b=0x555556074c60, bytepos=1)
at marker.c:343
#1 0x0000555555853509 in Ftreesit_node_start
(node=node <at> entry=XIL(0x55555605b225)) at treesit.c:1927
#2 0x00005555557f3f8a in print_vectorlike_unreadable
(obj=XIL(0x55555605b225), printcharfun=XIL(0), escapeflag=<optimized out>, buf=0x7fffffff7ef0 "dd\aVUU") at print.c:2051
#3 0x00005555557f1b85 in print_object
(obj=<optimized out>, printcharfun=<optimized out>, escapeflag=false)
at print.c:2642
#4 0x00005555557f2cf0 in Fprin1_to_string
(object=object <at> entry=XIL(0x55555605b225), noescape=XIL(0x30), overrides=overrides <at> entry=XIL(0)) at print.c:814
#5 0x00005555557b7c30 in styled_format
(nargs=2, args=args <at> entry=0x7fffffffda30, message=message <at> entry=true)
at editfns.c:3635
#6 0x00005555557b933f in Fformat_message
(args=0x7fffffffda30, nargs=<optimized out>) at editfns.c:3388
#7 Fmessage (args=0x7fffffffda30, nargs=<optimized out>) at editfns.c:3185
#8 Fmessage (nargs=<optimized out>, args=0x7fffffffda30) at editfns.c:3154
#9 0x00005555557c6b75 in eval_sub (form=<optimized out>)
at /scratch/emacs/emacs-git/src/lisp.h:2243
(More stack frames follow...)
In GNU Emacs 30.0.50 (build 6, x86_64-pc-linux-gnu, GTK+ Version
3.24.38, cairo version 1.16.0) of 2024-05-17 built on caladan
Repository revision: 6ca3a60db3427bc6aef08144c1524920ff3d9c4d
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101007
System Description: Debian GNU/Linux 12 (bookworm)
Configured using:
'configure --enable-checking --without-native-compiler
--with-xpm=ifavailable --with-gif=ifavailable
--with-native-compilation=no --with-tree-sitter'
Configured features:
CAIRO DBUS FREETYPE GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG LIBSELINUX
LIBSYSTEMD LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG SECCOMP SOUND
SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM
XINPUT2 GTK3 ZLIB
This bug report was last modified 324 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.