Repository navigation
[LLVM] Segmentation fault on MacOS with > 1 codegen units and optimization > 0 #60925
Description
I'm seeing a segmentation fault in the Weld project during compilation when compiling with cargo build --release. This is only happening on MacOS (tested on High Sierra and Mojave); it works fine on Ubuntu 16.04. This issue also does not occur without --release.
I haven't been able to make a smaller example for this, but it seems to have started after we renamed the llvm2 submodule to llvm (weld-project/weld#440).
After some investigation, we found that any one of the following changes fix the segmentation fault, but are non-ideal:
- Add
opt-level = 0toprofile.releasein the Cargo manifest. - Add
codegen-units = 1toprofile.releasein the Cargo manifest. - Rename the
weld::codegen::llvmto something else (e.g.,weld::codegen::llvm2): this is what seems to have introduced the issue.
This is almost certainly related to #53912, but the code example in that issue seems fixed: I'll update this issue with a minimal example when I can come up with one.
The faulting command is:
rustc --edition=2018 --crate-name weld weld/src/lib.rs --color always --crate-type lib --emit=dep-info,link -C opt-level=2 -C metadata=597bae5b2ab31e15 -C extra-filename=-597bae5b2ab31e15 --out-dir /Users/shoumikpalkar/work/weld/target/release/deps -L dependency=/Users/shoumikpalkar/work/weld/target/release/deps --extern chrono=/Users/shoumikpalkar/work/weld/target/release/deps/libchrono-f261edcedff7fdf9.rlib --extern env_logger=/Users/shoumikpalkar/work/weld/target/release/deps/libenv_logger-48ad719d69c29b83.rlib --extern fnv=/Users/shoumikpalkar/work/weld/target/release/deps/libfnv-c5377afc6353fb2e.rlib --extern lazy_static=/Users/shoumikpalkar/work/weld/target/release/deps/liblazy_static-7ef694354b396823.rlib --extern libc=/Users/shoumikpalkar/work/weld/target/release/deps/liblibc-841557f1e9c82484.rlib --extern llvm_sys=/Users/shoumikpalkar/work/weld/target/release/deps/libllvm_sys-b77778a82d9c4c52.rlib --extern log=/Users/shoumikpalkar/work/weld/target/release/deps/liblog-ac2f0859500275e8.rlib --extern num_integer=/Users/shoumikpalkar/work/weld/target/release/deps/libnum_integer-9a9190e54f393ad7.rlib --extern regex=/Users/shoumikpalkar/work/weld/target/release/deps/libregex-c35e629b59596f2c.rlib --extern time=/Users/shoumikpalkar/work/weld/target/release/deps/libtime-6604aa2275081d44.rlib --extern uuid=/Users/shoumikpalkar/work/weld/target/release/deps/libuuid-7f660aa24d3f6e4a.rlib -C link-args=-Wl,-export_dynamic -L native=/Users/shoumikpalkar/work/weld/target/release/build/weld-c91c7a8f561133ca/out -l z -l c++ -l dylib=stdc++ -l static=llvmext -L native=/Users/shoumikpalkar/work/weld/target/release/build/llvm-sys-681bcfd36d11b4f1/out -L 'native=/usr/local/Cellar/llvm@6/6.0.1_1/lib'```
And LLDB gives the following information:
* thread #4, stop reason = EXC_BAD_ACCESS (code=1, address=0xffffffffffffff41)
frame #0: 0x0000000106a7575d librustc_codegen_llvm-llvm.dylib`std::__1::__function::__func<llvm::thinLTOInternalizeModule(llvm::Module&, llvm::DenseMap<unsigned long long, llvm::GlobalValueSummary*, llvm::DenseMapInfo<unsigned long long>, llvm::detail::DenseMapPair<unsigned long long, llvm::GlobalValueSummary*> > const&)::$_2, std::__1::allocator<llvm::thinLTOInternalizeModule(llvm::Module&, llvm::DenseMap<unsigned long long, llvm::GlobalValueSummary*, llvm::DenseMapInfo<unsigned long long>, llvm::detail::DenseMapPair<unsigned long long, llvm::GlobalValueSummary*> > const&)::$_2>, bool (llvm::GlobalValue const&)>::operator()(llvm::GlobalValue const&) + 765
librustc_codegen_llvm-llvm.dylib`std::__1::__function::__func<llvm::thinLTOInternalizeModule(llvm::Module&, llvm::DenseMap<unsigned long long, llvm::GlobalValueSummary*, llvm::DenseMapInfo<unsigned long long>, llvm::detail::DenseMapPair<unsigned long long, llvm::GlobalValueSummary*> > const&)::$_2, std::__1::allocator<llvm::thinLTOInternalizeModule(llvm::Module&, llvm::DenseMap<unsigned long long, llvm::GlobalValueSummary*, llvm::DenseMapInfo<unsigned long long>, llvm::detail::DenseMapPair<unsigned long long, llvm::GlobalValueSummary*> > const&)::$_2>, bool (llvm::GlobalValue const&)>::operator():
-> 0x106a7575d <+765>: movzbl 0xc(%rax), %eax
0x106a75761 <+769>: andl $0xf, %eax
0x106a75764 <+772>: addl $-0x7, %eax
0x106a75767 <+775>: cmpl $0x1, %eax
Target 0: (rustc) stopped.
Metadata
Metadata
Assignees
Labels
Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.Category: This is a bug.Issue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics.Operating system: macOSHigh priorityRelevant to the compiler team, which will review and decide on the PR/issue.
Activity
jonas-schievink commentedon May 17, 2019
This is very likely to effectively be a duplicate of #53912, but would be good to confirm (and hopefully fix!).
pnkfelix commentedon May 23, 2019
heh. Can/should we special case
llvmin our mangling algorithm to side-step this?(are issues like this perhaps an argument for a non-bijective mangling system, to reduce the chance of painting ourselves into corners here? we really can't plan ahead for all possible lack-of-expressiveness bugs on LLVM's part, though)
cc rust-lang/rfcs#2603 and #60705
pnkfelix commentedon May 23, 2019
triage: P-high to resolve our short-term response. Leaving I-nominated in hopes that we discuss at triage today.
pnkfelix commentedon May 23, 2019
discussed at T-compiler meeting. Got rough approval from @michaelwoerister to put in a lint or something to detect offensive symbols as a short-term hack. The right long-term solution will come with the implementation of rust-lang/rfcs#2603 (see e.g. PR #57967 )
davidtwco commentedon May 23, 2019
@rustbot claim
Assigning to self to implement lint.
eddyb commentedon May 23, 2019
I'm not sure we should throw a lint at this.
We can replace the
minllvmwith$6d$, and eixsting demanglers should be able to cope with it.(We should've done this the first time, but because it was affecting rustc at that point, it would've caused further delays)
Rollup merge of rust-lang#61195 - davidtwco:seg-fault-mangler, r=eddyb