LLVM occassionally crashes when compiling project

[JakeChampion]

The project sometimes builds and sometimes fails to build with the below backtrace

I'm not sure what other information to give here, other than the backtrace - please let me know what (if any) other information would be useful to include and I will try my best to return with that information 🙇

0:12.22 PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
 0:12.32  #0 0x000000010aba7df0 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/Users/jakechampion/.mozbuild/clang/lib/libLLVM.dylib+0xb83df0)
 0:12.32  #1 0x000000010aba835c SignalHandler(int) (/Users/jakechampion/.mozbuild/clang/lib/libLLVM.dylib+0xb8435c)
 0:12.32  #2 0x000000019436b584 (/usr/lib/system/libsystem_platform.dylib+0x180477584)
 0:12.32  #3 0x0000000104f7e784 lld::wasm::InputChunk::relocate(unsigned char*) const (/Users/jakechampion/.mozbuild/clang/bin/lld+0x100322784)
 0:12.32  #4 0x0000000104f7e784 lld::wasm::InputChunk::relocate(unsigned char*) const (/Users/jakechampion/.mozbuild/clang/bin/lld+0x100322784)
 0:12.32  #5 0x0000000104f97e18 lld::wasm::CustomSection::writeTo(unsigned char*) (/Users/jakechampion/.mozbuild/clang/bin/lld+0x10033be18)
 0:12.32  #6 0x000000010ab41c34 std::__1::__function::__func<llvm::parallelFor(unsigned long, unsigned long, llvm::function_ref<void (unsigned long)>)::$_0, std::__1::allocator<llvm::parallelFor(unsigned long, unsigned long, llvm::function_ref<void (unsigned long)>)::$_0>, void ()>::operator()() (/Users/jakechampion/.mozbuild/clang/lib/libLLVM.dylib+0xb1dc34)
 0:12.32  #7 0x000000010ab41b60 std::__1::__function::__func<llvm::parallel::TaskGroup::spawn(std::__1::function<void ()>, bool)::$_0, std::__1::allocator<llvm::parallel::TaskGroup::spawn(std::__1::function<void ()>, bool)::$_0>, void ()>::operator()() (/Users/jakechampion/.mozbuild/clang/lib/libLLVM.dylib+0xb1db60)
 0:12.32  #8 0x000000010ab411c4 llvm::parallel::detail::(anonymous namespace)::ThreadPoolExecutor::work(llvm::ThreadPoolStrategy, unsigned int) (/Users/jakechampion/.mozbuild/clang/lib/libLLVM.dylib+0xb1d1c4)
 0:12.33  #9 0x000000010ab4136c void* std::__1::__thread_proxy[abi:un170006]<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct>>, llvm::parallel::detail::(anonymous namespace)::ThreadPoolExecutor::ThreadPoolExecutor(llvm::ThreadPoolStrategy)::'lambda'()::operator()() const::'lambda'()>>(void*) (/Users/jakechampion/.mozbuild/clang/lib/libLLVM.dylib+0xb1d36c)
 0:12.33 #10 0x000000019433af94 (/usr/lib/system/libsystem_pthread.dylib+0x180446f94)
 0:12.33 #11 0x0000000194335d34 (/usr/lib/system/libsystem_pthread.dylib+0x180441d34)

[llvmbot]

@llvm/issue-subscribers-backend-webassembly

Author: Jake Champion (JakeChampion)

The project sometimes builds and sometimes fails to build with the below backtrace

I'm not sure what other information to give here, other than the backtrace - please let me know what (if any) other information would be useful to include and I will try my best to return with that information 🙇

0:12.22 PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
 0:12.32  #<!-- -->0 0x000000010aba7df0 llvm::sys::PrintStackTrace(llvm::raw_ostream&amp;, int) (/Users/jakechampion/.mozbuild/clang/lib/libLLVM.dylib+0xb83df0)
 0:12.32  #<!-- -->1 0x000000010aba835c SignalHandler(int) (/Users/jakechampion/.mozbuild/clang/lib/libLLVM.dylib+0xb8435c)
 0:12.32  #<!-- -->2 0x000000019436b584 (/usr/lib/system/libsystem_platform.dylib+0x180477584)
 0:12.32  #<!-- -->3 0x0000000104f7e784 lld::wasm::InputChunk::relocate(unsigned char*) const (/Users/jakechampion/.mozbuild/clang/bin/lld+0x100322784)
 0:12.32  #<!-- -->4 0x0000000104f7e784 lld::wasm::InputChunk::relocate(unsigned char*) const (/Users/jakechampion/.mozbuild/clang/bin/lld+0x100322784)
 0:12.32  #<!-- -->5 0x0000000104f97e18 lld::wasm::CustomSection::writeTo(unsigned char*) (/Users/jakechampion/.mozbuild/clang/bin/lld+0x10033be18)
 0:12.32  #<!-- -->6 0x000000010ab41c34 std::__1::__function::__func&lt;llvm::parallelFor(unsigned long, unsigned long, llvm::function_ref&lt;void (unsigned long)&gt;)::$_0, std::__1::allocator&lt;llvm::parallelFor(unsigned long, unsigned long, llvm::function_ref&lt;void (unsigned long)&gt;)::$_0&gt;, void ()&gt;::operator()() (/Users/jakechampion/.mozbuild/clang/lib/libLLVM.dylib+0xb1dc34)
 0:12.32  #<!-- -->7 0x000000010ab41b60 std::__1::__function::__func&lt;llvm::parallel::TaskGroup::spawn(std::__1::function&lt;void ()&gt;, bool)::$_0, std::__1::allocator&lt;llvm::parallel::TaskGroup::spawn(std::__1::function&lt;void ()&gt;, bool)::$_0&gt;, void ()&gt;::operator()() (/Users/jakechampion/.mozbuild/clang/lib/libLLVM.dylib+0xb1db60)
 0:12.32  #<!-- -->8 0x000000010ab411c4 llvm::parallel::detail::(anonymous namespace)::ThreadPoolExecutor::work(llvm::ThreadPoolStrategy, unsigned int) (/Users/jakechampion/.mozbuild/clang/lib/libLLVM.dylib+0xb1d1c4)
 0:12.33  #<!-- -->9 0x000000010ab4136c void* std::__1::__thread_proxy[abi:un170006]&lt;std::__1::tuple&lt;std::__1::unique_ptr&lt;std::__1::__thread_struct, std::__1::default_delete&lt;std::__1::__thread_struct&gt;&gt;, llvm::parallel::detail::(anonymous namespace)::ThreadPoolExecutor::ThreadPoolExecutor(llvm::ThreadPoolStrategy)::'lambda'()::operator()() const::'lambda'()&gt;&gt;(void*) (/Users/jakechampion/.mozbuild/clang/lib/libLLVM.dylib+0xb1d36c)
 0:12.33 #<!-- -->10 0x000000019433af94 (/usr/lib/system/libsystem_pthread.dylib+0x180446f94)
 0:12.33 #<!-- -->11 0x0000000194335d34 (/usr/lib/system/libsystem_pthread.dylib+0x180441d34)

[aheejin]

Even if it does not always fail, we'd appreciate a reproducer. Can you provide one?

[JakeChampion]

I've now landed enough of the patches to make the reproduction hopefully simpler to do.

This happens when compiling Mozilla's SpiderMonkey to WASI in debug mode and with Intl included

A full log output can be found at https://treeherder.mozilla.org/logviewer?job_id=468809046&repo=try&lineNumber=5901

Gecko-Dev, which contains SpiderMonkey is a rather large codebase though, the steps to get it building are quite a bit -- https://firefox-source-docs.mozilla.org/setup/macos_build.html

Once that is done you can create a mozconfig file named 'mozconfig-intl-debug' containing:

ac_add_options --enable-project=js
ac_add_options --enable-application=js
ac_add_options --target=wasm32-unknown-wasi
ac_add_options --without-system-zlib
ac_add_options --disable-jit
ac_add_options --disable-shared-js
ac_add_options --disable-shared-memory
ac_add_options --disable-tests
ac_add_options --disable-clang-plugin
ac_add_options --enable-jitspew
ac_add_options --enable-optimize=-O3
ac_add_options --enable-portable-baseline-interp
mk_add_options AUTOCLOBBER=1
ac_add_options --host=aarch64-apple-darwin
ac_add_options --enable-debug

And building the project with MOZCONFIG=./mozconfig-intl-debug ./mach build

[aheejin]

Can you possibly generate a reproducer using wasm-ld --reproduce?

[JakeChampion]

Thanks, I've generated that file, it's 574M in size, not too sure where I could upload that

[aheejin]

You can upload it to a Google drive or Dropbox or something and paste the link here.

[JakeChampion]

@aheejin here it is https://mega.nz/file/VlNnRTSK#2kj3qBJFjlgQjl_vOT2MRfZQAG849r1sC9iXvF4qkRs

[guybedford]

I'll be picking up from @JakeChampion on this Fastly / BytecodeAlliance error report. If there is any more info that can be provided please just let me know.