GNU bug report logs - #72863
30.0.50; tree-sitter elixir-ts-mode hangs and memory leak on some elixir and heex code

Previous Next

Full log

View this message in rfc822 format

From: Yuan Fu <casouri <at> gmail.com>
To: mail <at> ssbb.me
Cc: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>, 72863 <at> debbugs.gnu.org
Subject: bug#72863: 30.0.50; tree-sitter elixir-ts-mode hangs and memory leak on some elixir and heex code
Date: Sat, 7 Sep 2024 22:44:53 -0700

> On Sep 4, 2024, at 9:32 PM, Yuan Fu <casouri <at> gmail.com> wrote:
> 
> 
> 
>> On Sep 4, 2024, at 12:42 AM, mail <at> ssbb.me wrote:
>> 
>> I can confirm that I never had such problems in heex-ts-mode but only with inline heex in elixir-ts-mode.
>> 
>>> On Sep 4, 2024, at 10:39 AM, Wilhelm Kirschbaum <wkirschbaum <at> gmail.com> wrote:
>>> 
>>> 
>>> 
>>> On Thu, Aug 29, 2024 at 8:14 AM Yuan Fu <casouri <at> gmail.com> wrote:
>>> 
>>> 
>>>> On Aug 28, 2024, at 10:09 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>>>> 
>>>>> From: mail <at> ssbb.me
>>>>> Date: Thu, 29 Aug 2024 06:57:38 +0400
>>>>> 
>>>>> Code in attached file cause Emacs to hang and memory leak infinitely
>>>>> while editing. Try to open this code in elixir-ts-mode and move cursor
>>>>> on line 6 (between <:loading>  </:loading>) and type char by char:
>>>>> 
>>>>> <.some_component a={
>>>>> 
>>>>> (for some reason it does not happen with electric-pair-mode when {}
>>>>> inserted automatically).
>>>>> 
>>>>> I am able to reproduce this with -Q on few different machines (Linux and
>>>>> MacOS) and Emacs 29, 30.0.5 and current HEAD.
>>>>> 
>>>>> C-g does nothing (including with debug-on-quit and sending SIGUSR2)
>>>>> 
>>>>> At the same time I can't reproduce this in other tree-sitter based editors.
>>>>> 
>>>>> I got this sample code sample from elixir-ts-mode repo but now it's moved
>>>>> to the Emacs core so seems to be out of scope of Github repo issues.
>>>>> 
>>>>> Attaching samle code and LLDB backtrace. 
>>>>> Also attaching report from built-in MacOS crash reporting tool just in case.
>>>> 
>>>> Thanks.
>>>> 
>>>> Wilhelm and Yuan, could you please look into this soon?
>>> 
>>> That’s bizarre, might have some bug around ranges. I’m looking into this. Hopefully I can figure it out in a few days :-(
>>> 
>>> Yuan
>>> 
>>> I can reproduce the issue by following the above instructions, but need to do some digging. It only seems to be the case with embedded heex and not with heex-ts-mode by itself. 
>>> 
>>> WIlhelm
>>> 
> 
> At the moment I’m still not able to pinpoint the culprit, but here’s what I found: I can reproduce the issue by simply creating a heex parser, set the ranges to [108,240], [300,572], [820,1346] (these are byte position, aka one less than character position), then make it parse the buffer (with the "<.some_component a={" part already typed in. I instrumented the buffer reader and the program hangs after reading the character at byte position 908 (end of "phx-click={“). Also the hang appears in ts_parser_parse.
> 
> I wrote a C program that does exactly that, but the program runs fine without hanging. I haven’t found what Emacs does differently that causes the hang to happen.
> 
> Also I found some other range bug, but fixing those didn’t help this issue.

Still don’t have much progress. The buffer’s gap is at the beginning, and there’s no narrowing, which means the parser is really just reading a continues chunk of memory, there’s no reason why it should behave differently. At this point I might have to read tree-sitter’s source :-(

Meanwhile, I want to push the fix for the other bug I discovered to emacs-30. Eli, I wrote a debugging function that prints parser states, naturally this function isn’t called anywhere so there’ll be a compiler warning, what should I do in this case?

Yuan

Previous Next

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