Skip to content

cargo panic on thirdparty tools install #3824

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

Closed
kpy3 opened this issue Mar 12, 2017 · 5 comments
Closed

cargo panic on thirdparty tools install #3824

kpy3 opened this issue Mar 12, 2017 · 5 comments

Comments

@kpy3
Copy link

kpy3 commented Mar 12, 2017

Hi there,

Just updated to latest nightly snapshot

% rustup update
info: syncing channel updates for 'stable-x86_64-apple-darwin'
info: syncing channel updates for 'nightly-x86_64-apple-darwin'
info: checking for self-updates

   stable-x86_64-apple-darwin unchanged - rustc 1.15.1 (021bd294c 2017-02-08)
  nightly-x86_64-apple-darwin unchanged - rustc 1.17.0-nightly (e4eb964dd 2017-03-11)

and try to reinstall clippy:

% RUST_BACKTRACE=full cargo +nightly install clippy
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', src/libcore/option.rs:323
stack backtrace:
   0:        0x10318d293 - std::sys::imp::backtrace::tracing::imp::unwind_backtrace::h7b906ec435ded35c
   1:        0x1031941b4 - std::panicking::default_hook::{{closure}}::h44d92332f38028b9
   2:        0x103193dcd - std::panicking::default_hook::ha8486ead32221b33
   3:        0x103196917 - std::panicking::rust_panic_with_hook::hdbc3bba6a9dc0bb9
   4:        0x1031967b4 - std::panicking::begin_panic::ha249c774b9bf96e1
   5:        0x103196722 - std::panicking::begin_panic_fmt::ha197daaf02a649ab
   6:        0x103196687 - rust_begin_unwind
   7:        0x1031be260 - core::panicking::panic_fmt::h7414cb5ce71ea361
   8:        0x1031be164 - core::panicking::panic::hcbe9ad6a1a4f4afd
   9:        0x102edc141 - cargo::version::h514bf8eb132b821a
  10:        0x102e6df43 - cargo::ops::registry::http_handle::ha92c0787d2d2696d
  11:        0x102e98699 - <cargo::sources::registry::remote::RemoteRegistry<'cfg> as cargo::sources::registry::RegistryData>::update_index::h7644a3bd96fbd546
  12:        0x102e9dec7 - cargo::sources::registry::RegistrySource::do_update::hbe49ec8677ca7a66
  13:        0x102e9e116 - <cargo::sources::registry::RegistrySource<'cfg> as cargo::core::source::Source>::update::h155c3dfa80eb0bd1
  14:        0x102df5002 - cargo::ops::cargo_install::install::h8745e233b79231fd
  15:        0x102c92a42 - cargo::try_execute_builtin_command::h6c891951512d460a
  16:        0x102c7e027 - cargo::execute::h818fd451708539ad
  17:        0x102c71ece - cargo::call_main_without_stdin::ha5cbac72641e15a1
  18:        0x102c7cbbf - cargo::main::hd19b6454ea1b61a0
  19:        0x1031965e5 - std::panicking::try::do_call::h24a2756282b9a31c
  20:        0x10319788a - __rust_maybe_catch_panic
  21:        0x103196d26 - std::rt::lang_start::hd19f94db0c6a490e
@Cxarli
Copy link

Cxarli commented Mar 12, 2017

Confirmed. cargo --version fails on all Travis Rust nightly builds.

@tmccombs
Copy link
Contributor

From the stacktrace it looks like it is coming from /checkout/cargo/src/cargo/lib.rs:263, which is

major: env_str!("CARGO_PKG_VERSION_MAJOR"),

was the CARGO_PKG_VERSION_MAJOR environment variable not set when it was built?

@sfackler
Copy link
Member

#3819

@alexcrichton
Copy link
Member

Ah yes this should be fixed in recent nightlies, thanks for the report though!

@Cxarli
Copy link

Cxarli commented Mar 13, 2017

It is indeed fixed. Thanks!

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

5 participants