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

Package: emacs;

Reported by: mail <at> ssbb.me

Date: Thu, 29 Aug 2024 03:30:02 UTC

Severity: normal

Found in version 30.0.50

To reply to this bug, email your comments to 72863 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#72863; Package emacs. (Thu, 29 Aug 2024 03:30:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to mail <at> ssbb.me:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Thu, 29 Aug 2024 03:30:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: mail <at> ssbb.me
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.50; tree-sitter elixir-ts-mode hangs and memory leak on some
 elixir and heex code
Date: Thu, 29 Aug 2024 06:57:38 +0400
[Message part 1 (text/plain, inline)]
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.

[code.ex (application/octet-stream, attachment)]
[backtrace (application/octet-stream, attachment)]
[report (application/octet-stream, attachment)]
[Message part 5 (text/plain, inline)]

In GNU Emacs 30.0.50 (build 1, aarch64-apple-darwin23.2.0, NS
 appkit-2487.30 Version 14.2.1 (Build 23C71)) of 2024-06-23 built on
 Sviatoslavs-MacBook-Pro.local
Windowing system distributor 'Apple', version 10.3.2487
System Description:  macOS 14.2.1

Configured using:
 'configure --disable-dependency-tracking --disable-silent-rules
 --enable-locallisppath=/opt/homebrew/share/emacs/site-lisp
 --infodir=/opt/homebrew/Cellar/emacs-plus <at> 30/30.0.50/share/info/emacs
 --prefix=/opt/homebrew/Cellar/emacs-plus <at> 30/30.0.50 --with-xml2
 --with-gnutls --with-native-compilation --without-compress-install
 --without-dbus --without-imagemagick --with-modules --with-rsvg
 --with-webp --with-ns --disable-ns-self-contained 'CFLAGS=-Os -w -pipe
 -mmacosx-version-min=14
 -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk
 -DFD_SETSIZE=10000 -DDARWIN_UNLIMITED_SELECT
 -I/opt/homebrew/opt/gcc/include -I/opt/homebrew/opt/libgccjit/include'
 'CPPFLAGS=-I/opt/homebrew/opt/zlib/include
 -I/opt/homebrew/opt/jpeg/include -I/opt/homebrew/opt/icu4c/include
 -I/opt/homebrew/opt/sqlite/include -I/opt/homebrew/opt/readline/include
 -isystem/opt/homebrew/include -F/opt/homebrew/Frameworks
 -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk'
 'LDFLAGS=-L/opt/homebrew/opt/zlib/lib -L/opt/homebrew/opt/jpeg/lib
 -L/opt/homebrew/opt/icu4c/lib -L/opt/homebrew/opt/sqlite/lib
 -L/opt/homebrew/opt/readline/lib -L/opt/homebrew/lib
 -F/opt/homebrew/Frameworks -Wl,-headerpad_max_install_names
 -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk
 -L/opt/homebrew/lib/gcc/14 -I/opt/homebrew/opt/gcc/include
 -I/opt/homebrew/opt/libgccjit/include''




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#72863; Package emacs. (Thu, 29 Aug 2024 05:11:01 GMT) Full text and rfc822 format available.

Message #8 received at 72863 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: mail <at> ssbb.me, Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>,
 Yuan Fu <casouri <at> gmail.com>
Cc: 72863 <at> debbugs.gnu.org
Subject: Re: bug#72863: 30.0.50;
 tree-sitter elixir-ts-mode hangs and memory leak on some elixir and
 heex code
Date: Thu, 29 Aug 2024 08:09:25 +0300
> 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?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#72863; Package emacs. (Thu, 29 Aug 2024 06:16:02 GMT) Full text and rfc822 format available.

Message #11 received at 72863 <at> debbugs.gnu.org (full text, mbox):

From: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Yuan Fu <casouri <at> gmail.com>, 72863 <at> debbugs.gnu.org, mail <at> ssbb.me
Subject: Re: bug#72863: 30.0.50; tree-sitter elixir-ts-mode hangs and memory
 leak on some elixir and heex code
Date: Thu, 29 Aug 2024 08:13:11 +0200
[Message part 1 (text/plain, inline)]
>
>  > 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?
>

Thanks, I will have a look later today.

Wilhelm
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#72863; Package emacs. (Thu, 29 Aug 2024 06:17:01 GMT) Full text and rfc822 format available.

Message #14 received at 72863 <at> debbugs.gnu.org (full text, mbox):

From: Yuan Fu <casouri <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>, 72863 <at> debbugs.gnu.org,
 mail <at> ssbb.me
Subject: Re: bug#72863: 30.0.50; tree-sitter elixir-ts-mode hangs and memory
 leak on some elixir and heex code
Date: Wed, 28 Aug 2024 23:14:26 -0700

> 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



Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#72863; Package emacs. (Wed, 04 Sep 2024 06:43:02 GMT) Full text and rfc822 format available.

Message #17 received at 72863 <at> debbugs.gnu.org (full text, mbox):

From: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>
To: Yuan Fu <casouri <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 72863 <at> debbugs.gnu.org, mail <at> ssbb.me
Subject: Re: bug#72863: 30.0.50; tree-sitter elixir-ts-mode hangs and memory
 leak on some elixir and heex code
Date: Wed, 4 Sep 2024 08:39:45 +0200
[Message part 1 (text/plain, inline)]
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
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#72863; Package emacs. (Wed, 04 Sep 2024 07:44:01 GMT) Full text and rfc822 format available.

Message #20 received at 72863 <at> debbugs.gnu.org (full text, mbox):

From: mail <at> ssbb.me
To: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>
Cc: Yuan Fu <casouri <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>,
 72863 <at> debbugs.gnu.org
Subject: Re: bug#72863: 30.0.50; tree-sitter elixir-ts-mode hangs and memory
 leak on some elixir and heex code
Date: Wed, 4 Sep 2024 11:42:01 +0400
[Message part 1 (text/plain, inline)]
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 <mailto:casouri <at> gmail.com>> wrote:
>> 
>> 
>> > On Aug 28, 2024, at 10:09 PM, Eli Zaretskii <eliz <at> gnu.org <mailto:eliz <at> gnu.org>> wrote:
>> > 
>> >> From: mail <at> ssbb.me <mailto: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
> 
> 
> 

[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#72863; Package emacs. (Thu, 05 Sep 2024 04:35:01 GMT) Full text and rfc822 format available.

Message #23 received at 72863 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#72863: 30.0.50; tree-sitter elixir-ts-mode hangs and memory
 leak on some elixir and heex code
Date: Wed, 4 Sep 2024 21:32:16 -0700

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

Yuan



Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#72863; Package emacs. (Sun, 08 Sep 2024 05:47:01 GMT) Full text and rfc822 format available.

Message #26 received at 72863 <at> debbugs.gnu.org (full text, mbox):

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: Re: 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



Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#72863; Package emacs. (Sun, 08 Sep 2024 05:57:02 GMT) Full text and rfc822 format available.

Message #29 received at 72863 <at> debbugs.gnu.org (full text, mbox):

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

Why would there be a compiler warning?  What kind of warning?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#72863; Package emacs. (Sun, 08 Sep 2024 05:59:02 GMT) Full text and rfc822 format available.

Message #32 received at 72863 <at> debbugs.gnu.org (full text, mbox):

From: Yuan Fu <casouri <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: wkirschbaum <at> gmail.com, 72863 <at> debbugs.gnu.org, mail <at> ssbb.me
Subject: Re: 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:57:29 -0700

> On Sep 7, 2024, at 10:54 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
>> From: Yuan Fu <casouri <at> gmail.com>
>> Date: Sat, 7 Sep 2024 22:44:53 -0700
>> Cc: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>,
>> Eli Zaretskii <eliz <at> gnu.org>,
>> 72863 <at> debbugs.gnu.org
>> 
>> 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?
> 
> Why would there be a compiler warning?  What kind of warning?

A function-not-used warning. Maybe it’s an lldb thing?

Yuan



Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#72863; Package emacs. (Sun, 08 Sep 2024 07:04:02 GMT) Full text and rfc822 format available.

Message #35 received at 72863 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Yuan Fu <casouri <at> gmail.com>
Cc: wkirschbaum <at> gmail.com, 72863 <at> debbugs.gnu.org, mail <at> ssbb.me
Subject: Re: bug#72863: 30.0.50; tree-sitter elixir-ts-mode hangs and memory
 leak on some elixir and heex code
Date: Sun, 08 Sep 2024 10:02:55 +0300
> From: Yuan Fu <casouri <at> gmail.com>
> Date: Sat, 7 Sep 2024 22:57:29 -0700
> Cc: mail <at> ssbb.me,
>  wkirschbaum <at> gmail.com,
>  72863 <at> debbugs.gnu.org
> 
> 
> 
> > On Sep 7, 2024, at 10:54 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> > 
> >> From: Yuan Fu <casouri <at> gmail.com>
> >> Date: Sat, 7 Sep 2024 22:44:53 -0700
> >> Cc: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>,
> >> Eli Zaretskii <eliz <at> gnu.org>,
> >> 72863 <at> debbugs.gnu.org
> >> 
> >> 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?
> > 
> > Why would there be a compiler warning?  What kind of warning?
> 
> A function-not-used warning. Maybe it’s an lldb thing?

If the function is not static, there should be no such warning.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#72863; Package emacs. (Sun, 08 Sep 2024 07:50:01 GMT) Full text and rfc822 format available.

Message #38 received at 72863 <at> debbugs.gnu.org (full text, mbox):

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

> On Sep 8, 2024, at 12:02 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
>> From: Yuan Fu <casouri <at> gmail.com>
>> Date: Sat, 7 Sep 2024 22:57:29 -0700
>> Cc: mail <at> ssbb.me,
>> wkirschbaum <at> gmail.com,
>> 72863 <at> debbugs.gnu.org
>> 
>> 
>> 
>>> On Sep 7, 2024, at 10:54 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>>> 
>>>> From: Yuan Fu <casouri <at> gmail.com>
>>>> Date: Sat, 7 Sep 2024 22:44:53 -0700
>>>> Cc: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>,
>>>> Eli Zaretskii <eliz <at> gnu.org>,
>>>> 72863 <at> debbugs.gnu.org
>>>> 
>>>> 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?
>>> 
>>> Why would there be a compiler warning?  What kind of warning?
>> 
>> A function-not-used warning. Maybe it’s an lldb thing?
> 
> If the function is not static, there should be no such warning.

Ah, you’re right, I marked it static. Thanks!

Yuan



Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#72863; Package emacs. (Wed, 11 Sep 2024 03:47:02 GMT) Full text and rfc822 format available.

Message #41 received at 72863 <at> debbugs.gnu.org (full text, mbox):

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

> On Sep 8, 2024, at 12:48 AM, Yuan Fu <casouri <at> gmail.com> wrote:
> 
> 
> 
>> On Sep 8, 2024, at 12:02 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> 
>>> From: Yuan Fu <casouri <at> gmail.com>
>>> Date: Sat, 7 Sep 2024 22:57:29 -0700
>>> Cc: mail <at> ssbb.me,
>>> wkirschbaum <at> gmail.com,
>>> 72863 <at> debbugs.gnu.org
>>> 
>>> 
>>> 
>>>> On Sep 7, 2024, at 10:54 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>>>> 
>>>>> From: Yuan Fu <casouri <at> gmail.com>
>>>>> Date: Sat, 7 Sep 2024 22:44:53 -0700
>>>>> Cc: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>,
>>>>> Eli Zaretskii <eliz <at> gnu.org>,
>>>>> 72863 <at> debbugs.gnu.org
>>>>> 
>>>>> 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?
>>>> 
>>>> Why would there be a compiler warning?  What kind of warning?
>>> 
>>> A function-not-used warning. Maybe it’s an lldb thing?
>> 
>> If the function is not static, there should be no such warning.
> 
> Ah, you’re right, I marked it static. Thanks!
> 
> Yuan

Good news: not an Emacs bug. Bad news: a tree-sitter bug. Turns out I made an error in my test program, which is the reason why Emacs hangs but the test program doesn’t. Once I fixed the error, the test program hangs too. I submitted a bug report to tree-sitter: https://github.com/tree-sitter/tree-sitter/issues/3620

I can finally sleep soundly at night now; and I guess tree-sitter dev will start having sleepless nights :-)

Yuan





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#72863; Package emacs. (Wed, 11 Sep 2024 19:24:01 GMT) Full text and rfc822 format available.

Message #44 received at 72863 <at> debbugs.gnu.org (full text, mbox):

From: mail <at> ssbb.me
To: Yuan Fu <casouri <at> gmail.com>
Cc: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>,
 72863 <at> debbugs.gnu.org
Subject: Re: bug#72863: 30.0.50; tree-sitter elixir-ts-mode hangs and memory
 leak on some elixir and heex code
Date: Wed, 11 Sep 2024 23:22:34 +0400
[Message part 1 (text/plain, inline)]
Wow, thank you so much for diving into this issue! I'll keep track of it in tree-sitter repo from now on.

It seems like other integrations somehow manage to avoid hanging or crashing the main process, so it doesn't affect them?

I just checked in the Zed editor again to confirm. When I type a={, it fails to highlight the rest of the embedded HEEX (but only within the current function) though.


> On Sep 11, 2024, at 7:45 AM, Yuan Fu <casouri <at> gmail.com> wrote:
> 
> 
> 
>> On Sep 8, 2024, at 12:48 AM, Yuan Fu <casouri <at> gmail.com> wrote:
>> 
>> 
>> 
>>> On Sep 8, 2024, at 12:02 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>>> 
>>>> From: Yuan Fu <casouri <at> gmail.com>
>>>> Date: Sat, 7 Sep 2024 22:57:29 -0700
>>>> Cc: mail <at> ssbb.me,
>>>> wkirschbaum <at> gmail.com,
>>>> 72863 <at> debbugs.gnu.org
>>>> 
>>>> 
>>>> 
>>>>> On Sep 7, 2024, at 10:54 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>>>>> 
>>>>>> From: Yuan Fu <casouri <at> gmail.com>
>>>>>> Date: Sat, 7 Sep 2024 22:44:53 -0700
>>>>>> Cc: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>,
>>>>>> Eli Zaretskii <eliz <at> gnu.org>,
>>>>>> 72863 <at> debbugs.gnu.org
>>>>>> 
>>>>>> 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?
>>>>> 
>>>>> Why would there be a compiler warning?  What kind of warning?
>>>> 
>>>> A function-not-used warning. Maybe it’s an lldb thing?
>>> 
>>> If the function is not static, there should be no such warning.
>> 
>> Ah, you’re right, I marked it static. Thanks!
>> 
>> Yuan
> 
> Good news: not an Emacs bug. Bad news: a tree-sitter bug. Turns out I made an error in my test program, which is the reason why Emacs hangs but the test program doesn’t. Once I fixed the error, the test program hangs too. I submitted a bug report to tree-sitter: https://github.com/tree-sitter/tree-sitter/issues/3620
> 
> I can finally sleep soundly at night now; and I guess tree-sitter dev will start having sleepless nights :-)
> 
> Yuan
> 

[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#72863; Package emacs. (Thu, 12 Sep 2024 07:50:01 GMT) Full text and rfc822 format available.

Message #47 received at 72863 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#72863: 30.0.50; tree-sitter elixir-ts-mode hangs and memory
 leak on some elixir and heex code
Date: Thu, 12 Sep 2024 00:47:36 -0700

> On Sep 11, 2024, at 12:22 PM, mail <at> ssbb.me wrote:
> 
> Wow, thank you so much for diving into this issue! I'll keep track of it in tree-sitter repo from now on.

My pleasure ;-)

> It seems like other integrations somehow manage to avoid hanging or crashing the main process, so it doesn't affect them?
> I just checked in the Zed editor again to confirm. When I type a={, it fails to highlight the rest of the embedded HEEX (but only within the current function) though.

I know a couple editors uses async parsing, Zed probably also uses async parsing.

Yuan


>> On Sep 11, 2024, at 7:45 AM, Yuan Fu <casouri <at> gmail.com> wrote:
>> 
>> 
>> 
>>> On Sep 8, 2024, at 12:48 AM, Yuan Fu <casouri <at> gmail.com> wrote:
>>> 
>>> 
>>> 
>>>> On Sep 8, 2024, at 12:02 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>>>> 
>>>>> From: Yuan Fu <casouri <at> gmail.com>
>>>>> Date: Sat, 7 Sep 2024 22:57:29 -0700
>>>>> Cc: mail <at> ssbb.me,
>>>>> wkirschbaum <at> gmail.com,
>>>>> 72863 <at> debbugs.gnu.org
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Sep 7, 2024, at 10:54 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>>>>>> 
>>>>>>> From: Yuan Fu <casouri <at> gmail.com>
>>>>>>> Date: Sat, 7 Sep 2024 22:44:53 -0700
>>>>>>> Cc: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>,
>>>>>>> Eli Zaretskii <eliz <at> gnu.org>,
>>>>>>> 72863 <at> debbugs.gnu.org
>>>>>>> 
>>>>>>> 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?
>>>>>> 
>>>>>> Why would there be a compiler warning?  What kind of warning?
>>>>> 
>>>>> A function-not-used warning. Maybe it’s an lldb thing?
>>>> 
>>>> If the function is not static, there should be no such warning.
>>> 
>>> Ah, you’re right, I marked it static. Thanks!
>>> 
>>> Yuan
>> 
>> Good news: not an Emacs bug. Bad news: a tree-sitter bug. Turns out I made an error in my test program, which is the reason why Emacs hangs but the test program doesn’t. Once I fixed the error, the test program hangs too. I submitted a bug report to tree-sitter: https://github.com/tree-sitter/tree-sitter/issues/3620
>> 
>> I can finally sleep soundly at night now; and I guess tree-sitter dev will start having sleepless nights :-)
>> 
>> Yuan
>> 
> 





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#72863; Package emacs. (Mon, 16 Sep 2024 07:01:02 GMT) Full text and rfc822 format available.

Message #50 received at 72863 <at> debbugs.gnu.org (full text, mbox):

From: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>
To: Yuan Fu <casouri <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 72863 <at> debbugs.gnu.org, mail <at> ssbb.me
Subject: Re: bug#72863: 30.0.50; tree-sitter elixir-ts-mode hangs and memory
 leak on some elixir and heex code
Date: Mon, 16 Sep 2024 08:58:48 +0200
[Message part 1 (text/plain, inline)]
Thanks Yuan, and thanks for the improvements on elixir-ts-mode.

Kind regards,
Wilhelm

On Thu, Sep 12, 2024 at 9:47 AM Yuan Fu <casouri <at> gmail.com> wrote:

>
>
> > On Sep 11, 2024, at 12:22 PM, mail <at> ssbb.me wrote:
> >
> > Wow, thank you so much for diving into this issue! I'll keep track of it
> in tree-sitter repo from now on.
>
> My pleasure ;-)
>
> > It seems like other integrations somehow manage to avoid hanging or
> crashing the main process, so it doesn't affect them?
> > I just checked in the Zed editor again to confirm. When I type a={, it
> fails to highlight the rest of the embedded HEEX (but only within the
> current function) though.
>
> I know a couple editors uses async parsing, Zed probably also uses async
> parsing.
>
> Yuan
>
>
> >> On Sep 11, 2024, at 7:45 AM, Yuan Fu <casouri <at> gmail.com> wrote:
> >>
> >>
> >>
> >>> On Sep 8, 2024, at 12:48 AM, Yuan Fu <casouri <at> gmail.com> wrote:
> >>>
> >>>
> >>>
> >>>> On Sep 8, 2024, at 12:02 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> >>>>
> >>>>> From: Yuan Fu <casouri <at> gmail.com>
> >>>>> Date: Sat, 7 Sep 2024 22:57:29 -0700
> >>>>> Cc: mail <at> ssbb.me,
> >>>>> wkirschbaum <at> gmail.com,
> >>>>> 72863 <at> debbugs.gnu.org
> >>>>>
> >>>>>
> >>>>>
> >>>>>> On Sep 7, 2024, at 10:54 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> >>>>>>
> >>>>>>> From: Yuan Fu <casouri <at> gmail.com>
> >>>>>>> Date: Sat, 7 Sep 2024 22:44:53 -0700
> >>>>>>> Cc: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>,
> >>>>>>> Eli Zaretskii <eliz <at> gnu.org>,
> >>>>>>> 72863 <at> debbugs.gnu.org
> >>>>>>>
> >>>>>>> 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?
> >>>>>>
> >>>>>> Why would there be a compiler warning?  What kind of warning?
> >>>>>
> >>>>> A function-not-used warning. Maybe it’s an lldb thing?
> >>>>
> >>>> If the function is not static, there should be no such warning.
> >>>
> >>> Ah, you’re right, I marked it static. Thanks!
> >>>
> >>> Yuan
> >>
> >> Good news: not an Emacs bug. Bad news: a tree-sitter bug. Turns out I
> made an error in my test program, which is the reason why Emacs hangs but
> the test program doesn’t. Once I fixed the error, the test program hangs
> too. I submitted a bug report to tree-sitter:
> https://github.com/tree-sitter/tree-sitter/issues/3620
> >>
> >> I can finally sleep soundly at night now; and I guess tree-sitter dev
> will start having sleepless nights :-)
> >>
> >> Yuan
> >>
> >
>
>
[Message part 2 (text/html, inline)]

This bug report was last modified 281 days ago.

Previous Next


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