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

[Eli Zaretskii]

> 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?

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