From unknown Sun Aug 17 22:00:02 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#59574 <59574@debbugs.gnu.org> To: bug#59574 <59574@debbugs.gnu.org> Subject: Status: 29.0.50; Emacs crashes when using tree-sitter-based mode in an empty buffer Reply-To: bug#59574 <59574@debbugs.gnu.org> Date: Mon, 18 Aug 2025 05:00:02 +0000 retitle 59574 29.0.50; Emacs crashes when using tree-sitter-based mode in a= n empty buffer reassign 59574 emacs submitter 59574 Eli Zaretskii severity 59574 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 25 10:04:11 2022 Received: (at submit) by debbugs.gnu.org; 25 Nov 2022 15:04:11 +0000 Received: from localhost ([127.0.0.1]:36913 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oyaFP-0004ae-3Z for submit@debbugs.gnu.org; Fri, 25 Nov 2022 10:04:11 -0500 Received: from lists.gnu.org ([209.51.188.17]:59380) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oyaFL-0004aT-4y for submit@debbugs.gnu.org; Fri, 25 Nov 2022 10:04:09 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oyaFK-0006BT-UH for bug-gnu-emacs@gnu.org; Fri, 25 Nov 2022 10:04:06 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oyaFK-00058m-8P; Fri, 25 Nov 2022 10:04:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=Subject:To:From:Date:mime-version:in-reply-to: references; bh=nAyuji0xetq/xel5USxdUfvfolppxuWdjC0Qdz6gkTY=; b=Ry1HVnQQSn9yvs hI5DSjaNiEYsqVyEImYGqEaI2F4JMcffr0/kV9t0TeAD8hTqTFfK8QIk3UlURvVDmllap+U2Gqa9o D/mq/jCNqZtHqCh0kA2i1QGDgLPIB0d99//wEJu1RcvkqQGmFALTvtjxhMq24G3rgr1HiqmTDIMvt SBk/GcPYO32BGqhs5MjTRNvBdFTh84CqBcEC401GMsjBxDJAqzYz/3ZPyTuCtLB4FmmC4cclA1SD2 AR5eD54iqBw50ZwPj7McgrTNxrhyKSGYINKeA/NClbQkS0/SRB4tMV2a8ixTieTMPbDxgA/YDLstY QuUJPEKO2CVxE0Yu3OJQ==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oyaFJ-0007JX-DX; Fri, 25 Nov 2022 10:04:05 -0500 Date: Fri, 25 Nov 2022 17:04:27 +0200 Message-Id: <837czjulc4.fsf@gnu.org> From: Eli Zaretskii To: bug-gnu-emacs@gnu.org Subject: 29.0.50; Emacs crashes when using tree-sitter-based mode in an empty buffer X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: submit Cc: Yuan Fu X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) To reproduce: emacs -Q C-x C-f foo.c RET M-x c-ts-mode RET Type "in" Make sure foo.c doesn't exist, so you start from an empty buffer. As soon as you type the second character of "in", there's an assertion violation: treesit.c:1383: Emacs fatal error: assertion failed: end_byte <= BUF_ZV_BYTE (bu ffer) Thread 1 hit Breakpoint 1, terminate_due_to_signal (sig=22, backtrace_limit=2147483647) at emacs.c:427 427 signal (sig, SIG_DFL); (gdb) up #1 0x01230802 in die ( msg=0x18e6778 "end_byte <= BUF_ZV_BYTE (buffer)", file=0x18e5fcc "treesit.c", line=1383) at alloc.c:7697 7697 terminate_due_to_signal (SIGABRT, INT_MAX); (gdb) #2 0x01355636 in treesit_make_ranges (ranges=0x856a778, len=1, buffer=0x7fe94b0) at treesit.c:1383 1383 eassert (end_byte <= BUF_ZV_BYTE (buffer)); (gdb) p end_byte $1 = 4 (gdb) p BUF_ZV_BYTE(buffer) $2 = 3 Interestingly, this only happens once, when the buffer includes exactly 1 byte and an additional character is inserted. If you get past this assertion, further characters can be inserted without any problems, and end_byte always equals BUF_ZV_BYTE. The backtrace is below, if it is interesting. I couldn't figure out where did tree-sitter take the range it returns to us. Yuan, can you describe how does the parser get the range it needs to consider? If I put a breakpoint in treesit-parser-set-included-ranges, the breakpoint never breaks, so this doesn't seem to be how the range is set in this scenario. There's also something strange in treesit_record_change: when it is called for the first time in a buffer which was empty and you insert one character, we bypass the updating of visible_beg and visible_end fields of the Lisp parser object, because XTS_PARSER (lisp_parser)->tree is NULL. But it looks to me that we should still update these two fields regardless, no? Only the call to treesit_tree_edit_1 needs the tree. (I thought that maybe this lack of update explains the assertion, but even if I move the condition to guard only treesit_tree_edit_1, the assertion still happens, so I guess my hypothesis eats dust.) Here's the backtrace I promised: (gdb) bt #0 terminate_due_to_signal (sig=22, backtrace_limit=2147483647) at emacs.c:427 #1 0x01230802 in die ( msg=0x18e6778 "end_byte <= BUF_ZV_BYTE (buffer)", file=0x18e5fcc "treesit.c", line=1383) at alloc.c:7697 #2 0x01355636 in treesit_make_ranges (ranges=0x856a778, len=1, buffer=0x7fe94b0) at treesit.c:1383 #3 0x01353c7e in treesit_call_after_change_functions (old_tree=0x84d9fe0, new_tree=0x856a5d0, parser=XIL(0xa00000000853e4e8)) at treesit.c:859 #4 0x01353fff in treesit_ensure_parsed (parser=XIL(0xa00000000853e4e8)) at treesit.c:906 #5 0x01354ff8 in Ftreesit_parser_root_node (parser=XIL(0xa00000000853e4e8)) at treesit.c:1328 #6 0x012773d2 in funcall_subr (subr=0x1883640 , numargs=1, args=0x6c10470) at eval.c:3034 #7 0x012e9b92 in exec_byte_code (fun=XIL(0xa00000000850edc8), args_template=256, nargs=1, args=0x6c10390) at bytecode.c:809 #8 0x0127799a in fetch_and_exec_byte_code (fun=XIL(0xa0000000084b0d20), args_template=257, nargs=1, args=0x6c101c8) at eval.c:3081 #9 0x01277ef9 in funcall_lambda (fun=XIL(0xa0000000084b0d20), nargs=1, arg_vector=0x6c101c8) at eval.c:3153 #10 0x01276e66 in funcall_general (fun=XIL(0xa0000000084b0d20), numargs=1, args=0x6c101c8) at eval.c:2945 #11 0x012771eb in Ffuncall (nargs=2, args=0x6c101c0) at eval.c:2995 #12 0x012762ae in run_hook_wrapped_funcall (nargs=2, args=0x6c101c0) at eval.c:2773 #13 0x01276765 in run_hook_with_args (nargs=2, args=0x6c101c0, funcall=0x1276266 ) at eval.c:2854 #14 0x012762fd in Frun_hook_wrapped (nargs=2, args=0x6c101c0) at eval.c:2788 #15 0x0127784b in funcall_subr (subr=0x187cf00 , numargs=2, args=0x6c101c0) at eval.c:3059 #16 0x012e9b92 in exec_byte_code (fun=XIL(0xa0000000061302c4), args_template=514, nargs=2, args=0x6c100f8) at bytecode.c:809 #17 0x0127799a in fetch_and_exec_byte_code (fun=XIL(0xa00000000612fd94), args_template=257, nargs=1, args=0x82ac88) at eval.c:3081 #18 0x01277ef9 in funcall_lambda (fun=XIL(0xa00000000612fd94), nargs=1, arg_vector=0x82ac88) at eval.c:3153 #19 0x01276e66 in funcall_general (fun=XIL(0xa00000000612fd94), numargs=1, args=0x82ac88) at eval.c:2945 #20 0x012771eb in Ffuncall (nargs=2, args=0x82ac80) at eval.c:2995 #21 0x012712a1 in internal_condition_case_n (bfun=0x127709f , nargs=2, args=0x82ac80, handlers=XIL(0x30), hfun=0x104286e ) at eval.c:1558 #22 0x01042aa1 in safe__call (inhibit_quit=false, nargs=2, func=XIL(0x47648c4), ap=0x82ad44 "") at xdisp.c:3024 #23 0x01042b1a in safe_call (nargs=2, func=XIL(0x47648c4)) at xdisp.c:3039 #24 0x01042b6e in safe_call1 (fn=XIL(0x47648c4), arg=make_fixnum(1)) at xdisp.c:3050 #25 0x010469d4 in handle_fontified_prop (it=0x82afd0) at xdisp.c:4416 #26 0x010453c7 in handle_stop (it=0x82afd0) at xdisp.c:3951 #27 0x01051ebf in reseat (it=0x82afd0, pos=..., force_p=true) at xdisp.c:7469 #28 0x01044495 in init_iterator (it=0x82afd0, w=0x7958be0, charpos=1, bytepos=1, row=0x7a214a0, base_face_id=DEFAULT_FACE_ID) at xdisp.c:3488 #29 0x010446c3 in start_display (it=0x82afd0, w=0x7958be0, pos=...) at xdisp.c:3568 #30 0x0107c99e in try_window (window=XIL(0xa000000007958be0), pos=..., flags=1) at xdisp.c:20511 #31 0x01079579 in redisplay_window (window=XIL(0xa000000007958be0), just_this_one_p=true) at xdisp.c:19903 #32 0x010706c6 in redisplay_window_1 (window=XIL(0xa000000007958be0)) at xdisp.c:17405 #33 0x0127108e in internal_condition_case_1 ( bfun=0x107066e , arg=XIL(0xa000000007958be0), handlers=XIL(0xc000000006462abc), hfun=0x10702c6 ) at eval.c:1498 #34 0x0106f10a in redisplay_internal () at xdisp.c:16944 #35 0x0106c163 in redisplay () at xdisp.c:16006 #36 0x01174cf8 in read_char (commandflag=1, map=XIL(0xc000000008096220), prev_event=XIL(0), used_mouse_menu=0x82f41f, end_time=0x0) at keyboard.c:2623 #37 0x0118ec5e in read_key_sequence (keybuf=0x82f6f8, prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:10070 #38 0x0117033d in command_loop_1 () at keyboard.c:1376 #39 0x01270fa4 in internal_condition_case (bfun=0x116fcdc , handlers=XIL(0x90), hfun=0x116ecaa ) at eval.c:1474 #40 0x0116f749 in command_loop_2 (handlers=XIL(0x90)) at keyboard.c:1125 #41 0x0126fe2b in internal_catch (tag=XIL(0x10290), func=0x116f712 , arg=XIL(0x90)) at eval.c:1197 #42 0x0116f6b4 in command_loop () at keyboard.c:1103 #43 0x0116e70a in recursive_edit_1 () at keyboard.c:712 #44 0x0116e9a8 in Frecursive_edit () at keyboard.c:795 #45 0x0116975d in main (argc=2, argv=0xa428e0) at emacs.c:2523 Lisp Backtrace: "treesit-parser-root-node" (0x6c10470) "treesit-buffer-root-node" (0x6c10388) "treesit-font-lock-fontify-region" (0x6c10300) "font-lock-default-fontify-region" (0x6c10298) "font-lock-fontify-region" (0x6c10230) 0x84b0d20 PVEC_COMPILED "run-hook-wrapped" (0x6c101c0) "jit-lock--run-functions" (0x6c100e8) "jit-lock-fontify-now" (0x6c10058) "jit-lock-function" (0x82ac88) "redisplay_internal (C function)" (0x0) (gdb) In GNU Emacs 29.0.50 (build 2261, i686-pc-mingw32) of 2022-11-25 built on HOME-C4E4A596F7 Repository revision: af545234314601ba3dcd8bf32e0d9b46e1917f79 Repository branch: master Windowing system distributor 'Microsoft Corp.', version 5.1.2600 System Description: Microsoft Windows XP Service Pack 3 (v5.1.0.2600) Configured using: 'configure -C --prefix=/d/usr --with-wide-int --enable-checking=yes,glyphs 'CFLAGS=-O0 -gdwarf-4 -g3'' Configured features: ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XPM ZLIB Important settings: value of $LANG: ENU locale-coding-system: cp1255 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 dos-w32 ls-lisp disp-table term/w32-win w32-win w32-vars 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 w32notify w32 lcms2 multi-tty make-network-process emacs) Memory information: ((conses 16 42624 11101) (symbols 48 6278 0) (strings 16 16553 2914) (string-bytes 1 398654) (vectors 16 9312) (vector-slots 8 146415 13640) (floats 8 23 27) (intervals 40 274 97) (buffers 896 10)) From debbugs-submit-bounces@debbugs.gnu.org Fri Nov 25 22:18:21 2022 Received: (at 59574) by debbugs.gnu.org; 26 Nov 2022 03:18:21 +0000 Received: from localhost ([127.0.0.1]:37591 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oylhs-0008Qi-Oc for submit@debbugs.gnu.org; Fri, 25 Nov 2022 22:18:21 -0500 Received: from mail-pl1-f172.google.com ([209.85.214.172]:40896) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oylho-0008QK-EM for 59574@debbugs.gnu.org; Fri, 25 Nov 2022 22:18:19 -0500 Received: by mail-pl1-f172.google.com with SMTP id d6so5456765pll.7 for <59574@debbugs.gnu.org>; Fri, 25 Nov 2022 19:18:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=lrmHcYzQxlYylA2IEvsJgcZc4S7L/qTp1F9tsSnXPRw=; b=UtUiwljeWf6Sj6irZ9FtTR8pJYNq2Ph5lNUOyJ/R6qZpizmJWKmCddW+Asfkohrh6n ievHQoYHWi//gI+f56cWR9jFbsTEYXy9QQ4w/43Dx0uBijAoufkXa4eKIV4bA/QIkTU3 y0lEWSl7ql4LTChjADbCwodA9VmWLBI7ZFVS3gIdSs85CJZ/z9egBUeMX7NrnSSUjFgq 7etzkc1EUvejP/lRvl/Sc4KH1JKNWs7V49VOJ4YWyD8XirPiRtnB6yjUvTHuzbaFIoOt jS/+VTOfXIPicWxpFx2FWYTIzgYVhhb1Mn00TK53p1PAwwTPeDQFSO2MY080xOKsWmra jQcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=lrmHcYzQxlYylA2IEvsJgcZc4S7L/qTp1F9tsSnXPRw=; b=l6SJDJsWPo8mOpT6JL1EjCheNWPmw9Lxe7W6MsKyfCWavtoteOUQXeJKchuPSAQbgv vXIPkFjaHLKETKJoCNnUOj+nyMrc571VyXMC65mZZn4gbg5sgPiPZHbFjCNtO2wGlu9c 0vDu0XA2DCS0eDx92nVPNloKpgJvmJZ8u/IcJGj0uXMPaGR6NAuehRDB9Qa2UZdrXjlf e/fVK21i71IGzWr/peJbTgEpgZ79eaz8d+CybuYDLURP8C9WvpLAEiLHlcAO22NLqqeH SnieKvrDxiwUnoKWAIjxRlJaeTaryLW08AoqlH95yU40EzF8jgSktUjvdGJr/XoeqwV/ HYzg== X-Gm-Message-State: ANoB5pmKrvB/CmBWZM2zocMVaX/LfVhCcTKSYzBOCZ45hI1X029wmhhg IpcFSXq4+jCFedfmftuOhVE= X-Google-Smtp-Source: AA0mqf7jF2h3+NdmVLZ9Gq8wX86ECO679IflMXvrGoaZ08uDhxMQDJOZ7SnzAYfIEz+hxVDtqiRjQQ== X-Received: by 2002:a17:902:a616:b0:189:46b1:fe0b with SMTP id u22-20020a170902a61600b0018946b1fe0bmr15076447plq.117.1669432690427; Fri, 25 Nov 2022 19:18:10 -0800 (PST) Received: from smtpclient.apple (cpe-172-117-161-177.socal.res.rr.com. [172.117.161.177]) by smtp.gmail.com with ESMTPSA id 77-20020a621850000000b005722f4dfbefsm3744297pfy.193.2022.11.25.19.18.09 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 25 Nov 2022 19:18:10 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: bug#59574: 29.0.50; Emacs crashes when using tree-sitter-based mode in an empty buffer From: Yuan Fu In-Reply-To: <837czjulc4.fsf@gnu.org> Date: Fri, 25 Nov 2022 19:18:09 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6350D0DE-63CD-410A-AA48-56D924ED67EA@gmail.com> References: <837czjulc4.fsf@gnu.org> To: Eli Zaretskii X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 59574 Cc: 59574@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > On Nov 25, 2022, at 7:04 AM, Eli Zaretskii wrote: >=20 > To reproduce: >=20 > emacs -Q > C-x C-f foo.c RET > M-x c-ts-mode RET > Type "in" Thanks for finding this out!=20 >=20 > Make sure foo.c doesn't exist, so you start from an empty buffer. As = soon > as you type the second character of "in", there's an assertion = violation: >=20 > treesit.c:1383: Emacs fatal error: assertion failed: end_byte <=3D = BUF_ZV_BYTE (bu > ffer) >=20 > Thread 1 hit Breakpoint 1, terminate_due_to_signal (sig=3D22, = backtrace_limit=3D2147483647) at emacs.c:427 > 427 signal (sig, SIG_DFL); > (gdb) up > #1 0x01230802 in die ( > msg=3D0x18e6778 "end_byte <=3D = BUF_ZV_BYTE (buffer)", file=3D0x18e5fcc = "treesit.c", line=3D1383) > at alloc.c:7697 > 7697 terminate_due_to_signal (SIGABRT, INT_MAX); > (gdb) > #2 0x01355636 in treesit_make_ranges (ranges=3D0x856a778, len=3D1, > buffer=3D0x7fe94b0) at treesit.c:1383 > 1383 eassert (end_byte <=3D BUF_ZV_BYTE (buffer)); > (gdb) p end_byte > $1 =3D 4 > (gdb) p BUF_ZV_BYTE(buffer) > $2 =3D 3 >=20 > Interestingly, this only happens once, when the buffer includes = exactly 1 > byte and an additional character is inserted. If you get past this > assertion, further characters can be inserted without any problems, = and > end_byte always equals BUF_ZV_BYTE. >=20 > The backtrace is below, if it is interesting. >=20 > I couldn't figure out where did tree-sitter take the range it returns = to us. > Yuan, can you describe how does the parser get the range it needs to > consider? If I put a breakpoint in = treesit-parser-set-included-ranges, the > breakpoint never breaks, so this doesn't seem to be how the range is = set in > this scenario. After we parse the buffer (in treesit_ensure_parsed) we compute the = ranges that has changed since last parse, by calling = ts_tree_get_changed_ranges, and pass the ranges to notifier functions = (those added by treesit-parser-add-notifier). This range is different = from the range within which a parser operates. That range is set by = treesit-parser-set-included-ranges, and is not involved with the = parsing, treesit_record_changes, visible_beg/end stuff. Both feature happens to use treesit_make_ranges as a helper function, = but the similarity ends there. > There's also something strange in treesit_record_change: when it is = called > for the first time in a buffer which was empty and you insert one = character, > we bypass the updating of visible_beg and visible_end fields of the = Lisp > parser object, because XTS_PARSER (lisp_parser)->tree is NULL. But it = looks > to me that we should still update these two fields regardless, no? = Only the > call to treesit_tree_edit_1 needs the tree. (I thought that maybe = this lack > of update explains the assertion, but even if I move the condition to = guard > only treesit_tree_edit_1, the assertion still happens, so I guess my > hypothesis eats dust.) We don=E2=80=99t need to update visible_beg/end in treesit_record_change = if tree is NULL, because visible_beg/end represents the range of buffer = that the tree sees, so if there is no tree, visible_beg/end can be = considered uninitialized. However you are right about needing to update = visible_beg/end, but in treesit_ensure_position_synced (I renamed it to = treesit_sync_visible_region): that=E2=80=99s where we ensure = visible_beg/end equals to BUF_BEGV_BYTE/friends.=20 The problem is we don=E2=80=99t update visible_beg/end for the very = first parse, when tree is NULL. I also added some comments, hopefully they sufficiently explain = everything. Yuan From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 26 09:31:42 2022 Received: (at 59574-done) by debbugs.gnu.org; 26 Nov 2022 14:31:42 +0000 Received: from localhost ([127.0.0.1]:38326 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oywDV-0005JN-PS for submit@debbugs.gnu.org; Sat, 26 Nov 2022 09:31:42 -0500 Received: from eggs.gnu.org ([209.51.188.92]:49922) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oywDU-0005JA-Az for 59574-done@debbugs.gnu.org; Sat, 26 Nov 2022 09:31:40 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oywDO-0003gG-KV; Sat, 26 Nov 2022 09:31:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=1+KuwH6EBF4cflVptiDxNCb7IlGjQqaqSYuQixPBdDQ=; b=dfY61H6iIqYbhrg71SSU of+qtPuBJaGiu4VgbhoeiaSbhvkjk1YlrBbu1pM6OHrxJ7hnfLAF6fhOCxfd5TzwkW03y2iOQMSif fQaXs0Hs9ebyKaUsAU0hXYO+tndzTkuYS+QHRx/YRavfEg5G4mSBbkRNeG1IhdRGyV7mxhjec7a4B iuayll0g9axWozrpMZygxBWRCvBOP6iFW2COtwpN9oxca/k73oq3gcjamTiMLaVnycikmrW/13wHH C+91MVLtNh5gcfZfblwRG73IiAuDbACMhbwmJTWM6jq6wQ9JNb1jVboSHWHjyYvLq9hKRGKxD/H8K puY+T7JWikT+kQ==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oywDN-0006f5-0s; Sat, 26 Nov 2022 09:31:33 -0500 Date: Sat, 26 Nov 2022 16:31:59 +0200 Message-Id: <83k03hss68.fsf@gnu.org> From: Eli Zaretskii To: Yuan Fu In-Reply-To: <6350D0DE-63CD-410A-AA48-56D924ED67EA@gmail.com> (message from Yuan Fu on Fri, 25 Nov 2022 19:18:09 -0800) Subject: Re: bug#59574: 29.0.50; Emacs crashes when using tree-sitter-based mode in an empty buffer References: <837czjulc4.fsf@gnu.org> <6350D0DE-63CD-410A-AA48-56D924ED67EA@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 59574-done Cc: 59574-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Yuan Fu > Date: Fri, 25 Nov 2022 19:18:09 -0800 > Cc: 59574@debbugs.gnu.org > > > There's also something strange in treesit_record_change: when it is called > > for the first time in a buffer which was empty and you insert one character, > > we bypass the updating of visible_beg and visible_end fields of the Lisp > > parser object, because XTS_PARSER (lisp_parser)->tree is NULL. But it looks > > to me that we should still update these two fields regardless, no? Only the > > call to treesit_tree_edit_1 needs the tree. (I thought that maybe this lack > > of update explains the assertion, but even if I move the condition to guard > > only treesit_tree_edit_1, the assertion still happens, so I guess my > > hypothesis eats dust.) > > We don’t need to update visible_beg/end in treesit_record_change if tree is NULL, because visible_beg/end represents the range of buffer that the tree sees, so if there is no tree, visible_beg/end can be considered uninitialized. However you are right about needing to update visible_beg/end, but in treesit_ensure_position_synced (I renamed it to treesit_sync_visible_region): that’s where we ensure visible_beg/end equals to BUF_BEGV_BYTE/friends. > > The problem is we don’t update visible_beg/end for the very first parse, when tree is NULL. > > I also added some comments, hopefully they sufficiently explain everything. Thanks, the problem is gone, so I'm closing the bug. From unknown Sun Aug 17 22:00:02 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 25 Dec 2022 12:24:09 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator