guix weather runaway memory consumption

  • Done
  • quality assurance status badge
Details
4 participants
  • Danny Milosavljevic
  • Ludovic Courtès
  • Maxim Cournoyer
  • swedebugia
Owner
unassigned
Submitted by
Danny Milosavljevic
Severity
normal

Debbugs page

Danny Milosavljevic wrote 6 years ago
(address . bug-guix@gnu.org)
20190509224044.60b37e3f@scratchpost.org
With guix master a0dc97a517cbc4c82640e30cacb2a564d128bbe9 guix weather consumes
8 GB of memory on a machine with 8 GB of memory and 1 GB of swap, then is killed
by Linux OOM killer.

Reproducible every time.

Reduced problem to GUIX_PACKAGE_PATH being set.

If I unset it, it works.

Attached contents of $GUIX_PACKAGE_PATH directory.
Attachment: wip2.tar.gz
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAlzUkE0ACgkQ5xo1VCww
uqUmvAgAlooFp1AHfHZbK/hTaOXOjRMahYddKv57G0bKzNa054UndPwop8M7pl9U
1t4PzqDN0LBjK4MgLcTLztQg77FnT8FM4n50KMWWJycFOi5w1WLG4UZtcvmlUxcs
65H/vgFs8dN1Ep416ItLZaRqy15wuF2WKVYPukqNjXHajw3PtDQjIdHfrggx+Lnv
9X2F0L8d0nKs9jPqkWScnQmrpgI30exnJ6fDEgb7LOY3mcfzYF42QvWduAGBalqx
Kmap5tw1M8EiQdeUlLwepyjTGNiRZYI/ESa74rkOFLN1SMh0xReOe90fx7jzLZZD
iB/4PLleH10tmEeGAJlNOgH1w624pw==
=16h6
-----END PGP SIGNATURE-----


Ludovic Courtès wrote 6 years ago
(name . Danny Milosavljevic)(address . dannym@scratchpost.org)(address . 35660@debbugs.gnu.org)
87ftpiozfl.fsf@gnu.org
Hi Danny,

Danny Milosavljevic <dannym@scratchpost.org> skribis:

Toggle quote (10 lines)
> With guix master a0dc97a517cbc4c82640e30cacb2a564d128bbe9 guix weather consumes
> 8 GB of memory on a machine with 8 GB of memory and 1 GB of swap, then is killed
> by Linux OOM killer.
>
> Reproducible every time.
>
> Reduced problem to GUIX_PACKAGE_PATH being set.
>
> If I unset it, it works.

I don’t think this is the place to debug personal package collections.
:-)

I’d love to give a hand but I feel we’re already overwhelmed with bugs
related to things happening on ‘master’.

WDYT?

Thanks,
Ludo’.
Danny Milosavljevic wrote 6 years ago
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 35660@debbugs.gnu.org)
20190513232558.22b4afc0@scratchpost.org
Hi Ludo,

On Mon, 13 May 2019 22:46:22 +0200
Ludovic Courtès <ludo@gnu.org> wrote:

Toggle quote (3 lines)
> I don’t think this is the place to debug personal package collections.
> :-)

I didn't even remember the personal package collection at first.
This here is a bug in guix that happens to manifest with that personal package
collection.

The failure mode here is very very bad. Guix will consume all available
memory and then start on the swap, at which point the computer will
become unresponsive to any input and the user can't save any open
documents and has to kill the power to the computer.

After the user did that and restarted the computer, it will happen all
over again on the next "guix weather" (100% of the time).

Toggle quote (5 lines)
> I’d love to give a hand but I feel we’re already overwhelmed with bugs
> related to things happening on ‘master’.
>
> WDYT?

Oh, it's not time-critical at all for me.

I reported this bug for documentation--I already know how to work
around it.

Though there is a bug somewhere--it's not going to magically vanish.

But a user is going to encounter the same problem eventually, then not
reduce it to his GUIX_PACKAGE_PATH and give up.

Furthermore, if he wanted to find out where exactly the problem is, he'd have
to delete files in $GUIX_PACKAGE_PATH one by one and invoke guix weather
in-between, each time crashing his entire computer after like 10 min per try.
That's not a good user experience.
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAlzZ4OYACgkQ5xo1VCww
uqWp9AgAl8JEXUhECVopYaD6cnqHwKlcBWuAFBwr0pzzl843pcX/BGoyy4GRO3kV
poJISfK6BUWteBian8HRTBfGp+Ss0ZioZJ/ZqS48RIlxdb3hJNI1OTozEccYmZWm
fydkD6FClqo5uQtM4q2JOc3c27jvffvkU5wvSSGUb95ZirDfXsk1g7+knZVzRuwg
sCLlE10RdcqUfNUexose0r4Pvyg8ip1gtizn/4OMLauCle4KpOI107rdQi0jjUdd
kEYKOEWsSh0fnFpTJ+wQtpSUBLubbUBA58CCcGZaXa3M0vFM5RxiL2Cn/EqFfYy4
2yCc0UQV0Atq18QYaGLD7X7VI/h/Dw==
=gfbi
-----END PGP SIGNATURE-----


Ludovic Courtès wrote 6 years ago
(name . Danny Milosavljevic)(address . dannym@scratchpost.org)(address . 35660@debbugs.gnu.org)
877easyd0w.fsf@gnu.org
Hi Danny,

Danny Milosavljevic <dannym@scratchpost.org> skribis:

Toggle quote (5 lines)
> The failure mode here is very very bad. Guix will consume all available
> memory and then start on the swap, at which point the computer will
> become unresponsive to any input and the user can't save any open
> documents and has to kill the power to the computer.

I agree that the failure mode is terrible. It’s very likely a cycle in
the package graph, given the symptoms you describe. So ‘guix build
OFFENDING-PACKAGE’ would probably give you the same result.

Chris Baines proposed a patch a while back to detect and report cycles,
but we never got around to polishing and integrating it. That would
probably help a lot in these cases.

We can open a new bug for that (if there’s not already one), but I think
it should be framed in terms of cycle detection in the package graph and
error reporting.

Thanks,
Ludo’.
swedebugia wrote 6 years ago
(address . 35660@debbugs.gnu.org)
7cb8d719-ffe9-ccf1-e68e-936401869692@riseup.net
On 2019-05-14 22:52, Ludovic Courtès wrote:
Toggle quote (21 lines)
> Hi Danny,
>
> Danny Milosavljevic <dannym@scratchpost.org> skribis:
>
>> The failure mode here is very very bad. Guix will consume all available
>> memory and then start on the swap, at which point the computer will
>> become unresponsive to any input and the user can't save any open
>> documents and has to kill the power to the computer.
>
> I agree that the failure mode is terrible. It’s very likely a cycle in
> the package graph, given the symptoms you describe. So ‘guix build
> OFFENDING-PACKAGE’ would probably give you the same result.
>
> Chris Baines proposed a patch a while back to detect and report cycles,
> but we never got around to polishing and integrating it. That would
> probably help a lot in these cases.
>
> We can open a new bug for that (if there’s not already one), but I think
> it should be framed in terms of cycle detection in the package graph and
> error reporting.

+1

When working on the NPM importer earlier this was very very common
happening with "guix build NPM-PACKAGE" because of cycles.

My strategy was to manually kill the build after a minute or two if no
output was produced.

--
Cheers Swedebugia
Maxim Cournoyer wrote 4 years ago
(name . swedebugia)(address . swedebugia@riseup.net)
87eeary363.fsf@gmail.com
retitle 35660 Implement cycle detection with proper reporting
thanks

swedebugia <swedebugia@riseup.net> writes:

Toggle quote (23 lines)
> On 2019-05-14 22:52, Ludovic Courtès wrote:
>> Hi Danny,
>> Danny Milosavljevic <dannym@scratchpost.org> skribis:
>>
>>> The failure mode here is very very bad. Guix will consume all available
>>> memory and then start on the swap, at which point the computer will
>>> become unresponsive to any input and the user can't save any open
>>> documents and has to kill the power to the computer.
>> I agree that the failure mode is terrible. It’s very likely a cycle
>> in
>> the package graph, given the symptoms you describe. So ‘guix build
>> OFFENDING-PACKAGE’ would probably give you the same result.
>> Chris Baines proposed a patch a while back to detect and report
>> cycles,
>> but we never got around to polishing and integrating it. That would
>> probably help a lot in these cases.
>> We can open a new bug for that (if there’s not already one), but I
>> think
>> it should be framed in terms of cycle detection in the package graph and
>> error reporting.
>
> +1

This would indeed be very useful. I'm retitling this bug so that it is
more actionable. Could someone link to the patch Chris Baines had
written going in this direction?

Thanks,

Maxim
Maxim Cournoyer wrote 3 years ago
control message for bug #35660
(address . control@debbugs.gnu.org)
87edyp37ud.fsf@gmail.com
close 35660
quit
?
Your comment

This issue is archived.

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

To respond to this issue using the mumi CLI, first switch to it
mumi current 35660
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
You may also tag this issue. See list of standard tags. For example, to set the confirmed and easy tags
mumi command -t +confirmed -t +easy
Or, remove the moreinfo tag and set the help tag
mumi command -t -moreinfo -t +help