GNU bug report logs - #60653
30.0.50; tree-sitter: `treesit-[explore/inspect]-mode' can leak memory

Previous Next

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

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

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

From: Mickey Petersen <mickey <at> masteringemacs.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.50; tree-sitter: `treesit-[explore/inspect]-mode' can leak memory
Date: Sun, 08 Jan 2023 10:44:44 +0000

If you enable either the `treesit-inspect-mode' or `treesit-explore-mode' and leave them to their devices, you may find that through excessive editing, particularly programmatically, that it can cause memory leaks over time.

I am 90% certain those modes are responsible: if I do not use them, then I do not experience these issues. I have had the oomkiller reap the Emacs process as it simply balloons out of control over time.





In GNU Emacs 30.0.50 (build 6, x86_64-pc-linux-gnu, GTK+ Version
 3.24.20, cairo version 1.16.0) of 2023-01-02 built on mickey-work
Repository revision: c209802f7b3721a1b95113290934a23fee88f678
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12013000
System Description: Ubuntu 20.04.3 LTS

Configured using:
 'configure --with-native-compilation --with-json --with-mailutils
 --without-compress-install --with-imagemagick CC=gcc-10'

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

From: Yuan Fu <casouri <at> gmail.com>
To: Mickey Petersen <mickey <at> masteringemacs.org>
Cc: 60653 <at> debbugs.gnu.org
Subject: Re: bug#60653: 30.0.50; tree-sitter: 
 `treesit-[explore/inspect]-mode' can leak memory
Date: Sun, 8 Jan 2023 19:38:49 -0800

Mickey Petersen <mickey <at> masteringemacs.org> writes:

> If you enable either the `treesit-inspect-mode' or
> `treesit-explore-mode' and leave them to their devices, you may find
> that through excessive editing, particularly programmatically, that it
> can cause memory leaks over time.
>
> I am 90% certain those modes are responsible: if I do not use them,
> then I do not experience these issues. I have had the oomkiller reap
> the Emacs process as it simply balloons out of control over time.

Hmmm, maybe it’s just using a lot of memory. Emacs never returns memory
once it allocates them. Are you opening a lot of buffers? A tree-sitter
parse tree uses about 10x memory as the source text.

Yuan

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

From: Mickey Petersen <mickey <at> masteringemacs.org>
To: Yuan Fu <casouri <at> gmail.com>
Cc: 60653 <at> debbugs.gnu.org
Subject: Re: bug#60653: 30.0.50; tree-sitter:
 `treesit-[explore/inspect]-mode' can leak memory
Date: Mon, 09 Jan 2023 08:58:50 +0000

Yuan Fu <casouri <at> gmail.com> writes:

> Mickey Petersen <mickey <at> masteringemacs.org> writes:
>
>> If you enable either the `treesit-inspect-mode' or
>> `treesit-explore-mode' and leave them to their devices, you may find
>> that through excessive editing, particularly programmatically, that it
>> can cause memory leaks over time.
>>
>> I am 90% certain those modes are responsible: if I do not use them,
>> then I do not experience these issues. I have had the oomkiller reap
>> the Emacs process as it simply balloons out of control over time.
>
> Hmmm, maybe it’s just using a lot of memory. Emacs never returns memory
> once it allocates them. Are you opening a lot of buffers? A tree-sitter
> parse tree uses about 10x memory as the source text.
>

Nah. This VM's got 64 GiB RAM. So that's not it. And my list of open
buffers does go up or down a bit, but as I'm working on TS stuff, it's
mostly the same handful of smallish files.

Note that I used the third-party tree-sitter implementation for a long
time and never encountered this. And it never seems to happen if I
leave the explorer/inspect mode off. Note that I do do a lot of repeat
editing in the ones that have those modes active.

There's definitely something going on here, and I wish I had more
information to give you, Yuan!

> Yuan

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

From: Yuan Fu <casouri <at> gmail.com>
To: Mickey Petersen <mickey <at> masteringemacs.org>
Cc: 60653 <at> debbugs.gnu.org
Subject: Re: bug#60653: 30.0.50; tree-sitter: 
 `treesit-[explore/inspect]-mode' can leak memory
Date: Mon, 9 Jan 2023 19:45:14 -0800

Mickey Petersen <mickey <at> masteringemacs.org> writes:

> Yuan Fu <casouri <at> gmail.com> writes:
>
>> Mickey Petersen <mickey <at> masteringemacs.org> writes:
>>
>>> If you enable either the `treesit-inspect-mode' or
>>> `treesit-explore-mode' and leave them to their devices, you may find
>>> that through excessive editing, particularly programmatically, that it
>>> can cause memory leaks over time.
>>>
>>> I am 90% certain those modes are responsible: if I do not use them,
>>> then I do not experience these issues. I have had the oomkiller reap
>>> the Emacs process as it simply balloons out of control over time.
>>
>> Hmmm, maybe it’s just using a lot of memory. Emacs never returns memory
>> once it allocates them. Are you opening a lot of buffers? A tree-sitter
>> parse tree uses about 10x memory as the source text.
>>
>
> Nah. This VM's got 64 GiB RAM. So that's not it. And my list of open
> buffers does go up or down a bit, but as I'm working on TS stuff, it's
> mostly the same handful of smallish files.
>
> Note that I used the third-party tree-sitter implementation for a long
> time and never encountered this. And it never seems to happen if I
> leave the explorer/inspect mode off. Note that I do do a lot of repeat
> editing in the ones that have those modes active.
>
> There's definitely something going on here, and I wish I had more
> information to give you, Yuan!

Thank you. I’ll try to figure it out! At this point my guess is that
there’s some leak in the C code which is triggered a lot by
treesit-explore-mode.

Yuan

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

From: Yuan Fu <casouri <at> gmail.com>
To: Mickey Petersen <mickey <at> masteringemacs.org>
Cc: 60653 <at> debbugs.gnu.org
Subject: Re: bug#60653: 30.0.50; tree-sitter: 
 `treesit-[explore/inspect]-mode' can leak memory
Date: Tue, 17 Jan 2023 01:39:00 -0800

Yuan Fu <casouri <at> gmail.com> writes:

> Mickey Petersen <mickey <at> masteringemacs.org> writes:
>
>> Yuan Fu <casouri <at> gmail.com> writes:
>>
>>> Mickey Petersen <mickey <at> masteringemacs.org> writes:
>>>
>>>> If you enable either the `treesit-inspect-mode' or
>>>> `treesit-explore-mode' and leave them to their devices, you may find
>>>> that through excessive editing, particularly programmatically, that it
>>>> can cause memory leaks over time.
>>>>
>>>> I am 90% certain those modes are responsible: if I do not use them,
>>>> then I do not experience these issues. I have had the oomkiller reap
>>>> the Emacs process as it simply balloons out of control over time.
>>>
>>> Hmmm, maybe it’s just using a lot of memory. Emacs never returns memory
>>> once it allocates them. Are you opening a lot of buffers? A tree-sitter
>>> parse tree uses about 10x memory as the source text.
>>>
>>
>> Nah. This VM's got 64 GiB RAM. So that's not it. And my list of open
>> buffers does go up or down a bit, but as I'm working on TS stuff, it's
>> mostly the same handful of smallish files.
>>
>> Note that I used the third-party tree-sitter implementation for a long
>> time and never encountered this. And it never seems to happen if I
>> leave the explorer/inspect mode off. Note that I do do a lot of repeat
>> editing in the ones that have those modes active.
>>
>> There's definitely something going on here, and I wish I had more
>> information to give you, Yuan!
>
> Thank you. I’ll try to figure it out! At this point my guess is that
> there’s some leak in the C code which is triggered a lot by
> treesit-explore-mode.

When you observe the memory leak, do you see warnings mentioning pure
storage, etc? I’m asking because we just fixed a bug that overflows the
pure space which may or may not be the same bug as this one.

Yuan

Previous Next

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