GNU bug report logs - #49439
grafts cause “guix environment” to get killed with OOM

Previous Next

Full log

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

From: Julien Lepiller <julien <at> lepiller.eu>
To: bug-guix <at> gnu.org, Sarah Morgensen <iskarian <at> mgsn.dev>,
 Ricardo Wurmus <rekado <at> elephly.net>
Cc: 49439 <at> debbugs.gnu.org
Subject: Re: bug#49439: grafts cause “guix environment” to get killed with OOM
Date: Tue, 27 Jul 2021 10:52:44 -0400

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

I have a similar issue with an ocaml package I use at work. It's not free software, but all its dependencies are. The dependencies are not all yeet in guix, so to reproduce you might have to import them first with "guix import opam -r foo" for ocaml-foo.

The package depends on ocaml-ounit, ocaml-lp, ocaml-apronext, menhir, ocaml-async, ocaml-core, ocaml-graph, ocaml-libsvm, ocaml-minisat, ocaml-ppx-deriving-yojson, ocaml-yojson, ocaml-z3, ocaml-zarith and z3.

In total, that's 118 transitive inputs. Building the profile takes 30 minutes for me, on an SSD. The builder takes 1.5g resident.

Other than that, I measured time and memory for creating the environment when the profile was already built (no more derivation to build):

`which time` -v ~/guix/pre-inst-env guix environment ocaml-dummy-package -- echo done

User time: 121.43s
System time: 2.28s
Maximum resident: 1803028kB (1.8 GB)

With a warning from GC:

Repeated allocation of very large block (approx. size 35606528)

Note that I get the same numbers with --no-grafts, so it might be a different issue.

"guix build" terminates quickly.

Le 23 juillet 2021 00:59:21 GMT-04:00, Sarah Morgensen <iskarian <at> mgsn.dev> a écrit :
>Hello,
>
>Ricardo Wurmus <rekado <at> elephly.net> writes:
>
>> With a recent version of Guix, “guix environment” will not 
>> terminate on its own, keeps the CPU busy, and gets killed when the 
>> system eventually runs out of memory.
>>
>> $ guix describe -f channels
>>
>> (list (channel
>>         (name 'guix)
>>         (url "/home/rekado/dev/gx/branches/master")
>>         (commit
>>           "685cfdec94e5e48c4ad28de53466a28dfc258edb")))
>>
>>
>> $ guix environment pigx-scrnaseq
>> [wait until it gets killed]
>
>I can reproduce this with pigx-scrnaseq as well a number of other
>packages (listed below).
>
>$ ./pre-inst-env guix describe -f channels
>(list (channel
>        (name 'guix)
>        (url "/home/sarah/guix")
>        (commit
>          "3217a04b0352c2dd13323257b369604eeabfccc3")))
>
>Does not complete within 5 minutes:
>package            # inputs  # transitive inputs
>                                 (from package-transitive-inputs)
>pigx-chipseq       48        338
>pigx-scrnaseq      41        321
>r-cellchat         34        110
>pigx-rnaseq        34        343
>pigx-bsseq         32        358
>pigx-sars-cov2-ww  25        261
>r-circus           16        134
>
>Does complete:
>r-chipseq          6         37     completes in >2m
>r-shortread        17        36     completes in >1m
>python-scanpy      25        113    completes in <15s
>
>I suspect it has something to do with the number of transitive inputs,
>because it is so prevalent with these R packages, which all use
>propagated inputs. However... python-scanpy succeeds in under 15
>seconds, and it has more transitive inputs than r-chipseq.
>
>Can we reproduce this with a large number of low-transitivity packages
>directly on the command line?
>
>>
>> The problem disappears when grafts are disabled:
>>
>> $ guix environment --no-grafts pigx-scrnaseq
>> $ [env] yay!
>
>--
>Sarah

[Message part 2 (text/html, inline)]

Previous Next

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