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

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#79280: closed (package installation leaks tar-mode data buffers)
Date: Fri, 22 Aug 2025 15:30:02 +0000

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

Your message dated Fri, 22 Aug 2025 17:29:47 +0200
with message-id <6FB36B54-DA99-44CC-8B29-6BEAAF59E334 <at> gmail.com>
and subject line Re: bug#79280: package installation leaks tar-mode data buffers
has caused the debbugs.gnu.org bug report #79280,
regarding package installation leaks tar-mode data buffers
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
79280: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=79280
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

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 3 (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 part 5 (message/rfc822, inline)]

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!

Previous Next

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