firefly Compilation fails with SIGSEGV on Windows WSL2 (Ubuntu)

A release! Congratulations!

I gave it a test on my computer which is running Ubuntu in WSL2 on Windows 10.

Here's the result:

% init.erl
-module(init).
-export([start/0]).

start() ->
    erlang:display(hello_lumen).

$ lumen compile
   Compiling /home/louis/src/lpil/learning/erlang/lumen_test/init.erl
fish: 'lumen compile' terminated by signal SIGSEGV (Address boundary error)

Let me know if I can help in future with debugging + testing. Cheers

Sep 03 '20 09:09 lpil

I've also tried this on my Linux machine and got a segmentation fault:

~/Projects/Experiments/lumen-cli$ /opt/lumen/bin/lumen compile init.erl 
   Compiling init.erl
Segmentation fault (core dumped)

How can I get more info and help?

Sep 03 '20 10:09 Tuxified

Trying this on a Mac (mojave) also fails to compile:

~/Projects/experiments/lumen-cli$ /opt/lumen/bin/lumen compile init.erl
   Compiling init.erl
Assertion failed: (impl && "isa<> used on a null type."), function isa, file /Users/paulschoenfelder/src/github.com/bitwalker/llvm-project/mlir/include/mlir/IR/Types.h, line 292.
Abort trap: 6

Sep 03 '20 11:09 Tuxified

Hi @Tuxified, I think these are different issues, it may be worth having a different issue for each different error.

Sep 03 '20 11:09 lpil

@lpil I trust with your work on Gleam, you have had some practice with lldb. Can you do

lldb lumen -- compile
run

and see what happens?

Sep 03 '20 14:09 KronicDeth

I've not dabbled in llvm yet! I've installed the lldb package on Ubuntu in WSL2 and here's what I've got:

$ lldb lumen -- compile
(lldb) target create "lumen"
Current executable set to 'lumen' (x86_64).
(lldb) settings set -- target.run-args  "compile"
(lldb) run
Process 685 launched: '/home/louis/bin/lumen' (x86_64)
   Compiling /home/louis/src/lpil/learning/erlang/lumen_test/init.erl
Process 685 stopped
* thread #2, name = 'lumen', stop reason = signal SIGSEGV: invalid address (fault address: 0x800000000)
    frame #0: 0x00005555575ecfb1 lumen`mlir::LLVM::LLVMStructType::setBody(llvm::ArrayRef<mlir::LLVM::LLVMType>, bool) + 641
lumen`mlir::LLVM::LLVMStructType::setBody:
->  0x5555575ecfb1 <+641>: movq   (%rax), %rax
    0x5555575ecfb4 <+644>: testq  %rax, %rax
    0x5555575ecfb7 <+647>: je     0x5555575ed0e5            ; <+949>
    0x5555575ecfbd <+653>: movq   0x10(%rax), %rax
(lldb)

Sep 04 '20 09:09 lpil

As you suggested in the other topic, I've retrieved the backtrace (hope it helps):

~/Projects/Experiments/lumen-cli$ ~/.local/share/llvm/lumen/bin/lldb /opt/lumen/bin/lumen -- compile
(lldb) target create "/opt/lumen/bin/lumen"
Current executable set to '/opt/lumen/bin/lumen' (x86_64).
(lldb) settings set -- target.run-args  "compile"


(lldb) run
Process 9745 launched: '/opt/lumen/bin/lumen' (x86_64)
   Compiling /home/tuxified/Projects/Experiments/lumen-cli/init.erl
Process 9745 stopped
* thread #12, name = 'lumen', stop reason = signal SIGSEGV: invalid address (fault address: 0x800000000)
    frame #0: 0x00005555575ecfb1 lumen`mlir::LLVM::LLVMStructType::setBody(llvm::ArrayRef<mlir::LLVM::LLVMType>, bool) + 641
lumen`mlir::LLVM::LLVMStructType::setBody:
->  0x5555575ecfb1 <+641>: movq   (%rax), %rax
    0x5555575ecfb4 <+644>: testq  %rax, %rax
    0x5555575ecfb7 <+647>: je     0x5555575ed0e5            ; <+949>
    0x5555575ecfbd <+653>: movq   0x10(%rax), %rax


(lldb) bt
* thread #12, name = 'lumen', stop reason = signal SIGSEGV: invalid address (fault address: 0x800000000)
  * frame #0: 0x00005555575ecfb1 lumen`mlir::LLVM::LLVMStructType::setBody(llvm::ArrayRef<mlir::LLVM::LLVMType>, bool) + 641
    frame #1: 0x00005555575ecad6 lumen`mlir::LLVM::LLVMType::createStructTy(mlir::MLIRContext*, llvm::ArrayRef<mlir::LLVM::LLVMType>, llvm::Optional<llvm::StringRef>, bool) + 342
    frame #2: 0x00005555574be02d lumen`lumen::TargetInfo::TargetInfo(llvm::TargetMachine*, mlir::MLIRContext*) + 1421
    frame #3: 0x00005555574bafc2 lumen`lumen::eir::ConvertEIRToLLVMPass::runOnOperation() + 402
    frame #4: 0x0000555557617b6f lumen`mlir::Pass::run(mlir::Operation*, mlir::AnalysisManager) + 223
    frame #5: 0x000055555761bb52 lumen`mlir::PassManager::run(mlir::ModuleOp) + 418
    frame #6: 0x0000555557507fb1 lumen`MLIRLowerModule + 17
    frame #7: 0x0000555557505a42 lumen`liblumen_mlir::module::Module::lower::h0a4a0c86d67c5594 + 34
    frame #8: 0x00005555572ae845 lumen`liblumen_compiler::compiler::queries::get_llvm_dialect_module::hb4864d44652a2989 + 405
    frame #9: 0x0000555557228c48 lumen`salsa::runtime::Runtime$LT$DB$GT$::execute_query_implementation::heb303b5bcbb3ee57 + 328
    frame #10: 0x0000555557270e8a lumen`salsa::derived::slot::Slot$LT$DB$C$Q$C$MP$GT$::read_upgrade::hfb4e540eca498918 + 2138
    frame #11: 0x00005555572767a8 lumen`salsa::derived::slot::Slot$LT$DB$C$Q$C$MP$GT$::read::h3e80036de32232dd + 568
    frame #12: 0x0000555557241ad8 lumen`_$LT$salsa..derived..DerivedStorage$LT$DB$C$Q$C$MP$GT$$u20$as$u20$salsa..plumbing..QueryStorageOps$LT$DB$C$Q$GT$$GT$::try_fetch::h666cc05ace5a9b09 + 888
    frame #13: 0x00005555572af31b lumen`liblumen_compiler::compiler::queries::get_llvm_module::h6adcc5caeb66357a + 187
    frame #14: 0x0000555557227f18 lumen`salsa::runtime::Runtime$LT$DB$GT$::execute_query_implementation::h78e9ee12477fe077 + 328
    frame #15: 0x000055555726d84a lumen`salsa::derived::slot::Slot$LT$DB$C$Q$C$MP$GT$::read_upgrade::hbe93ca91c1d23fc4 + 2138
    frame #16: 0x0000555557279498 lumen`salsa::derived::slot::Slot$LT$DB$C$Q$C$MP$GT$::read::h7071a15bbcdcce00 + 568
    frame #17: 0x00005555572444e8 lumen`_$LT$salsa..derived..DerivedStorage$LT$DB$C$Q$C$MP$GT$$u20$as$u20$salsa..plumbing..QueryStorageOps$LT$DB$C$Q$GT$$GT$::try_fetch::hbd9e367efb7bccc5 + 888
    frame #18: 0x00005555572b0012 lumen`liblumen_compiler::compiler::queries::compile::h6200ec8f72be1cdf + 626
    frame #19: 0x00005555572288f5 lumen`salsa::runtime::Runtime$LT$DB$GT$::execute_query_implementation::hab518cbba333722b + 325
    frame #20: 0x000055555725c90a lumen`salsa::derived::slot::Slot$LT$DB$C$Q$C$MP$GT$::read_upgrade::h3948fe9222884e1d + 2074
    frame #21: 0x0000555557278d22 lumen`salsa::derived::slot::Slot$LT$DB$C$Q$C$MP$GT$::read::h6eb9ff24bd6b912d + 562
    frame #22: 0x0000555557242555 lumen`_$LT$salsa..derived..DerivedStorage$LT$DB$C$Q$C$MP$GT$$u20$as$u20$salsa..plumbing..QueryStorageOps$LT$DB$C$Q$GT$$GT$::try_fetch::h8e210aec83111ba4 + 805
    frame #23: 0x00005555572c455d lumen`_$LT$core..future..from_generator..GenFuture$LT$T$GT$$u20$as$u20$core..future..future..Future$GT$::poll::h22ae25e5b1df644f + 61
    frame #24: 0x00005555572bc6d2 lumen`async_task::raw::RawTask$LT$F$C$R$C$S$C$T$GT$::run::h235a15e492cbf498 + 114
    frame #25: 0x00005555572a7c9c lumen`std::sys_common::backtrace::__rust_begin_short_backtrace::h7e758b03affaa6fb + 92
    frame #26: 0x00005555572beb8e lumen`core::ops::function::FnOnce::call_once$u7b$$u7b$vtable.shim$u7d$$u7d$::h5c51da0d808debbb + 78
    frame #27: 0x0000555559a7cc1a lumen`std::sys::unix::thread::Thread::new::thread_start::h8b0ae441dc3343d4 [inlined] _$LT$alloc..boxed..Box$LT$F$GT$$u20$as$u20$core..ops..function..FnOnce$LT$A$GT$$GT$::call_once::h5b84f52b19042f22 at boxed.rs:1034:9
    frame #28: 0x0000555559a7cc14 lumen`std::sys::unix::thread::Thread::new::thread_start::h8b0ae441dc3343d4 [inlined] _$LT$alloc..boxed..Box$LT$F$GT$$u20$as$u20$core..ops..function..FnOnce$LT$A$GT$$GT$::call_once::h6e1ef057e35f3144 at boxed.rs:1034
    frame #29: 0x0000555559a7cc0b lumen`std::sys::unix::thread::Thread::new::thread_start::h8b0ae441dc3343d4 at thread.rs:87
    frame #30: 0x00007ffff7f76609 libpthread.so.0`start_thread + 217
    frame #31: 0x00007ffff7b50103 libc.so.6`__clone + 67
(lldb)

Sep 04 '20 19:09 Tuxified

@lpil sorry, forgot to mention that you need to do bt to get the backtrace when run stops at the segfault so you're not stuck just looking at the ASM instructions.

Sep 04 '20 19:09 KronicDeth

@tuxified this looks like the same as https://github.com/lumen/lumen/issues/577#issuecomment-687577068

Sep 05 '20 13:09 KronicDeth

Yes, Linux mint, @lpil's Ubuntu (running behind WSL) and the distro I use (PopOS) are all Ubuntu derivatives, so I think we're hitting the same issue. I tried to compile lumen itself, but haven't been succesful, so I wonder if the lumen executable also depends on something from llvms tooling (for example, it seems to use llvm c compiler and not gcc: https://github.com/lumen/lumen/blob/develop/.github/workflows/Dockerfile#L9) ? I'm guessing here as I'm not experienced with C / systems programming etc ...

Sep 05 '20 13:09 Tuxified

Ah! Here it is with bt

louis ~/src/lpil/learning/erlang/lumen_test (master ?) $ lldb lumen -- compile
(lldb) target create "lumen"
Current executable set to 'lumen' (x86_64).
(lldb) settings set -- target.run-args  "compile"
(lldb) run
Process 132 launched: '/home/louis/bin/lumen' (x86_64)
   Compiling /home/louis/src/lpil/learning/erlang/lumen_test/init.erl
Process 132 stopped
* thread #2, name = 'lumen', stop reason = signal SIGSEGV: invalid address (fault address: 0x800000000)
    frame #0: 0x00005555575ecfb1 lumen`mlir::LLVM::LLVMStructType::setBody(llvm::ArrayRef<mlir::LLVM::LLVMType>, bool) + 641
lumen`mlir::LLVM::LLVMStructType::setBody:
->  0x5555575ecfb1 <+641>: movq   (%rax), %rax
    0x5555575ecfb4 <+644>: testq  %rax, %rax
    0x5555575ecfb7 <+647>: je     0x5555575ed0e5            ; <+949>
    0x5555575ecfbd <+653>: movq   0x10(%rax), %rax
(lldb) bt
* thread #2, name = 'lumen', stop reason = signal SIGSEGV: invalid address (fault address: 0x800000000)
  * frame #0: 0x00005555575ecfb1 lumen`mlir::LLVM::LLVMStructType::setBody(llvm::ArrayRef<mlir::LLVM::LLVMType>, bool) + 641
    frame #1: 0x00005555575ecad6 lumen`mlir::LLVM::LLVMType::createStructTy(mlir::MLIRContext*, llvm::ArrayRef<mlir::LLVM::LLVMType>, llvm::Optional<llvm::StringRef>, bool) + 342
    frame #2: 0x00005555574be02d lumen`lumen::TargetInfo::TargetInfo(llvm::TargetMachine*, mlir::MLIRContext*) + 1421
    frame #3: 0x00005555574bafc2 lumen`lumen::eir::ConvertEIRToLLVMPass::runOnOperation() + 402
    frame #4: 0x0000555557617b6f lumen`mlir::Pass::run(mlir::Operation*, mlir::AnalysisManager) + 223
    frame #5: 0x000055555761bb52 lumen`mlir::PassManager::run(mlir::ModuleOp) + 418
    frame #6: 0x0000555557507fb1 lumen`MLIRLowerModule + 17
    frame #7: 0x0000555557505a42 lumen`liblumen_mlir::module::Module::lower::h0a4a0c86d67c5594 + 34
    frame #8: 0x00005555572ae845 lumen`liblumen_compiler::compiler::queries::get_llvm_dialect_module::hb4864d44652a2989 + 405
    frame #9: 0x0000555557228c48 lumen`salsa::runtime::Runtime$LT$DB$GT$::execute_query_implementation::heb303b5bcbb3ee57 + 328
    frame #10: 0x0000555557270e8a lumen`salsa::derived::slot::Slot$LT$DB$C$Q$C$MP$GT$::read_upgrade::hfb4e540eca498918 + 2138
    frame #11: 0x00005555572767a8 lumen`salsa::derived::slot::Slot$LT$DB$C$Q$C$MP$GT$::read::h3e80036de32232dd + 568
    frame #12: 0x0000555557241ad8 lumen`_$LT$salsa..derived..DerivedStorage$LT$DB$C$Q$C$MP$GT$$u20$as$u20$salsa..plumbing..QueryStorageOps$LT$DB$C$Q$GT$$GT$::try_fetch::h666cc05ace5a9b09 + 888
    frame #13: 0x00005555572af31b lumen`liblumen_compiler::compiler::queries::get_llvm_module::h6adcc5caeb66357a + 187
    frame #14: 0x0000555557227f18 lumen`salsa::runtime::Runtime$LT$DB$GT$::execute_query_implementation::h78e9ee12477fe077 + 328
    frame #15: 0x000055555726d84a lumen`salsa::derived::slot::Slot$LT$DB$C$Q$C$MP$GT$::read_upgrade::hbe93ca91c1d23fc4 + 2138
    frame #16: 0x0000555557279498 lumen`salsa::derived::slot::Slot$LT$DB$C$Q$C$MP$GT$::read::h7071a15bbcdcce00 + 568
    frame #17: 0x00005555572444e8 lumen`_$LT$salsa..derived..DerivedStorage$LT$DB$C$Q$C$MP$GT$$u20$as$u20$salsa..plumbing..QueryStorageOps$LT$DB$C$Q$GT$$GT$::try_fetch::hbd9e367efb7bccc5 + 888
    frame #18: 0x00005555572b0012 lumen`liblumen_compiler::compiler::queries::compile::h6200ec8f72be1cdf + 626
    frame #19: 0x00005555572288f5 lumen`salsa::runtime::Runtime$LT$DB$GT$::execute_query_implementation::hab518cbba333722b + 325
    frame #20: 0x000055555725c90a lumen`salsa::derived::slot::Slot$LT$DB$C$Q$C$MP$GT$::read_upgrade::h3948fe9222884e1d + 2074
    frame #21: 0x0000555557278d22 lumen`salsa::derived::slot::Slot$LT$DB$C$Q$C$MP$GT$::read::h6eb9ff24bd6b912d + 562
    frame #22: 0x0000555557242555 lumen`_$LT$salsa..derived..DerivedStorage$LT$DB$C$Q$C$MP$GT$$u20$as$u20$salsa..plumbing..QueryStorageOps$LT$DB$C$Q$GT$$GT$::try_fetch::h8e210aec83111ba4 + 805
    frame #23: 0x00005555572c455d lumen`_$LT$core..future..from_generator..GenFuture$LT$T$GT$$u20$as$u20$core..future..future..Future$GT$::poll::h22ae25e5b1df644f + 61
    frame #24: 0x00005555572bc6d2 lumen`async_task::raw::RawTask$LT$F$C$R$C$S$C$T$GT$::run::h235a15e492cbf498 + 114
    frame #25: 0x00005555572a7c9c lumen`std::sys_common::backtrace::__rust_begin_short_backtrace::h7e758b03affaa6fb + 92
    frame #26: 0x00005555572beb8e lumen`core::ops::function::FnOnce::call_once$u7b$$u7b$vtable.shim$u7d$$u7d$::h5c51da0d808debbb + 78
    frame #27: 0x0000555559a7cc1a lumen`std::sys::unix::thread::Thread::new::thread_start::h8b0ae441dc3343d4 [inlined] _$LT$alloc..boxed..Box$LT$F$GT$$u20$as$u20$core..ops..function..FnOnce$LT$A$GT$$GT$::call_once::h5b84f52b19042f22 at boxed.rs:1034
    frame #28: 0x0000555559a7cc14 lumen`std::sys::unix::thread::Thread::new::thread_start::h8b0ae441dc3343d4 [inlined] _$LT$alloc..boxed..Box$LT$F$GT$$u20$as$u20$core..ops..function..FnOnce$LT$A$GT$$GT$::call_once::h6e1ef057e35f3144 at boxed.rs:1034
    frame #29: 0x0000555559a7cc0b lumen`std::sys::unix::thread::Thread::new::thread_start::h8b0ae441dc3343d4 at thread.rs:87
    frame #30: 0x00007ffff77b16db libpthread.so.0`start_thread + 219
    frame #31: 0x00007ffff6b9ba3f libc.so.6`clone + 63
(lldb)

Sep 05 '20 18:09 lpil

Duplicate of #572

Sep 24 '20 19:09 bitwalker

Discussed on Dec 9 standup. Assigning to @bitwalker

Dec 09 '20 15:12 bcardarella

I believe this issue should be resolved alongside our other Linux build issues, using the latest on develop and our latest llvm release. See the instructions in the readme for details on setup.

I will close for now, but if there are still issues, follow up using #677, since that issue is explicitly about Windows support, or if you feel a new issue is more appropriate, that's fine as well.

Aug 31 '22 21:08 bitwalker

firefly firefly copied to clipboard

Compilation fails with SIGSEGV on Windows WSL2 (Ubuntu)

firefly
firefly copied to clipboard