GNU bug report logs - #67977
30.0.50; tree-sitter: Emacs crashes when accessing treesit-nodes in a narrowed buffer

Previous Next

Full log

View this message in rfc822 format

From: Yuan Fu <casouri <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Denis Zubarev <dvzubarev <at> yandex.ru>, 67977 <at> debbugs.gnu.org
Subject: bug#67977: 30.0.50; tree-sitter: Emacs crashes when accessing treesit-nodes in a narrowed buffer
Date: Tue, 26 Dec 2023 20:15:24 -0800

> On Dec 23, 2023, at 11:11 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
>> From: Yuan Fu <casouri <at> gmail.com>
>> Date: Sat, 23 Dec 2023 19:00:34 -0800
>> Cc: Denis Zubarev <dvzubarev <at> yandex.ru>,
>> 67977 <at> debbugs.gnu.org
>> 
>>>> Yuan, this also happens on the emacs-29 branch, so we should try
>>>> fixing this crash ASAP.
>>> 
>>> Yeah. The node wants to print it’s type name (with ts_node_type), which access it’s parse tree, but the tree is already freed, that means the node is outdated and shouldn’t try to print it’s type name, but should rather print “outdated”.
>>> 
>>> But simply narrowing the buffer shouldn’t reparse the buffer and cause the parse tree to be freed. Anyway, let me see what’s going on.
>> 
>> 
>> I pushed a fix and now it shouldn’t crash anymore. However, I’m yet not sure why at some point the buffer was widened. Is there any way to track who called widen?
> 
> Run Emacs under GDB with a breakpoint at Fwiden, then look at the
> backtrace.  The command "xbacktrace", defined on src/.gdbinit, will
> show a Lisp backtrace as well.
> 
> But I already did the above, and the answer is the expected one: it's
> JIT font-lock, which calls font-lock-fontify-region, which does:
> 
>    (save-restriction
>      (unless font-lock-dont-widen (widen))
> 
> And if you leave blink-cursor-mode and global-eldoc-mode on (which is
> the default), you have also another caller: jit-lock-context-fontify
> (which is called from a timer).
> 
> Does this answer your question?

Yes, they do. Many thanks!

> Btw, I hope that these calls to 'widen' don't require unnecessary
> reparsing by tree-sitter, do they?

Yes, but only because we called treesit-node-at while the buffer is narrowed, which triggers a reparse. Font-lock and jit-lock themselves always access the parser with widened buffer so they don’t trigger reparse on their own. 

So it seems working in a narrowed buffer would trigger a lot of back-and-fortch reparse. I wonder if it’s worth optimizing for (eg, use two parsers behind the scenes, one for widened buffer and one for narrowed buffer).

Yuan

Previous Next

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