GNU bug report logs - #61284
[rust] Segfault when trying to download dependencies using Cargo

Previous Next

Package: guix;

Reported by: Albin Otterhäll <albin <at> a12l.xyz>

Date: Sun, 5 Feb 2023 00:29:01 UTC

Severity: normal

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

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

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-guix <at> gnu.org:
bug#61284; Package guix. (Sun, 05 Feb 2023 00:29:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to Albin Otterhäll <albin <at> a12l.xyz>:
New bug report received and forwarded. Copy sent to bug-guix <at> gnu.org. (Sun, 05 Feb 2023 00:29:02 GMT) Full text and rfc822 format available.

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

From: Albin Otterhäll <albin <at> a12l.xyz>
To: "bug-guix <at> gnu.org" <bug-guix <at> gnu.org>
Subject: [rust] Segfault when trying to download dependencies using Cargo
Date: Sun, 05 Feb 2023 00:28:25 +0000
# Segfault when trying to build Rust binary using cargo and a dependency

## Description

As soon as I add a dependency to `Cargo.toml` I get a segfault when I in some way try to build the binary.

## Expected behavior

When running `cargo build` after having added a dependency on `rand = "0.8.3"` in the example below Cargo should download the `rand` package (`rust-rand` in Guix).

## Actual behavior

The build process halts with a segmentation fault.

### Steps to reproduce

Create an environment with the command `guix shell --manifest=manifest.scm` and there `manifest.scm` contains

```
(specifications->manifest (list "rust"
                                "rust-analyzer"
                                "rust-cargo"))
```

and then run the commands

$ cargo new mve
Created binary (application) `mve` package

$ cd mve/

mve $ cargo build
   Compiling mve v0.1.0 (/home/a12l/Long-Term/TRPL/mve)
    Finished dev [unoptimized + debuginfo] target(s) in 0.56s

mve $ echo 'rand = "0.8.3"' >> Cargo.toml

mve $ cargo build
    Updating crates.io index
Segmentation fault (core dumped)

## My system

I'm running Guix on a NixOS 22.11 machine, by having added `https://github.com/foo-dogsquared/nix-overlay-guix` to my system configuration.

Thanks!
--
Albin Otterhäll




Information forwarded to bug-guix <at> gnu.org:
bug#61284; Package guix. (Sat, 02 Aug 2025 06:27:05 GMT) Full text and rfc822 format available.

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

From: Johannes Nix <jnxx <at> posteo.net>
To: 61284 <at> debbugs.gnu.org
Subject: [rust] Segfault when trying to download dependencies using Cargo
Date: Fri, 01 Aug 2025 20:53:18 +0000
> 
> mve $ cargo build
>     Updating crates.io index
> Segmentation fault (core dumped)

I am very new to Guix System - just installed it this
morning.

However, I seem to have had the same issue today,
and apparently found a workaroung.

I tried to run it under strace and it indicated that
apparently it segfaults when it tries to find and
parse several git config files, especially
$HOME/.gitconfig .

Found on the web multiple suggestions that these config
files might be faulty - but I could not find any fault
in my file.

Instead, I found a workaround that might help you:

I set the environment variable

export CARGO_NET_GIT_FETCH_WITH_CLI=true


which changes the way in which cargo uses git.
With this, it works for me.

On top of that, I had further errors with cargo 
which might or might not be unrelated, when doing a
"cargo build". There it looks like rust-cargo and
rustc-1.82.0 are somehow out of sync, leading cargo to
query rustc for a profile option which is not supported by
rustc (print-split-debuginfo). Roughly, it is failing
with this error message, which relates to a much older
version:

https://github.com/kbknapp/cargo-outdated/issues/355

But, *both* errors only happen on my new Guix System
installation, not in Guix package manager on top
of Debian 12 with the same rust-cargo version.


I'll make a separate bug tracking entry for that one
(I need to capture the output and check the version
numbers again).

I suspicion I have is that actually one of rustc or
cargo might actually refer to an out-dated version,
causing a mismatch. Perhaps because of an ci glitch.

Perhaps it is informative to check the installed
version with "cargo -vV" ? One important point
is surely to not mix up manually installed binaries
and the Guix-installed ones... but I am still new
and confused by all this.

--

Johannes Nix





This bug report was last modified 7 days ago.

Previous Next


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