emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#37449: closed (Bug when using non-trivial inferior


From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#37449: closed (Bug when using non-trivial inferiors/channel setup)
Date: Sun, 06 Oct 2019 12:32:02 +0000

Your message dated Sun, 06 Oct 2019 14:31:07 +0200
with message-id <address@hidden>
and subject line Re: bug#37449: Bug when using non-trivial inferiors/channel 
setup
has caused the debbugs.gnu.org bug report #37449,
regarding Bug when using non-trivial inferiors/channel setup
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden.)


-- 
37449: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=37449
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: Bug when using non-trivial inferiors/channel setup Date: Wed, 18 Sep 2019 16:08:45 +0000
Hi all,

This is a followup to some discussion between rekado, civodul, and I on IRC (see
end of email for transcript). There is a curious bug that happens when using
non-trivial inferiors/channels setup that triggers an error with vague output,
something like:

```
building path(s) `/gnu/store/myrl5p8fy3qhpdv7376sak8wmhdsrl5f-profile'
Backtrace:
           2 (primitive-load "/home/dongcarl/.config/guix/current/bi…")
In guix/ui.scm:
  1692:12  1 (run-guix-command _ . _)
   623:13  0 (_ srfi-34 #<inferior-object #<condition &store-protoco…>)

guix/ui.scm:623:13: Throw to key `wrong-type-arg' with args 
`("condition-has-type?" "Wrong type argument")'.
```

Both rekado and I have ran into this problem. Rekado ran into this problem when
using inferiors with more than one channel, and I ran into this problem when
using an inferior with a channel that has a .guix-channel file specifying a
'guix channel. A detail here is that it only triggers, but triggers reliably,
for certain packages in our manifests, with is quite odd.

I've attached the IRC conversation below for convenience.


Cheers,
Carl Dong
address@hidden
"I fight for the users"


```
<dongcarl> question about general Guix debugging... I'm building a manifest, 
and I see this: https://pastebin.com/JjpEjxaG
<rekado> dongcarl: I’ve bumped into this very same bug just a day ago
<dongcarl> It's hard to know where to look... :-/
<rekado> I’m not sure what’s going on here.
<dongcarl> rekado: REALLY?!
<rekado> a user at the institute, actually
<dongcarl> Where did you bump into it?
<dongcarl> Sounds like it needs to be fixed
<rekado> we’re using inferiors with more than one channel
<dongcarl> rekado: Right exactly!
<rekado> the user managed to avoid the problem for now by pinning the 'guix 
channel to commit 2f43e5db1c36ec93a80ed1e3cbe763a8d64adcb5.
<rekado> this sounds like a meta error, really
<dongcarl> Hmm... Well let me describe what I have
<rekado> there’s something triggering an error in an expression that is wrapped 
in “call-with-error-handling”
<dongcarl> Perhaps the info will be helpful for debugging
<rekado> but the error is not a condition, so the guard fails
<rekado> or something like that
<dongcarl> my manifest only has one channel in it, called `'bitcoin-guix`, and 
that channel's repo has a `.guix-channel` file that specifies a `'guix` channel
<rekado> actually, the error says that it got a “condition” but wrapped inside 
an “inferior-object”
<rekado> that’s the problem, I think
<rekado> it should just be a condition.
<rekado> the fact that we’re using an inferior results in a wrapped value
<rekado> it should be unwrapped before raising the condition.
<dongcarl> another piece of info, this is only happens for one of the packages 
in the manifest (I narrowed it down), all others are fine
— dongcarl reading
<rekado> same here
<rekado> it happened for python-scanpy
<rekado> others were ine
<rekado> *fine
<rekado> I’m guessing that this may be related to sexp->object in 
read-repl-response in guix/inferior.scm
<dongcarl> rekado: Huh...
<rekado> conditions don’t have a self-quoting sexp representation
<rekado> so they end up being wrapped in inferior-object
<dongcarl> rekado: Is this easy to fix?
<rekado> I don’t know.
<dongcarl> rekado: what should I look for in guix/inferior.scm? I can take a 
look
<rekado> read-repl-response expects to read either (values …) or (exception …) 
from the port
<rekado> I don’t know what a condition value would look like
<rekado> we probably need to a) make sure that conditions are serialized 
properly and b) handle them in read-repl-response.
<dongcarl> rekado: Why does this error only happen for _some_ objects and but 
not all?
<rekado> I don’t know
<rekado> we don’t even see the actual error.
<rekado> I guess (a) needs to be done in guix/repl.scm in send-repl-response
<rekado> the problem seems to be that there we only catch plain exceptions, but 
not conditions
— dongcarl needs to read up on exceptions and conditions
<rekado> (error 'foo) is an exception
<rekado> conditions are more complex and are defined in srfi-35
<rekado> conditions have proper types whereas plain errors really only have a 
key and optional arguments
<rekado> errors can be caught with (catch 'the-key …) or (catch #t …) for any 
error
<civodul> dongcarl: could you paste the error on, say, paste.debian.net? 
(patebin.com cannot be accessed over Tor)
<dongcarl> civodul: Yes, would love to, one second
<dongcarl> rekado: Ah the type distinction is good to know
<civodul> debugging exceptions from an inferior is... inconvenient
<dongcarl> civodul: http://paste.debian.net/hidden/03c69d6b/
<dongcarl> civodul: agreed
<dongcarl> I was actually thinking that perhaps inferiors can be a first-class 
`guix` cli construct... Not sure if that's possible
<dongcarl> As in, run the CLI as if `guix` was at this commit
<dongcarl> Maybe that's dumb :man-shrugging:
<dongcarl> gunna be back online in 30 mins if you guys need more logs or wtv
<civodul> dongcarl: oh, i see
<civodul> actually i don't see that much, mostly ellipses
<civodul> ah the re-throw for SRFI-34/35 is interesting
<civodul> it cannot work
<civodul> we should maybe serialize &store-error conditions over the wire
```



--- End Message ---
--- Begin Message --- Subject: Re: bug#37449: Bug when using non-trivial inferiors/channel setup Date: Sun, 06 Oct 2019 14:31:07 +0200 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)
Hi Carl,

Ludovic Courtès <address@hidden> skribis:

> Carl Dong <address@hidden> skribis:
>
>> building path(s) `/gnu/store/myrl5p8fy3qhpdv7376sak8wmhdsrl5f-profile'
>> Backtrace:
>>            2 (primitive-load "/home/dongcarl/.config/guix/current/bi…")
>> In guix/ui.scm:
>>   1692:12  1 (run-guix-command _ . _)
>>    623:13  0 (_ srfi-34 #<inferior-object #<condition &store-protoco…>)
>>
>> guix/ui.scm:623:13: Throw to key `wrong-type-arg' with args 
>> `("condition-has-type?" "Wrong type argument")'.
>
> With commit e773b3918f51231f28363905b64ca164b172b47a, you should be able
> to see the actual error condition.
>
>>From there, we should have clues as to why some inferior packages in
> your manifest are problematic.

[...]

> Actually commit 71507435225f10d8d944ba183cbcc77ef953e0e5.

IIRC you mentioned on IRC that the problem is solved, so I’m closing
this bug.  Please reopen it if anything’s wrong!

Thanks,
Ludo’.


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]