GNU bug report logs - #79280
package installation leaks tar-mode data buffers

Previous Next

To reply to this bug, email your comments to 79280 AT debbugs.gnu.org.
There is no need to reopen the bug first.

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

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

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Emacs Bug Report <bug-gnu-emacs <at> gnu.org>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: package installation leaks tar-mode data buffers
Date: Wed, 20 Aug 2025 19:50:14 +0200

[Message part 1 (text/plain, inline)]

Apparently, package.el generates at least one leaked buffer for each package installed. From what I can tell, it's the use of tar-mode in temporary buffers, as in

  (with-temp-buffer
    (tar-mode)
    ...)

that is the problem: tar-mode will generate a helper buffer which is normally removed when the tar-mode buffer is killed, but temporary buffers inhibit the kill-buffer-hook so that never happens.

Here is a straightforward patch: explicitly return to fundamental-mode before the temporary buffer is destroyed.

An alternative would be to change tar-mode so that it doesn't rely on kill-buffer-hook to release its helper buffer. A finaliser would do, but those see so little use that it makes me a bit uneasy.

Are there other modes that may have similar problems?

[package-tar-buffer-leak.diff (application/octet-stream, attachment)]

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: Emacs Bug Report <bug-gnu-emacs <at> gnu.org>
Subject: Re: package installation leaks tar-mode data buffers
Date: Wed, 20 Aug 2025 17:06:15 -0400

> that is the problem: tar-mode will generate a helper buffer which is
> normally removed when the tar-mode buffer is killed, but temporary
> buffers inhibit the kill-buffer-hook so that never happens.

Maybe we should be more careful when we skip `kill-buffer-hook`.
Maybe we should run the local part of the hook (and skip the global part)?


        Stefan

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

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Emacs Bug Report <bug-gnu-emacs <at> gnu.org>
Subject: Re: package installation leaks tar-mode data buffers
Date: Thu, 21 Aug 2025 13:52:20 +0200

20 aug. 2025 kl. 23.06 skrev Stefan Monnier <monnier <at> iro.umontreal.ca>:

> Maybe we should be more careful when we skip `kill-buffer-hook`.
> Maybe we should run the local part of the hook (and skip the global part)?

Yes, I considered that but was worried about not having a hard way to kill a buffer without misguided kill-buffer-hook functions getting in the way. We'd be adding an override to the override, then an override to the override to the override, and so on.

A more principled solution might be to make buffers GC-able like any other object, at least optionally. Exactly how to do this can be discussed but maybe just being able to remove a buffer from Vbuffer_alist would do. (We have one buffer like that, Vprin1_to_string.) Of course, we'd have to teach the GC to destroy buffers. Fkill_buffer is depressingly long and complicated and should be broken up in smaller parts.

For now I'll just push the patch as a stopgap measure, but am definitely open to better solutions.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: 79280 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#79280: package installation leaks tar-mode data buffers
Date: Thu, 21 Aug 2025 17:02:58 +0300

> Cc: 79280 <at> debbugs.gnu.org
> From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
> Date: Thu, 21 Aug 2025 13:52:20 +0200
> 
> A more principled solution might be to make buffers GC-able like any other object, at least optionally. Exactly how to do this can be discussed but maybe just being able to remove a buffer from Vbuffer_alist would do. (We have one buffer like that, Vprin1_to_string.) Of course, we'd have to teach the GC to destroy buffers. Fkill_buffer is depressingly long and complicated and should be broken up in smaller parts.

There's no way Emacs could know whether a buffer is still needed.
Users that want to get rid of buffers that were not accessed for too
long can use the midnight.el features to do that.  So I don't think we
need to add any automation here.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79280 <at> debbugs.gnu.org,
 Mattias Engdegård <mattias.engdegard <at> gmail.com>
Subject: Re: bug#79280: package installation leaks tar-mode data buffers
Date: Thu, 21 Aug 2025 15:15:57 -0400

>> A more principled solution might be to make buffers GC-able like any other
>> object, at least optionally. Exactly how to do this can be discussed but
>> maybe just being able to remove a buffer from Vbuffer_alist would do. (We
>> have one buffer like that, Vprin1_to_string.) Of course, we'd have to
>> teach the GC to destroy buffers. Fkill_buffer is depressingly long and
>> complicated and should be broken up in smaller parts.
>
> There's no way Emacs could know whether a buffer is still needed.
> Users that want to get rid of buffers that were not accessed for too
> long can use the midnight.el features to do that.  So I don't think we
> need to add any automation here.

I don't think Mattias is suggesting to GC normal buffers, but rather to
allow the creation&use of anonymous buffers (and then to make `tar-mode`
use such an anonymous buffer for its auxiliary buffer).

It's been suggested/mentioned several times in the past, but it's not
clear how that would work.  Maybe we could allow `buffer-name` to be `t`
for buffers which have no name yet are still live, and then collect (and
find solutions for) all the problems this introduces.


        Stefan

Message #22 received at 79280-done <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 79280-done <at> debbugs.gnu.org
Subject: Re: bug#79280: package installation leaks tar-mode data buffers
Date: Fri, 22 Aug 2025 17:29:47 +0200

21 aug. 2025 kl. 21.15 skrev Stefan Monnier <monnier <at> iro.umontreal.ca>:

> It's been suggested/mentioned several times in the past, but it's not
> clear how that would work.  Maybe we could allow `buffer-name` to be `t`
> for buffers which have no name yet are still live, and then collect (and
> find solutions for) all the problems this introduces.

Right. The idea would be to have unlisted buffers, which may or may not have a name but wouldn't be in Vbuffer_alist. We may need to impose other restrictions such as not being used in a window, to reduce the number of things that can go wrong. But the GC proving an absence of references to a buffer is a pretty solid ground for removal.

This should be completely feasible but is not very high up on my list of things to do. Meanwhile, hacks like the one made for package.el will have to do.

Anyway, no reason for this bug to dwell any longer at the platform. Closing!

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

From: Richard Stallman <rms <at> gnu.org>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: 79280 <at> debbugs.gnu.org, mattias.engdegard <at> gmail.com
Subject: Re: bug#79280: package installation leaks tar-mode data buffers
Date: Sat, 23 Aug 2025 22:47:31 -0400

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

To have buffers that can be GC'd if not really in use could be useful.
But I think it will be much more convenient to code which uses that
feature if they have names to refer to them by.

Such a buffer could be in the buffer list as usual, but some flag in
the buffer would say that the buffer list should not protect it from
GC.  It would be protected if anything else pointed to it, except
a marker pointing in it I suppose

At the end of GC, if a buffer is not marked to be preserved,
GC could kill it in the usual way.  It could look at all the
buffers in the buffer list to find those it wants to kill.

Because the buffer does have a name, displaying it or selecting it
would be easy.  You could do that with the usual functions and
commands.  Doing so would protect it from GC, for the time.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Previous Next

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