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

From: Eli Zaretskii <[email-masked]>
Date: Sun, 24 Dec 2023 09:11:57 +0200

> From: Yuan Fu <[email-masked]>
> Date: Sat, 23 Dec 2023 19:00:34 -0800
> Cc: Denis Zubarev <[email-masked]>,
>  [email-masked]
> 
> >> 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?