Skip to content
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 install never ends on nightly and linux #6384

Closed
ghusse opened this issue Dec 6, 2018 · 10 comments
Closed

cargo install never ends on nightly and linux #6384

ghusse opened this issue Dec 6, 2018 · 10 comments

Comments

@ghusse
Copy link

ghusse commented Dec 6, 2018

Problem
I'm trying to use some packages that need nightly.

Running cargo install xxxx works correctly
Running cargo +nightly install racer (for instance, but I have the same issue for other packages) never ends. The installation is stuck in "installing".

Steps

  1. rustup toolchain add nightly
  2. cargo +nightly install racer

Notes
I installed rust/nightly on windows a few days ago, and did not have this issue

Output of cargo version:
cargo 1.30.0 (a1a4ad372 2018-11-02)

@ehuss
Copy link
Contributor

ehuss commented Dec 6, 2018

cargo 1.30.0 (a1a4ad3 2018-11-02)

This version is quite old. Can you try with a newer version (current nightly is 1.32 2018-12-05)? You may want to check your PATH is set up correctly and you are using the correct cargo/rustc as installed by rustup.

@ghusse
Copy link
Author

ghusse commented Dec 7, 2018

It seems to be an issue with rustc in nightly.

rustc --version

Never ends, with nightly on my machine. On stable it works as expected.

@ghusse
Copy link
Author

ghusse commented Dec 7, 2018

I upgraded everything, rustc --version works correctly, rustc +nightly --version is stuck.

I should have posted the result of cargo +nightly --version which is now

cargo 1.32.0-nightly (5e85ba14a 2018-12-02)

@alexcrichton
Copy link
Member

@ghusse out of curiosity, can you attach a debugger and try to get a stack trace of the stuck process?

@ghusse
Copy link
Author

ghusse commented Dec 10, 2018

@ghusse out of curiosity, can you attach a debugger and try to get a stack trace of the stuck process?

If you can indicate me how to do that, I'll be pleased to execute :)

@alexcrichton
Copy link
Member

Oh sure, you should be able to:

  • First, execute rustc and wait for it to hagn
  • Next, figure out the pid for rustc (I used ps typically for that)
  • Execute gdb -p $PID, this should attach GDB to the process
  • Execute thread apply all bt

And hopefully that's enough output to gist!

@ehuss
Copy link
Contributor

ehuss commented Dec 12, 2018

@ghusse Do you have ESET antivirus installed (or any security software)?

@ghusse
Copy link
Author

ghusse commented Dec 17, 2018

@ghusse Do you have ESET antivirus installed (or any security software)?

@ehuss Yes, I have ESET antivirus. I tried to deactivate its protection to see if it works but that did not do anything.

@alexcrichton I followed the steps, but I don't see any output for the command thread apply all bt. Am I missing anything?

@ehuss
Copy link
Contributor

ehuss commented Dec 17, 2018

Ah, in that case, I'm going to close in favor of the upstream issue rust-lang/rust#56736 as it is a problem with how rust is built. You can follow that for more updates. I think we understand what's wrong. It's an unfortunate interaction between ESET, jemalloc 5, and how rust is built. At this time I don't know of a good fix, though there are some ideas listed on that issue.

@ehuss ehuss closed this as completed Dec 17, 2018
@ghusse
Copy link
Author

ghusse commented Dec 19, 2018

Thanks for the explanations.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants