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

[Yuan Fu <casouri@gmail.com>]

> On Dec 23, 2023, at 11:11 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Yuan Fu <casouri@gmail.com>
>> Date: Sat, 23 Dec 2023 19:00:34 -0800
>> Cc: Denis Zubarev <dvzubarev@yandex.ru>,
>> 67977@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