Segmentation fault on version v0.10.2 with no reason

[kerkmann]

Heyho, when I try to run cargo outdated on my project:
https://gitlab.com/kerkmann/clappy/-/tree/dcf932e26c4157d3a0598a54f35545ca8e1a051b
I just receive an segmentation fault. :(

The last lines of the debug log is:

...
[2022-02-21T23:38:51Z TRACE cargo::core::registry] 	serde_derive/^1.0/registry `crates-io`
[2022-02-21T23:38:51Z TRACE cargo::core::registry] 	nope, unlocked
[2022-02-21T23:38:51Z TRACE cargo::core::registry] 	thiserror/^1.0/registry `crates-io`
[2022-02-21T23:38:51Z TRACE cargo::core::registry] 	nope, unlocked
[2022-02-21T23:38:51Z TRACE cargo::core::registry] 	users/*//tmp/cargo-outdatedY6gRy3/users
[2022-02-21T23:38:51Z TRACE cargo::core::registry] 	nope, unlocked
[2022-02-21T23:38:51Z TRACE cargo::core::registry] 	uuid/^0.8/registry `crates-io`
[2022-02-21T23:38:51Z TRACE cargo::core::registry] 	nope, unlocked
[2022-02-21T23:38:51Z DEBUG cargo::core::resolver] initial activation: clappy v0.1.0 (/tmp/cargo-outdatedY6gRy3)
[2022-02-21T23:38:51Z TRACE cargo::core::resolver] activating clappy v0.1.0 (/tmp/cargo-outdatedY6gRy3)
[2022-02-21T23:38:51Z DEBUG cargo::core::registry] load/missing  registry `crates-io`
[2022-02-21T23:38:51Z DEBUG cargo::core::registry] loading source registry `crates-io`
[2022-02-21T23:38:51Z DEBUG cargo::sources::config] loading: registry `crates-io`
[2022-02-21T23:38:51Z TRACE cargo::core::source::source_id] loading SourceId; registry `crates-io`
[2022-02-21T23:38:51Z DEBUG cargo::sources::registry::remote] updating the index
[2022-02-21T23:38:51Z TRACE cargo::util::config] get cv ConfigKey { env: "CARGO_HTTP", parts: [("http", 5)] }
[2022-02-21T23:38:51Z TRACE cargo::sources::registry::remote] opened a repo without a lock
[2022-02-21T23:38:51Z DEBUG cargo::sources::git::utils] attempting GitHub fast path for https://api.github.com/repos/rust-lang/crates.io-index/commits/HEAD
[2022-02-21T23:38:51Z DEBUG cargo::sources::git::utils] skipping gc as there's only 74 pack files
[2022-02-21T23:38:51Z DEBUG cargo::sources::git::utils] doing a fetch for https://github.com/rust-lang/crates.io-index
[2022-02-21T23:38:51Z DEBUG cargo::sources::git::utils] initiating fetch of ["HEAD:refs/remotes/origin/HEAD"] from https://github.com/rust-lang/crates.io-index
[1]    161993 segmentation fault (core dumped)  RUST_LOG=trace cargo outdated

Appended the entire log. :)

debug.log

[stefan0xC]

I also ran into this issue. This is probably an incompatibility in git2-rs with the libgit2 system library (which will be addressed in the next release). In my case the segmentation fault happened because I had libgit2 1.4.1 installed. Rebuilding cargo-outdated without libgit2 or after downgrading libgit2 to 1.3 solved this issue for me.

• release tag rust-lang/git2-rs#810

It should also be possible to enable the vendored-libgit2 feature of git2-rs instead of relying on it being compatible (and always up to date) with an external library?

[kerkmann]

Can confirm what @stefan0xC wrote. :)

I downgraded libgit2 to 1.3.0 and now it's working! :)

Thanks @stefan0xC !

[stefan0xC]

There has been a new git2-rs release shortly after I linked the issue that is compatible with libgit2 1.4.1 so downgrading is not necessary anymore. However, you'd need to run cargo install cargo-outdated without the --locked flag to use the newest version of the crate.

[kerkmann]

You are right, after upgrading to 1.4.1 and installing the unlocked cargo-outdated version, it's now working. :)

[kbknapp]

Can you try again with v0.11.0?

[dbrgn]

When I run cargo install --locked cargo-outdated on my Arch Linux system with libgit2 1.4.2-1, I still get a segfault.

$ cargo outdated --version
cargo-outdated 0.11.0

$ ldd ~/.cargo/bin/cargo-outdated
	linux-vdso.so.1 (0x00007ffc770f6000)
	libgit2.so.1.4 => /usr/lib/libgit2.so.1.4 (0x00007fc870a44000)
	libz.so.1 => /usr/lib/libz.so.1 (0x00007fc870a2a000)
	libcurl.so.4 => /usr/lib/libcurl.so.4 (0x00007fc870987000)
	libssl.so.1.1 => /usr/lib/libssl.so.1.1 (0x00007fc8708f5000)
	libcrypto.so.1.1 => /usr/lib/libcrypto.so.1.1 (0x00007fc870614000)
	libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007fc8705f9000)
	libm.so.6 => /usr/lib/libm.so.6 (0x00007fc87050f000)
	libc.so.6 => /usr/lib/libc.so.6 (0x00007fc870305000)
	libhttp_parser.so.2.9 => /usr/lib/libhttp_parser.so.2.9 (0x00007fc8702f9000)
	libpcre.so.1 => /usr/lib/libpcre.so.1 (0x00007fc870282000)
	libssh2.so.1 => /usr/lib/libssh2.so.1 (0x00007fc870241000)
	libnghttp2.so.14 => /usr/lib/libnghttp2.so.14 (0x00007fc87021a000)
	libidn2.so.0 => /usr/lib/libidn2.so.0 (0x00007fc8701f6000)
	libpsl.so.5 => /usr/lib/libpsl.so.5 (0x00007fc8701e3000)
	libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x00007fc87018e000)
	libzstd.so.1 => /usr/lib/libzstd.so.1 (0x00007fc8700df000)
	libbrotlidec.so.1 => /usr/lib/libbrotlidec.so.1 (0x00007fc8700d1000)
	libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007fc8700cc000)
	libdl.so.2 => /usr/lib/libdl.so.2 (0x00007fc8700c5000)
	/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007fc87118c000)
	libunistring.so.2 => /usr/lib/libunistring.so.2 (0x00007fc86ff43000)
	libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x00007fc86fe5c000)
	libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x00007fc86fe2b000)
	libcom_err.so.2 => /usr/lib/libcom_err.so.2 (0x00007fc86fe25000)
	libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0x00007fc86fe13000)
	libkeyutils.so.1 => /usr/lib/libkeyutils.so.1 (0x00007fc86fe0c000)
	libresolv.so.2 => /usr/lib/libresolv.so.2 (0x00007fc86fdf8000)
	libbrotlicommon.so.1 => /usr/lib/libbrotlicommon.so.1 (0x00007fc86fdd5000)

$ coredumpctl dump
...
       Message: Process 36267 (cargo-outdated) of user 1000 dumped core.

                Module /home/danilo/.cargo/bin/cargo-outdated with build-id d1a2be05d5d8a25c214cda7279074a8f8c19fc52
                Module linux-vdso.so.1 with build-id 351b3072a0555d16594b35d390715fc2f77d54e3
                Module libnss_resolve.so.2 with build-id 414afec983f18e39bd181d4b1ae3de44775bb13b
                Module libcap.so.2 with build-id eb6dae97527fc89dbb0d5bb581a15acd02ae9f56
                Module librt.so.1 with build-id 4761858b348db8303e872e515aa8d56c046c921c
                Module libnss_mymachines.so.2 with build-id 3b659875bdb194d71d8660f90b86783b38e86dcc
                Module libbrotlicommon.so.1 with build-id a4ba3f4b4571c8272343b621da812a6e24a202a7
                Module libresolv.so.2 with build-id 46ffdf3d477a170314060c26927470d7399bc900
                Module libkeyutils.so.1 with build-id ac405ddd17be10ce538da3211415ee50c8f8df79
                Module libkrb5support.so.0 with build-id adf65240a4d2aba772d7a0772b4d015469934113
                Module libcom_err.so.2 with build-id 358b783c9b3d12ba8248519ea2e7f3da4c4e0297
                Module libk5crypto.so.3 with build-id eb8220b8f36675aac769450be4cb6bb7f97ec38a
                Module libkrb5.so.3 with build-id 72d26767c5cb1097db75a5f5bff88860233c902b
                Module libunistring.so.2 with build-id 015ac6d6bcb60b7d8bea31a80d1941b06e8636ab
                Module ld-linux-x86-64.so.2 with build-id c09c6f50f6bcec73c64a0b4be77eadb8f7202410
                Module libdl.so.2 with build-id bb9bd2657bfba9f60bd34d2050cc63a7eb024bc4
                Module libpthread.so.0 with build-id 7fa8b52fae071a370ba4ca32bf9490a30aff31c4
                Module libbrotlidec.so.1 with build-id 45defc036e918e0140a72f1fbce6e7692d38241d
                Module libzstd.so.1 with build-id 72f3511cba7db578f6a2647925f35664da6c838b
                Module libgssapi_krb5.so.2 with build-id e6e098ad51ce7bdd3dbe902d7b0f69a90f8a9e08
                Module libpsl.so.5 with build-id 0229a201aaf5652186c9fdc192ebe52baf19d7f1
                Module libidn2.so.0 with build-id 1ce2b50ad9f9821c2c629b521cf5a3c99593d332
                Module libnghttp2.so.14 with build-id f2738fead8e6593084b4fb8756f460aa8cf5535a
                Module libssh2.so.1 with build-id a4adfe44cc7ebd295b3b783361acc3dcfcea1d50
                Module libpcre.so.1 with build-id 845483dd0acba86de9f0313102bebbaf3ce52767
                Module libhttp_parser.so.2.9 with build-id a7b44d494c1e52a62efd933ab2f7b37dae9482e1
                Module libc.so.6 with build-id 85766e9d8458b16e9c7ce6e07c712c02b8471dbc
                Module libm.so.6 with build-id 596b63a006a4386dcab30912d2b54a7a61827b07
                Module libgcc_s.so.1 with build-id 5d817452a709ca3a213341555ddcf446ecee37fa
                Module libcrypto.so.1.1 with build-id 4c926b672d97886b123e03a008387aecf0786de4
                Module libssl.so.1.1 with build-id 1024424ab33a3767da03f4fdb1fc1b02479f160f
                Module libcurl.so.4 with build-id d4dec3d9f8c789ec28d441f2a3f73d532809e6ef
                Module libz.so.1 with build-id 0c1459c56513efd5d53eb3868290e9afee6a6a26
                Module libgit2.so.1.4 with build-id c0d036dddc2044070404f7ae5e65b4464588f4ca
                Stack trace of thread 36267:
                #0  0x00007ffb67635fc0 n/a (libgit2.so.1.4 + 0xa3fc0)
                #1  0x00007ffb67637aae git_remote_fetch (libgit2.so.1.4 + 0xa5aae)
                #2  0x000055fb5f9b7c20 n/a (/home/danilo/.cargo/bin/cargo-outdated + 0x246c20)
                ELF object binary architecture: AMD x86-64

[dbrgn]

I think the reason for this is that the cargo package itself depended on an older version of the git2 crate. This was fixed here:

rust-lang/cargo@dd701a1

The other dependency which depends on libgit2 is git2-curl. Indeed, if I bump both dependencies:

diff --git a/Cargo.toml b/Cargo.toml
index 2ce0c82..5b93884 100644
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -29,9 +29,9 @@ name = "cargo-outdated"

 [dependencies]
 anyhow = "1.0"
-cargo = "0.60.0"
+cargo = { git = "https://github.com/rust-lang/cargo/" }
 env_logger = "0.9.0"
-git2-curl = "0.14.0"
+git2-curl = "0.15.0"
 semver = "1.0.0"
 serde = {version="1.0.114", features = ["derive"]}
 serde_derive = "1.0.114"

Then cargo-outdated works again.

I guess we'll have to wait for upstream releases. (This is quite a PITA, as it also affects other cargo plugins like cargo-crev.)

[kpcyrd]

Does somebody know what's the relevant commit/change in git2 0.13 -> 0.14, git2-curl 0.14 -> 0.15.0, libgit2-sys 0.12 -> 0.13? Can this be backported?

[kerkmann]

Can confirm, it's still broken with cargo install cargo-outdated and cargo install --locked cargo-outdated. :)

[ArekPiekarz]

It's been over a month and it's still a problem on Manjaro. Is there a way to use cargo-outdated without getting a segfault?

[dbrgn]

@ArekPiekarz see rust-lang/cargo#10446

[niklasf]

A possible workaround appears to be cargo update --dry-run && cargo outdated

Meanwhile another affected project, cargo-edit, has now been released with vendored libgit2.

[ArekPiekarz]

@niklasf Thanks for the workaround! I must ask, why does one command affect the way another command behaves? Does it alter the environment in some way?

[orhun]

@niklasf Thanks for the workaround! I must ask, why does one command affect the way another command behaves? Does it alter the environment in some way?

It is because running cargo update updates the registry index (~/.cargo/registry/index) so that cargo-outdated can skip this step (which is the point of failure due to libgit2).