GNU bug report logs - #53369
guix pull command fails on a torified bash shell

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 53369 in the body.
You can then email your comments to 53369 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Girish <girishm <at> posteo.net>
To: bug-guix <at> gnu.org
Subject: guix pull command fails on a torified bash shell
Date: Wed, 19 Jan 2022 15:47:49 +0000

When I run `guix pull` command the following error is generated:

In procedure scm_lreadr: #<unknown port>:16:144: Unknown # object: #\<

Further invocations to `guix <option>` produces Segmentation fault.

However, the following command still works:

`/run/current-system/profile/bin/guix <option>`

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

From: Maxime Devos <maximedevos <at> telenet.be>
To: Girish <girishm <at> posteo.net>, 53369 <at> debbugs.gnu.org
Subject: Re: bug#53369: guix pull command fails on a torified bash shell
Date: Thu, 20 Jan 2022 11:04:40 +0100

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

Girish schreef op wo 19-01-2022 om 15:47 [+0000]:
> When I run `guix pull` command the following error is generated:
> 
> In procedure scm_lreadr: #<unknown port>:16:144: Unknown # object: #\<

Does it only print that, or is there also some backtrace?
To investigate the issue, the backtrace would be useful.

Greetings
Maxime.

[signature.asc (application/pgp-signature, inline)]

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

From: Maxime Devos <maximedevos <at> telenet.be>
To: Girish <girishm <at> posteo.net>
Cc: 53369 <at> debbugs.gnu.org
Subject: Re: bug#53369: guix pull command fails on a torified bash shell
Date: Fri, 21 Jan 2022 10:49:03 +0100

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

[Please keep debbugs in CC or To]

>  guix pull command fails on a torified bash shell

Does it also happen outside a torified shell?
torify sets LD_PRELOAD, which is rather fragile ...
E.g., if torify comes from a foreign distro and guix comes from guix,
then quite possibly there's some kind of binary incompatibility in-
between.

Anyway, torify probably doesn't do what you want it to do, because the
substitutes and most source code is downloaded through the guix daemon,
which is probably not torified.  I recommend setting the 'http_proxy'
and 'https_proxy' environment variables instead (for the daemon and
user), although there might be some situations in which they are not
respected.

Girish schreef op vr 21-01-2022 om 08:54 [+0000]:
> Actually, it prints 'Segmentation fault' when I run `guix pull`.
Maybe look in 'dmesg' to see if there was an out-of-memory situation.

> When I run `/run/current-system/profile/bin/guix pull` it runs fine
> but ends with following exception:
> ice-9/boot-9.scm:1669:16: In procedure raise-exception:
> In procedure scm_lreadr: #<unknown port>:16:144: Unknown # object #\<
> I'm not sure whether the above details are enough.
> How can I view the complete backtrace for `guix`?

Normally, the backtrace is printed automatically, looking like
something along these lines:

> Backtrace:
> In ice-9/boot-9.scm:
>   1752:10  6 (with-exception-handler _ _ #:unwind? _ # _)
> In unknown file:
>            5 (apply-smob/0 #<thunk 7f1cc976d080>)
> In ice-9/boot-9.scm:
>     724:2  4 (call-with-prompt _ _ #<procedure default-prompt-
> handle…>)
> In ice-9/eval.scm:
>     619:8  3 (_ #(#(#<directory (guile-user) 7f1cc9773c80>)))
> In ice-9/boot-9.scm:
>    2835:4  2 (save-module-excursion _)
>   4380:12  1 (_)
> In $HOME/source-code/rw/guix/q.scm:
>       1:1  0 (_)
> 
> $HOME/source-code/rw/guix/q.scm:1:1: Unbound variable: foo

Basically, the backtrace starts at the 'Backtrace:' line.
But it seems like it was not printed in your case ...

Greetings
Maxime.

[signature.asc (application/pgp-signature, inline)]

Previous Next

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