[LLVM] Segmentation fault on MacOS with > 1 codegen units and optimization > 0

[sppalkia]

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 = 0 to profile.release in the Cargo manifest.
• Add codegen-units = 1 to profile.release in the Cargo manifest.
• Rename the weld::codegen::llvm to 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.

[jonas-schievink]

This is very likely to effectively be a duplicate of #53912, but would be good to confirm (and hopefully fix!).

[pnkfelix]

heh. Can/should we special case llvm in 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]

triage: P-high to resolve our short-term response. Leaving I-nominated in hopes that we discuss at triage today.

[pnkfelix]

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]

@rustbot claim

Assigning to self to implement lint.