-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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 build
dumps core on latest nightly with Hello World project (macOS)
#46505
Comments
Doesn't seem to happen with $ touch src/main.rs && time rustup run stable cargo build --release ~/tmp/hello_nightly 1s (master*)
Compiling hello_nightly v0.1.0 (file:///Users/gib/tmp/hello_nightly)
Finished release [optimized] target(s) in 0.25 secs
rustup run stable cargo build --release 0.29s user 0.15s system 93% cpu 0.478 total
$ touch src/main.rs && time rustup run nightly cargo build --release ~/tmp/hello_nightly (master*)
Compiling hello_nightly v0.1.0 (file:///Users/gib/tmp/hello_nightly)
Finished release [optimized] target(s) in 0.25 secs
rustup run nightly cargo build --release 0.29s user 0.16s system 93% cpu 0.482 total |
@gibfahn I'm a bit confused. If I'm not misreading things, it appears that the nightly build is faster (at least in the one case where the numbers are not identical):
vs
|
No, nm, I was getting confused by time output. I see... 3.229 total vs 0.908 total. =) |
Still happens with the newest nightly ( Pretty easy to reproduce: # Get rust if you haven't already
curl https://sh.rustup.rs -sSf | sh
rustup install nightly cargo new --bin rust-foo && cd rust-foo
cargo build
touch src/main.rs && time cargo +stable build
touch src/main.rs && time cargo +nightly build
cd .. && rm -rf rust-foo EDIT: Can't reproduce this on Ubuntu |
@gibfahn just to be clear, if you diff those two projects, do you see any difference? i.e., it seems to me you should be able to just have one project and do |
I don't see any significant difference on linux, anyway. |
@nikomatsakis are you running on macOS? I'll keep a list of platforms I tried it on. Using the shortened script above I reproduced with the same code.
$ cargo new --bin rust-foo && cd rust-foo
Created binary (application) `rust-foo` project
Cargo.toml src
$ cargo build
Compiling rust-foo v0.1.0 (file:///Users/gib/tmp/rust-foo)
Finished dev [unoptimized + debuginfo] target(s) in 2.92 secs
$ touch src/main.rs && time cargo +stable build
Compiling rust-foo v0.1.0 (file:///Users/gib/tmp/rust-foo)
Finished dev [unoptimized + debuginfo] target(s) in 0.39 secs
cargo +stable build 0.37s user 0.22s system 92% cpu 0.639 total
$ touch src/main.rs && time cargo +nightly build
Compiling rust-foo v0.1.0 (file:///Users/gib/tmp/rust-foo)
Finished dev [unoptimized + debuginfo] target(s) in 2.74 secs
cargo +nightly build 0.34s user 1.06s system 47% cpu 2.995 total |
I cannot reproduce on macOS High Sierra 10.13.2. |
It might be helpful to have a bash script that'll run the commands for me just in case, but as far as I can tell I have the same make of hardware, just a slightly different version of macOS. Seems unlikely that would be the culprit, though... |
@Mark-Simulacrum the script in #46505 (comment) is exactly what I'm doing. I tried this on a different machine (same OS level, different hardware configuration) and it didn't have the same problem. I'm not sure how else to debug. |
Clearing out |
Did an uninstall and reinstall ( $ cargo new --bin rust-foo && cd rust-foo
Created binary (application) `rust-foo` project
$ cargo build
Compiling rust-foo v0.1.0 (file:///Users/gib/tmp/rust-foo)
Finished dev [unoptimized + debuginfo] target(s) in 0.92 secs
$ touch src/main.rs && time cargo +stable build
Compiling rust-foo v0.1.0 (file:///Users/gib/tmp/rust-foo)
Finished dev [unoptimized + debuginfo] target(s) in 0.31 secs
cargo +stable build 0.26s user 0.17s system 92% cpu 0.466 total
$ touch src/main.rs && time cargo +nightly build
Compiling rust-foo v0.1.0 (file:///Users/gib/tmp/rust-foo)
Finished dev [unoptimized + debuginfo] target(s) in 0.57 secs
cargo +nightly build 0.31s user 0.22s system 68% cpu 0.774 total I did have a fair amount of stuff in ▶▶▶ ls * ~/.local/share/cargo
env
bin:
cargo cargo-fmt cargo-watch cobalt ion racer rust-gdb rustc rustfmt s xi-syntect-plugin
cargo-clippy cargo-wa clippy-driver exa pijul rls rust-lldb rustdoc rustup xi-core
git:
checkouts db
registry:
cache index src Thanks for troubleshooting! |
Okay, I worked out what's going on. I'm seeing this behaviour because I have Updated repro: ls /cores
cargo new --bin rust-foo && cd rust-foo
cargo build
ulimit -c unlimited
touch src/main.rs && time cargo +stable build # Doesn't generate a dump.
ls /cores
touch src/main.rs && time cargo +nightly build # Does generate a dump (thus slower).
ls /cores
ulimit -c 0
touch src/main.rs && time cargo +stable build
touch src/main.rs && time cargo +nightly build # Faster as dumps turned off.
cd .. && rm -rf rust-foo $ ls /cores
$ cargo new --bin rust-foo && cd rust-foo
Created binary (application) `rust-foo` project
$ cargo build
Compiling rust-foo v0.1.0 (file:///Users/gib/tmp/rust-foo)
Finished dev [unoptimized + debuginfo] target(s) in 0.26 secs
$ ulimit -c unlimited
$ touch src/main.rs && time cargo +stable build
Compiling rust-foo v0.1.0 (file:///Users/gib/tmp/rust-foo)
Finished dev [unoptimized + debuginfo] target(s) in 0.31 secs
cargo +stable build 0.27s user 0.16s system 93% cpu 0.467 total
$ ls /cores
$ touch src/main.rs && time cargo +nightly build
Compiling rust-foo v0.1.0 (file:///Users/gib/tmp/rust-foo)
Finished dev [unoptimized + debuginfo] target(s) in 1.51 secs
cargo +nightly build 0.24s user 1.03s system 75% cpu 1.679 total
$ ls /cores
core.68358
$ ulimit -c 0
$ touch src/main.rs && time cargo +stable build
Compiling rust-foo v0.1.0 (file:///Users/gib/tmp/rust-foo)
Finished dev [unoptimized + debuginfo] target(s) in 0.31 secs
cargo +stable build 0.27s user 0.17s system 94% cpu 0.466 total
$ touch src/main.rs && time cargo +nightly build
Compiling rust-foo v0.1.0 (file:///Users/gib/tmp/rust-foo)
Finished dev [unoptimized + debuginfo] target(s) in 0.27 secs
cargo +nightly build 0.24s user 0.15s system 93% cpu 0.429 total
$ cd .. && rm -rf rust-foo Now I know the issue this is easy enough to work around, I can just disable core dumps. But it'd be good to know why the cores get dumped, maybe it's a mac-specific feature, as the build does complete successfully. |
cargo build
slowdown on latest nightly with Hello World projectcargo build
dumps core on latest nightly with Hello World project (macOS)
Assigning to @pnkfelix Could you try to confirm you can reproduce this today? |
I have now reproduced this, by invoking |
This apparently was injected between the nightlies for 2017-11-25 and 2017-11-26:
|
The last entries in ouput from
Additionally, I tried running
|
I suppose another option is to load the core dump itself into the debugger and see what it says:
I have to go home now. I probably will not look at this again until tomorrow (and it will have to take lower precedence than fixes to the beta branch in preparation for the upcoming release). |
In other fronts of investigation: I worked on analyzing the actual Starting from the original invocation and whittling it down, I have determined that adding So:
|
Oh. Looking at my "OS X" terminal window during that long pause where the core dump is happening, the title bar of the window shows (I think) the current active child process. In this case, it appears to be
Maybe something has gone wrong with how we are invoking that utility? |
dsymutil? Sounds like #46346 (fixed 8 hours ago). Check with the next nightly? |
I can no longer reproduce this with the latest nightly, so I'm guessing #46346 was the fix. Thanks for all the investigation! |
Updated to the latest nightly earlier today, and immediately started noticing a marked compile time slowdown in
cargo build
(debug mode) for small projects.EDIT: Turns out the slowdown is because it's dumping a core to
/cores
, I worked this out when my machine became completely full 😁 .Platform: macOS High Sierra.
NOTE (added by @pnkfelix): it appears you need to turn up a core dump threshold to observe this, e.g. via
ulimit -c unlimited
Sorry if this is a duplicate, didn't see anything relevant in the issue tracker.
The text was updated successfully, but these errors were encountered: