cargo-bloat: It "hangs" sometimes

I ran the usage example and many variants of it, on both the crate root AND the target/release dirs. Why does this happen?

About this issue

  • Original URL
  • State: open
  • Created 2 years ago
  • Reactions: 1
  • Comments: 18 (9 by maintainers)

Most upvoted comments

Oh actually, I tried reproducing this since even with the aforementioned settings in Cargo.toml it wasn’t hanging.

I think I figured it out: while it appears to “hang” or “block”, cargo is actually performing a download - it’s just that there’s no output to reflect this.

Perhaps cargo is outputting the download progress differently? Or maybe it doesn’t output it when used in this way?

Either way. When it’s blocking here it seems to be downloading or updating the registery, etc, and for some reason that progress isn’t surfaced.

FWIW I also encountered this issue - it would block and appear frozen, but in my case even after waiting 4+ minutes nothing happened…

Came across this issue and I also have been compiling with

[profile.release]
strip = true
lto = true
codegen-units = 1

So I commented that out, ran rm -rf target and tried again. This next time, it hung for ~15 seconds and then began building.

So downloads are not visible, but Compiling is?

Yes, your profile is very computation expensive. So this is expected. lto alone can take forever depending on the number of dependencies.

Also note that strip = true isn’t compatible with cargo bloat.

The first thing cargo bloat does is runs cargo build, so if you do not see anything means that cargo build frozen.