--- Begin Message ---
|
Subject: |
30.0.50; tree-sitter crash |
|
Date: |
Fri, 17 May 2024 15:39:27 +0200 |
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
Description: application/emacs-lisp
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@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@entry=XIL(0x55555605b225), noescape=XIL(0x30),
overrides=overrides@entry=XIL(0)) at print.c:814
#5 0x00005555557b7c30 in styled_format
(nargs=2, args=args@entry=0x7fffffffda30, message=message@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
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#71012: 30.0.50; tree-sitter crash |
|
Date: |
Wed, 5 Jun 2024 22:31:04 -0700 |
> On Jun 1, 2024, at 10:43 AM, Yuan Fu <casouri@gmail.com> wrote:
>
>
>
>> On Jun 1, 2024, at 10:15 AM, Yuan Fu <casouri@gmail.com> wrote:
>>
>>
>>
>>> On May 29, 2024, at 5:28 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>>>
>>>> From: Yuan Fu <casouri@gmail.com>
>>>> Date: Tue, 28 May 2024 22:15:05 -0700
>>>> Cc: Helmut Eller <eller.helmut@gmail.com>,
>>>> 71012@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
--- End Message ---