‘guix publish’ memory leak

  • Done
  • quality assurance status badge
Details
2 participants
  • Jonathan Roberts
  • Ludovic Courtès
Owner
unassigned
Submitted by
Ludovic Courtès
Severity
important
L
L
Ludovic Courtès wrote on 6 Mar 22:39 +0100
‘guix publish’ memory leak
(address . bug-guix@gnu.org)
87zfvb6nwi.fsf@inria.fr
It seems that ‘guix publish’ has been leaking memory noticeably I’d say
since the beginning of the year on berlin. After roughly 10 days, it
has several GiB resident and needs to be restarted or it becomes too
unresponsive.

I wonder what could be causing this because we used to let it run for
months without problems I believe.

This is what’s currently running on berlin:

/gnu/store/cpnshv80n3mar5lwp4qqa2dxxxv4zb03-guix-1.4.0-16.aeb4943/libexec/guix/guile \
/gnu/store/cpnshv80n3mar5lwp4qqa2dxxxv4zb03-guix-1.4.0-16.aeb4943/bin/guix \
publish -u guix-publish -p 3000 -C lzip:9 -C zstd:19 --nar-path=nar \
--listen=localhost --workers=8 --ttl=15552000s \
--cache=/var/cache/guix/publish --cache-bypass-threshold=157286400

… coming from commit 21e4d6cd6913eca131f2c0fd0cd509fc843c7eb8.

I don’t see anything that changed recently, be it in maintenance.git
(for the parameters), ‘guix publish’, guile-{lzlib,zstd}, or Guile.
Maybe we had just been lucky? Anyone else seeing this?

Ludo’.
L
L
Ludovic Courtès wrote on 4 Apr 23:20 +0200
control message for bug #69596
(address . control@debbugs.gnu.org)
87il0wu8ol.fsf@gnu.org
severity 69596 important
quit
L
L
Ludovic Courtès wrote on 29 Apr 00:03 +0200
Re: bug#69596: ‘guix publish’ memory leak
(address . 69596@debbugs.gnu.org)
87le4xgn5n.fsf@gnu.org
Hi!

Ludovic Courtès <ludo@gnu.org> skribis:

Toggle quote (18 lines)
> It seems that ‘guix publish’ has been leaking memory noticeably I’d say
> since the beginning of the year on berlin. After roughly 10 days, it
> has several GiB resident and needs to be restarted or it becomes too
> unresponsive.
>
> I wonder what could be causing this because we used to let it run for
> months without problems I believe.
>
> This is what’s currently running on berlin:
>
> /gnu/store/cpnshv80n3mar5lwp4qqa2dxxxv4zb03-guix-1.4.0-16.aeb4943/libexec/guix/guile \
> /gnu/store/cpnshv80n3mar5lwp4qqa2dxxxv4zb03-guix-1.4.0-16.aeb4943/bin/guix \
> publish -u guix-publish -p 3000 -C lzip:9 -C zstd:19 --nar-path=nar \
> --listen=localhost --workers=8 --ttl=15552000s \
> --cache=/var/cache/guix/publish --cache-bypass-threshold=157286400
>
> … coming from commit 21e4d6cd6913eca131f2c0fd0cd509fc843c7eb8.

It turned out to be a guile-lzlib leak that had always been present:


The reason we were seeing it more on berlin is probably because we
increased the cache-bypass-threshold, which goes through the
‘make-lzip-output-port’ code path (as opposed to
‘call-with-lzip-output-port’).

The bug could be reproduced with:

guix publish -p 8124 … &
while true ; do wget -q -O/dev/full http://localhost:8124/nar/lzip/…-coreutils-9.1; done

(Replace the ellipses with the actual store file name of coreutils.)

Fixed by commit 7cef6b7ba555a9dfaf6d09cb7e112b0df77d5141, which updates
guile-lzlib.

Ludo’.
L
L
Ludovic Courtès wrote on 29 Apr 00:04 +0200
control message for bug #69596
(address . control@debbugs.gnu.org)
87jzkhgn5b.fsf@gnu.org
close 69596
quit
J
J
Jonathan Roberts wrote on 30 Apr 10:38 +0200
Possibly breaks Guix pull on foreign distros
(address . 69596@debbugs.gnu.org)
48BA9CD1-7ED9-4FB9-9BB6-3A4E91E0C5CA@googlemail.com
Ran in to the error that a lot of people are reporting - too many heap sections on Guix pull.

Worked through commits to see where Guix pull stopped working for me, and the answer seems to be that it broke with 7cef6b7ba - gnu: guile-lzlib: Update to 0.3.0.

Could this be confirmed and reverted if it is breaking pull?

Sent from my iPhone
?
Your comment

This issue is archived.

To comment on this conversation send an email to 69596@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 69596
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch