Re: Channel details of profile generation

[Phil <phil@beadling.co.uk>]

Hi,

Thanks - I think the original question is answered now - however I am
curious over why only I can reproduce issues with the incorrect use of
'guix pull'.  It's tempting to say it's just undefined behaviour and
move on with my life, but I've done a bit more digging....


* This appears to have nothing to do with defined channels - I have now
  removed the channel.scm completely and can still reproduce the
  problem.
* The problem occurs whenever 'guix pull -l' is called incorrectly on a
  standard profile which has > 1 generation in it.
* There are 2 outcomes I've observed so far - a) a backtrace is given,
  or b) the command halts for at least 27 minutes in what appears to be
  a frozen state (but could just be very slow).


When I sent my first e-mail about this issue I showed the backtrace as
per a) above.  I have now tried the experiment on a completely different
server and I can reproduce a), that is, I can create a profile
containing 1 package in 1st generation, and use 'guix pull -l' OK.

Then if I install another package for the 2nd generation I get the
backtrace occurring (see below).

However - I cannot reproduce b) myself on another machine, that is, I cannot
reproduce the freezing of 'guix pull -l' apart from on one specific
server.  Instead I get the backtrace.

Perhaps the problem is specific to running Guix on Ubuntu 18.04 as all
my servers run this?



ubuntu@foobar:~$ guix pull -p /tmp/test-profile-only-guix-3 -l
\Generation 1   Jan 12 2021 18:51:57\
  python 3.8.2
\Generation 2   Jan 12 2021 18:52:19\   (current)
  python 3.8.2
  python-numpy 1.17.3
Backtrace:
          11 (primitive-load "/home/ubuntu/.config/guix/curre…")
In guix/ui.scm:
  2154:12 10 (run-guix-command _ . _)
In ice-9/boot-9.scm:
  1736:10  9 (with-exception-handler _ _ #:unwind? _ # _)
  1731:15  8 (with-exception-handler #<procedure 7f757a497390 at ic…> …)
  1731:15  7 (with-exception-handler #<procedure 7f757a497360 at ic…> …)
  1731:15  6 (with-exception-handler #<procedure 7f757a49f9c0 at ic…> …)
In guix/scripts/pull.scm:
    636:4  5 (_)
In guix/memoization.scm:
    100:0  4 (_ #<hash-table 7f757a499fa0 0/31> "/tmp/test-profile-…" …)
In guix/scripts/pull.scm:
   538:21  3 (_)
In guix/inferior.scm:
    256:2  2 (inferior-available-packages #f)
   251:13  1 (send-inferior-request (defined? (quote #)) #f)
In ice-9/boot-9.scm:
  1669:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1669:16: In procedure raise-exception:
In procedure struct-vtable: Wrong type argument in position 1 (expecting struct): #f



A few more comments inline.


zimoun writes:

> yet.  Maybe an option ’--export-manifest’ is coming… ;-)
>
> http://logs.guix.gnu.org/guix-hpc/2021-01-11.log

Cool - thanks for pointer.

> Do you mean issues when replicating my example with only the channels
> guix and guix-science?

I've actually reduced this down to no channel.scm file (so only default
guix channel), and picking 2 packages in guix - eg python and python-numpy.

>
> By hanging, do you mean “you were not enough patient“? or “after several
> minutes” (10-20min), it was not finished yet?

I've waited up to 27 mins with no change.

> Thank for the details.  Well, does it fail or is it slow?

When run with only 1 generation the command returns immediately, so if
it is slow, then there's a marked degrading of performance from
generation 1 -> 2.  My guess is it's hanging not slow - but it is a
guess.


>
>
>> I'm running out of steam a bit here but both this error in ui.scm@2154
>> and the original backtrace I posted ui.scm@2127 come from the
>> run-guix-command function on attempting a primitive-load of, I assume,
>> the current guix script.
>
> The bracktrace is a fail.  But I am not able to reproduce.
> For your experiment, I do not know if it is failure or slowness.

To be clear the backtrace only failed once I killed the process (after
waiting several minutes as discussed above).  My hope was by killing it
the strace might show something illuminating.