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 deny doesn't exit after run #141

Closed
patriksvensson opened this issue Feb 20, 2020 · 6 comments
Closed

Cargo deny doesn't exit after run #141

patriksvensson opened this issue Feb 20, 2020 · 6 comments
Labels
bug Something isn't working

Comments

@patriksvensson
Copy link
Contributor

patriksvensson commented Feb 20, 2020

Thanks for an awesome tool!

Describe the bug
After running cargo deny check -d (or cargo deny check), the application does not exit after printing diagnostics. I have to press Ctrl+C to abort the run. Same thing happens on both Linux (Ubuntu and archlinux) and Windows.

I've tried adding the -L trace to see if it's doing something, but there is nothing in the output that indicates that it does.

To Reproduce
I have no idea how to reproduce it at the moment. Will try to create a minimal reproducible example, but thought I would log it here first (in case I'm holding it wrong in an obvious way).

Expected behavior
Cargo-deny should exit after it's done.

Device:

  • OS: Windows 10
  • Version: 1903 build 18362.657

Additional context

@patriksvensson patriksvensson added the bug Something isn't working label Feb 20, 2020
@Jake-Shadle
Copy link
Member

Hmm weird. I think I might have seen this once before, but haven't in a while. Might be a race somewhere since we spawn several worker threads in the check command.

@patriksvensson
Copy link
Contributor Author

patriksvensson commented Feb 23, 2020

@Jake-Shadle This doesn't seem to be a bug after all. If I leave cargo deny check for about 5-10 minutes, it will finish, and the subsequent run finishes in a couple of seconds after that as intended.

Clearing Cargo's registry cache/index/src will make the check run slowly again, which makes sense.

Perhaps we could add some logging to make it apparent that cargo-deny is doing something and haven't hung? I'd be happy to submit a pull request for this.

@Jake-Shadle
Copy link
Member

Ahh ok, so I take it you don't have a lock file? Either way that's an insanely long time doing a fetch, as that's what I am assuming is causing the stall, as fetching is done during lock file generation by default.

@patriksvensson
Copy link
Contributor Author

@Jake-Shadle Hmm, yes, I have a lock file. My app is a binary I distribute so it’s committed to the repo.

Perhaps creating a memory dump from the time it hangs could provide more insight in what the problem is. I’ll take a closer look at it tomorrow.

@Jake-Shadle
Copy link
Member

How long does running cargo metadata take? That is where I would expect it to take time, but only if it needs to fetch crate sources that aren't already local. The only other network operation that occurs is the fetching of the advisory database, which is logged (try -L debug before check to see more info on that part).

@Jake-Shadle
Copy link
Member

Closing for now as I have heard of no other issues with this.

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

No branches or pull requests

2 participants