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

Previous Next

To reply to this bug, email your comments to 53369 AT debbugs.gnu.org.

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.