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

0.13.0 and later will hang forever #48

Closed
adamchalmers opened this issue Nov 1, 2022 · 5 comments · Fixed by #49
Closed

0.13.0 and later will hang forever #48

adamchalmers opened this issue Nov 1, 2022 · 5 comments · Fixed by #49
Labels
bug Something isn't working

Comments

@adamchalmers
Copy link

adamchalmers commented Nov 1, 2022

Describe the bug
When I run cargo deny check on my project, it hangs forever. This does not happen in 0.12.0, but happens in every 0.13.x release so far.

To Reproduce
I haven't got an open-source reproduction, because the dependency which makes cargo deny check hang forever is closed-source. It does use features and a build.rs which generates protobuf stubs using tonic 0.8, and @OrionNebula says

It uses a bunch of CPU while it's stuck. I was able to pull this stack trace:

* frame #0: 0x0000000102b08220 cargo-deny`_$LT$krates..builder..features..ParsedFeature$u20$as$u20$core..convert..From$LT$$RF$str$GT$$GT$::from::hf68f245ee90305bc + 880
    frame EmbarkStudios/cargo-deny#1: 0x0000000102af78e8 cargo-deny`core::ops::function::impls::_$LT$impl$u20$core..ops..function..FnMut$LT$A$GT$$u20$for$u20$$RF$mut$u20$F$GT$::call_mut::heacbba78aae5bd8a + 1252
    frame EmbarkStudios/cargo-deny#2: 0x0000000102b1a79c cargo-deny`_$LT$alloc..vec..Vec$LT$T$GT$$u20$as$u20$alloc..vec..spec_from_iter..SpecFromIter$LT$T$C$I$GT$$GT$::from_iter::h95bc6335c05ec316 + 112
    frame EmbarkStudios/cargo-deny#3: 0x0000000102b03914 cargo-deny`krates::builder::Builder::build_with_metadata::h3b97f71ebdbfe52c + 2812
    frame EmbarkStudios/cargo-deny#4: 0x0000000102b38434 cargo-deny`cargo_deny::common::KrateContext::gather_krates::h305c801079727285 + 1528
    frame EmbarkStudios/cargo-deny#5: 0x0000000102ac1d94 cargo-deny`_$LT$core..panic..unwind_safe..AssertUnwindSafe$LT$F$GT$$u20$as$u20$core..ops..function..FnOnce$LT$$LP$$RP$$GT$$GT$::call_once::h20701a9243b8a631 + 168
    frame EmbarkStudios/cargo-deny#6: 0x0000000102b50ec4 cargo-deny`std::panicking::try::hceb1dcc0c38e1c37 + 76
    frame EmbarkStudios/cargo-deny#7: 0x0000000102aeed2c cargo-deny`_$LT$rayon_core..job..HeapJob$LT$BODY$GT$$u20$as$u20$rayon_core..job..Job$GT$::execute::h881373966ed269c9 + 312
    frame EmbarkStudios/cargo-deny#8: 0x0000000102facc08 cargo-deny`rayon_core::registry::WorkerThread::wait_until_cold::hccf0349944ec2090 + 288
    frame EmbarkStudios/cargo-deny#9: 0x0000000102e6fe84 cargo-deny`rayon_core::registry::ThreadBuilder::run::hcec1fb84ac686d4a + 584
    frame EmbarkStudios/cargo-deny#10: 0x0000000102e72748 cargo-deny`std::sys_common::backtrace::__rust_begin_short_backtrace::heba377b850be9f58 + 52
    frame EmbarkStudios/cargo-deny#11: 0x0000000102e6c604 cargo-deny`core::ops::function::FnOnce::call_once$u7b$$u7b$vtable.shim$u7d$$u7d$::ha077a802a4cc31a1 + 172
    frame EmbarkStudios/cargo-deny#12: 0x0000000102f7b41c cargo-deny`std::sys::unix::thread::Thread::new::thread_start::h403ab16d5f453cd4 [inlined] _$LT$alloc..boxed..Box$LT$F$C$A$GT$$u20$as$u20$core..ops..function..FnOnce$LT$Args$GT$$GT$::call_once::h8a0d110322a74330 at boxed.rs:1935:9 [opt]
    frame EmbarkStudios/cargo-deny#13: 0x0000000102f7b410 cargo-deny`std::sys::unix::thread::Thread::new::thread_start::h403ab16d5f453cd4 [inlined] _$LT$alloc..boxed..Box$LT$F$C$A$GT$$u20$as$u20$core..ops..function..FnOnce$LT$Args$GT$$GT$::call_once::h381d30f48837780e at boxed.rs:1935:9 [opt]
    frame EmbarkStudios/cargo-deny#14: 0x0000000102f7b40c cargo-deny`std::sys::unix::thread::Thread::new::thread_start::h403ab16d5f453cd4 at thread.rs:108:17 [opt]
    frame EmbarkStudios/cargo-deny#15: 0x000000019168826c libsystem_pthread.dylib`_pthread_start + 148
    ```
> Which I think comes from this line: https://docs.rs/krates/latest/src/krates/builder.rs.html#875 (or something in that statement anyway)

**Expected behavior**
cargo deny check should terminate in a few seconds

**Device:**
 - OS: macOS Monterey
 - Architecture: tested on both Intel arm64 and Apple Silicon M1 (aarch64)

**Additional context**
I'm sorry this is so vague, I am trying to reproduce in an open-source way. But I figured I'd open this issue now, even though it's not very helpful, in case anyone else has this problem with an open-source crate.
@adamchalmers adamchalmers added the bug Something isn't working label Nov 1, 2022
@Jake-Shadle
Copy link
Member

Would it be possible to just post the output of cargo metadata --format-version 1 to a gist?

@adamchalmers
Copy link
Author

adamchalmers commented Nov 2, 2022

Yeah, here it is, in pretty or raw JSON

@Jake-Shadle Jake-Shadle transferred this issue from EmbarkStudios/cargo-deny Nov 2, 2022
@Jake-Shadle
Copy link
Member

It seems the proto_schema crate has cyclic feature references

"features": {
  "auditlog-receiver-v1": [
      "auditlog-receiver-v1-ans-v1",
      "blocks-v1",
      "blocks-v2",
      "challenges-widgets-v1",
      "dlp-v1",
      "dns-firewall-v1",
      "emailrouting-config-v1",
      "emailrouting-v2",
      "iam-iapi-v1",
      "web3-config-v1",
      "zaraz-config-v1"
  ],
  "auditlog-receiver-v1-ans-v1": [
      "auditlog-receiver-v1"
  ],
}

I wasn't protecting against that because I could have sworn cargo would actually error if there were cyclic references like that, but maybe that doesn't apply to features, only crates, fixing.

@Jake-Shadle
Copy link
Member

Thanks for the repro!

@adamchalmers
Copy link
Author

Thanks for the quick fix :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants