-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cargo segfaults on NFS with git dependencies #3042
Comments
Oh dear, this sounds bad! Could you try running the test suite of git2-rs and see if there's a smaller test case exhibiting this assertion? |
Nope. In the 0.4.4 and the git head version of git2-rs, all tests pass. I can't build the 0.4 version because of an unresolved import error. However, I did find a test failure in libgit2 that might be related. |
Definitely sounds fishy! Perhaps you could try building a debug version of Cargo and stepping through the faulting function? |
When I build a debug version of Cargo, gdb can't understand the core file. However, gdb has no problems with a core file made from a release version of gdb. Odd. But I did manage to get a stack trace from the debug version by setting a breakpoint at the assertion that fails. Unfortunately, the bug is a refcount mismatch in a structure deep within the bowels of libgit2. As such, it's beyond my ability to debug. I'm afraid that it's going to take a libgit2 expert.
|
We are falling a bit behind on libgit2's latest version at this point, so this could very well be a bug that's been fixed in master. Unfortunately it won't be trivial to update, so it may be difficult to test out |
FYI, libgit2 just fixed an issue that may be related: libgit2/libgit2#3931 |
Pull in the next major version of the `openssl` crate as well as the `git2` crate which is targeted at helping to fix rust-lang#3042
Update: FreeBSD is not the culprit; NFS is. I have a FreeBSD server 10.3, a FreeBSD 11.0 client, and an Ubuntu 16.10 client. All three systems can use cargo with git dependencies when CARGO_HOME points to a local file system. However, both clients get the same segfault when CARGO_HOME points to an NFSv4 mount, served by the FreeBSD 10.3 server. |
Interesting! If you can narrow down with the segfault is we can hopefully report upstream to libgit2 |
Here's a stack trace from the latest master branch of cargo. It's failing with SIGABRT now instead of SIGSEGV. And BTW, it fails on NFSv3 as well as NFSv4. Am I really the first person to use cargo with CARGOHOME on an NFS share?
|
Thanks for the trace @asomers! Could you also clarify what version of Cargo that was collected with? |
I've filed an upstream bug as well at libgit2/libgit2#4023 to hopefully get to the bottom of this. |
@alexcrichton I've seen the failure with multiple versions of cargo, most recently f33b7b0 . |
It's been > 7 years since I filed this bug, and I don't recall seeing it for a very long time. I still use CARGO_HOME on NFS, and it works these days. I'm going the close the bug. |
On FreeBSD, running "cargo build" on any repo with a git dependency specified in Cargo.toml will segfault. It doesn't matter if the dependency is on github or uses a file:/// url.
Here is the backtrace from the core file:
Using Cargo from git, the result is an assertion error instead of a segfault.
In this case, the core file contains no intelligible stack trace.
My Cargo.toml file contains the following lines. However, every other variation I tried produces the same result, as long as it involves git.
The text was updated successfully, but these errors were encountered: