Open davidspies opened 3 years ago
You can find where the time is being spent with -Z time-passes
, which prints the times eagerly. Specifically cargo rustc --bin -- -Z time-passes
should work here.
Also, SIGKILL usually means another process killed it - are you running out of memory maybe?
yup
That's what's happening.
I was looking at top
and rustc
seems to be trying to use more memory than I have on my laptop (32 GiB). I think the compiler needing more than 32 GiB memory for a ~5000 LOC project probably still qualifies as a bug.
Can you try to make an MCVE? If not, can you link the project that's using so much memory?
I tried -Z time-passes
but it doesn't print out the step that's using all the memory because it's killed before finishing. I tried killing it with ctrl-C
hoping that it would print out something on SIGTERM
rather than SIGKILL
but still nothing.
However, you can see an earlier step where it used 7 GiB. So it might just be another instantiation of that:
$ cargo rustc --bin boolsatr -- -Z time-passes
Compiling boolsatr v0.1.0 (/home/david/projects/boolsatr)
time: 0.006; rss: 50MB -> 52MB ( +1MB) parse_crate
time: 0.001; rss: 52MB -> 52MB ( +0MB) attributes_injection
time: 0.004; rss: 52MB -> 53MB ( +2MB) incr_comp_prepare_session_directory
time: 0.001; rss: 53MB -> 53MB ( +0MB) incr_comp_garbage_collect_session_directories
time: 0.001; rss: 53MB -> 53MB ( +0MB) recursion_limit
time: 0.000; rss: 53MB -> 53MB ( +0MB) plugin_loading
time: 0.000; rss: 53MB -> 53MB ( +0MB) plugin_registration
time: 0.002; rss: 55MB -> 55MB ( +0MB) crate_injection
time: 0.228; rss: 55MB -> 80MB ( +25MB) expand_crate
time: 0.000; rss: 80MB -> 80MB ( +0MB) check_unused_macros
time: 0.229; rss: 55MB -> 80MB ( +25MB) macro_expand_crate
time: 0.000; rss: 80MB -> 80MB ( +0MB) maybe_building_test_harness
time: 0.001; rss: 80MB -> 80MB ( +0MB) AST_validation
time: 0.000; rss: 80MB -> 80MB ( +0MB) maybe_create_a_macro_crate
time: 0.001; rss: 80MB -> 80MB ( +0MB) finalize_imports
time: 0.001; rss: 80MB -> 81MB ( +0MB) finalize_macro_resolutions
time: 0.023; rss: 81MB -> 84MB ( +3MB) late_resolve_crate
time: 0.001; rss: 84MB -> 84MB ( +0MB) resolve_check_unused
time: 0.000; rss: 84MB -> 84MB ( +0MB) resolve_report_errors
time: 0.000; rss: 84MB -> 84MB ( +0MB) resolve_postprocess
time: 0.026; rss: 80MB -> 84MB ( +3MB) resolve_crate
time: 0.001; rss: 84MB -> 84MB ( +0MB) complete_gated_feature_checking
time: 0.276; rss: 53MB -> 84MB ( +30MB) configure_and_expand
time: 0.001; rss: 84MB -> 84MB ( +0MB) prepare_outputs
time: 0.002; rss: 84MB -> 84MB ( +0MB) blocked_on_dep_graph_loading
time: 0.009; rss: 84MB -> 87MB ( +3MB) hir_lowering
time: 0.001; rss: 87MB -> 87MB ( +0MB) early_lint_checks
time: 0.005; rss: 87MB -> 89MB ( +2MB) setup_global_ctxt
time: 0.012; rss: 87MB -> 89MB ( +2MB) create_global_ctxt
time: 0.003; rss: 92MB -> 92MB ( +0MB) looking_for_entry_point
time: 0.001; rss: 92MB -> 92MB ( +0MB) looking_for_plugin_registrar
time: 0.000; rss: 92MB -> 92MB ( +0MB) looking_for_derive_registrar
time: 0.038; rss: 92MB -> 99MB ( +7MB) misc_checking_1
time: 0.020; rss: 99MB -> 102MB ( +3MB) type_collecting
time: 0.001; rss: 102MB -> 102MB ( +0MB) impl_wf_inference
time: 0.000; rss: 139MB -> 139MB ( +0MB) unsafety_checking
time: 0.000; rss: 139MB -> 139MB ( +0MB) orphan_checking
time: 0.166; rss: 102MB -> 139MB ( +37MB) coherence_checking
time: 0.043; rss: 139MB -> 144MB ( +5MB) wf_checking
time: 0.003; rss: 144MB -> 144MB ( +0MB) item_types_checking
time: 0.177; rss: 144MB -> 155MB ( +12MB) item_bodies_checking
time: 0.409; rss: 99MB -> 155MB ( +57MB) type_check_crate
time: 0.004; rss: 155MB -> 156MB ( +1MB) match_checking
time: 0.004; rss: 156MB -> 158MB ( +2MB) liveness_and_intrinsic_checking
time: 0.008; rss: 155MB -> 158MB ( +3MB) misc_checking_2
time: 0.197; rss: 158MB -> 176MB ( +18MB) MIR_borrow_checking
time: 0.000; rss: 176MB -> 176MB ( +0MB) MIR_effect_checking
time: 0.000; rss: 176MB -> 176MB ( +0MB) layout_testing
warning: associated function is never used: `dump_stats`
--> src/solver/mod.rs:101:12
|
101 | pub fn dump_stats(&mut self, _graph_file: &mut File) -> Result<(), io::Error> {
| ^^^^^^^^^^
|
= note: `#[warn(dead_code)]` on by default
time: 0.003; rss: 177MB -> 177MB ( +1MB) death_checking
time: 0.001; rss: 177MB -> 177MB ( +0MB) unused_lib_feature_checking
time: 0.003; rss: 177MB -> 179MB ( +2MB) crate_lints
time: 0.002; rss: 179MB -> 179MB ( +0MB) module_lints
time: 0.005; rss: 177MB -> 179MB ( +2MB) lint_checking
time: 0.008; rss: 179MB -> 179MB ( +0MB) privacy_checking_modules
time: 0.020; rss: 176MB -> 179MB ( +3MB) misc_checking_3
time: 0.003; rss: 179MB -> 180MB ( +1MB) monomorphization_collector_root_collections
time: 93.116; rss: 180MB -> 254MB ( +74MB) monomorphization_collector_graph_walk
time: 45.622; rss: 254MB -> 7394MB (+7140MB) partition_and_assert_distinct_symbols
time: 0.001; rss: 7395MB -> 7395MB ( +0MB) write_allocator_module
time: 0.000; rss: 7395MB -> 7395MB ( +0MB) find_cgu_reuse
time: 0.000; rss: 5826MB -> 5826MB ( +0MB) LLVM_module_optimize_function_passes(2yqwcofw48oip3q)
time: 0.000; rss: 5826MB -> 5826MB ( +0MB) LLVM_module_optimize_module_passes(2yqwcofw48oip3q)
time: 0.002; rss: 5826MB -> 5827MB ( +1MB) LLVM_module_optimize_function_passes(5054vo9ldvu6shng)
time: 0.037; rss: 5827MB -> 5832MB ( +5MB) LLVM_module_optimize_module_passes(5054vo9ldvu6shng)
time: 0.000; rss: 5859MB -> 5859MB ( +0MB) LLVM_module_optimize_function_passes(483dpiq9qkl9z8jb)
time: 0.000; rss: 5859MB -> 5859MB ( +0MB) LLVM_module_optimize_module_passes(483dpiq9qkl9z8jb)
time: 0.001; rss: 5859MB -> 5860MB ( +1MB) LLVM_module_optimize_function_passes(2o3q8cccyyjhbuub)
time: 0.028; rss: 5860MB -> 5864MB ( +4MB) LLVM_module_optimize_module_passes(2o3q8cccyyjhbuub)
time: 0.000; rss: 5905MB -> 5905MB ( +0MB) LLVM_module_optimize_function_passes(51uxob6iog635dyd)
time: 0.000; rss: 5905MB -> 5905MB ( +0MB) LLVM_module_optimize_module_passes(51uxob6iog635dyd)
time: 0.002; rss: 5905MB -> 5906MB ( +1MB) LLVM_module_optimize_function_passes(4rj8oul8m6jyjmj1)
time: 0.044; rss: 5906MB -> 5914MB ( +8MB) LLVM_module_optimize_module_passes(4rj8oul8m6jyjmj1)
time: 0.000; rss: 5921MB -> 5921MB ( +0MB) LLVM_module_optimize_function_passes(42r33rw64tassjdf)
time: 0.000; rss: 5921MB -> 5921MB ( +0MB) LLVM_module_optimize_function_passes(8q5lsqmu640v7oj)
time: 0.000; rss: 5921MB -> 5921MB ( +0MB) LLVM_module_optimize_module_passes(8q5lsqmu640v7oj)
time: 0.009; rss: 5921MB -> 5922MB ( +2MB) LLVM_module_optimize_module_passes(42r33rw64tassjdf)
time: 0.000; rss: 11669MB -> 11669MB ( +0MB) LLVM_module_optimize_function_passes(2wu69c6uhy5ywqpg)
time: 0.000; rss: 11669MB -> 11669MB ( +0MB) LLVM_module_optimize_module_passes(2wu69c6uhy5ywqpg)
time: 0.001; rss: 11669MB -> 11669MB ( +0MB) LLVM_module_optimize_function_passes(z221iw9si33ns95)
time: 0.235; rss: 11669MB -> 11695MB ( +26MB) LLVM_module_optimize_module_passes(z221iw9si33ns95)
time: 0.000; rss: 14330MB -> 14331MB ( +1MB) LLVM_module_optimize_function_passes(9wflittwaemudxk)
time: 0.000; rss: 14331MB -> 14331MB ( +0MB) LLVM_module_optimize_function_passes(389lxyptdtznlxxi)
time: 0.000; rss: 14331MB -> 14331MB ( +0MB) LLVM_module_optimize_module_passes(389lxyptdtznlxxi)
time: 0.009; rss: 14331MB -> 14359MB ( +28MB) LLVM_module_optimize_module_passes(9wflittwaemudxk)
^C Building [========================> ] 14/15: boolsatr(bin)
Okay
I have a MCVE (where M
stands for "Much smaller")
This uses over 20 GiB to compile
@rustbot claim
Any ideas at a workaround? I tried changing all the .split
calls to .collect
and that reduced the memory usage quite a bit, but after some more changes to the dc2
package (https://github.com/davidspies/dc2/commit/d73daf710bf02da48aeb8f2c308575e676e58d5c) it's still using more than 32GiB memory
I haven't been able to fully investigate, so I can't help much yet. But the issue is partly that the compiler is struggling with generic functions whose type parameters are deeply nested. The MCVE results in types whose string representations are extremely long (like FlatMap<FlatMap<Receiver<FlatMap<Concat<Receiver<FlatMap<Join<Receiver<...>>>>>>>>
). One is 19 million characters.
At one point, I believe these might have been rejected by the default type length limit, but there is a bug preventing that.
These types also cause the compiler to generate enormous symbol names, which accounts for the memory increase in the partition_and_assert_distinct_symbols
pass. They're likely a problem during code generation as well.
Thanks,
How do I see how long the generated types are?
I want to try various changes and see how that affects things
You can use -Z print-mono-items=lazy
. The output will be a couple of GB.
@davidspies, a partial solution is to use -Z symbol-manging-version=v0
. That enables the newer symbol mangling scheme, which generates smaller symbols in cases where there are repeated components within it. With this, the MCVE compiles in 1.3 GB in debug mode.
However, compiling in release mode (#82445) still requires 14 GB. You can lower this substantially by disabling all LTO, for example by putting this in Cargo.toml:
[profile.release]
lto = "off"
With LTO off in release mode, it compiles using ~875MB.
But whether in debug or release mode, it still takes a longer time to compile than one would hope. Much of the time appears to be spent in the call to generate the optimized MIR. Still need to investigate that and the LTO memory usage.
By the way, there are several related issues that this may turn out to be a duplicate of, for example, #54540.
thanks so much; I'll try these things
I'm using vscode with the rust extension. Is there some way to get rls
to build with the -Z
option? Can I modify the Cargo.toml
for that?
I would not recommend using RLS for anything complicated. matklad.rust-analyzer
works pretty well, there's some setting to change the arguments to rustc I think.
Alternatively you could put this in .cargo/config
, which should have cargo pick it up automatically.
I tried creating a .cargo/config.toml
file with:
[target.nightly-x86_64-unknown-linux-gnu]
rustflags = "-Z symbol-manging-version=v0"
note I kept your typo sayng "manging" rather than "mangling" and it didn't complain. I think it's ignoring the settings in my config.toml
. I don't know whether that's because I have the wrong target name or because I'm not supposed to have the -Z
. I can't find any example toml
files that do it correctly.
@davidspies remove nightly
:
[target.x86_64-unknown-linux-gnu]
rustflags = "-Z symbol-mangling-version=v0"
@rustbot release-assignment
Sorry, I haven't had time to work on this.
@tgnottingham Is there a way to ask someone else to take it on? Also, how do I get rid of the "needs-mcve" tag?
@davidspies do you mean https://github.com/rust-lang/rust/issues/82406#issuecomment-783664175 for the MCVE? I think it might still be nice to get it smaller (at least no dependencies).
I have a project where
cargo build
runs for about 5 minutes before spitting out:(
cargo check
runs without issue)I assume the compiler's getting stuck in a loop somewhere and
cargo
is killing it after some timeout, but to produce a MWE I need some idea of which bit of code is causing it. How can I figure this out?Meta
rustc --version --verbose
:Adding
RUST_BACKTRACE=1
doesn't change the error message