SIGSEGV in llvm::SectionMemoryManager

[nixpulvis]

I think I'm linking to LLVM 6 correctly, though my compiler itself depends on my systems llvm-libs which contains .so files, so IDK for sure I guess... Either way this is the error I'm getting on my Arch Linux system ATM.

(gdb) run
Starting program: /home/nixpulvis/Code/axiom/build/editor/backend/standalone/Axiom Standalone
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Starting application
[New Thread 0x7ffff14f7700 (LWP 1009)]
Using data path /home/nixpulvis/.local/share/Axiom
Starting backend
Starting editor

Thread 1 "Axiom Standalon" received signal SIGSEGV, Segmentation fault.
0x0000555555b600ab in std::_Sp_counted_ptr_inplace<llvm::SectionMemoryManager, std::allocator<llvm::SectionMemoryManager>, (__gnu_cxx::_Lock_policy)2>::_M_get_deleter(std::type_info const&) ()

[cpdt]

Hey, thanks for reporting the issue!

The error looks like something’s up deep inside LLVM. Are you able to get a stacktrace for where the segfault is happening? That should help determine if Axiom isn’t playing nicely with LLVM somehow.

[nixpulvis]

Sorry for the slow response, here's the backtrace.

Reading symbols from editor/backend/standalone/Axiom Standalone...done.
(gdb) run
Starting program: /home/nixpulvis/Code/axiom/build/editor/backend/standalone/Axiom Standalone
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Starting application
[New Thread 0x7ffff1681700 (LWP 3444)]
Using data path /home/nixpulvis/.local/share/Axiom
Starting backend
Starting editor

Thread 1 "Axiom Standalon" received signal SIGSEGV, Segmentation fault.
0x0000555555b5ff6b in std::_Sp_counted_ptr_inplace<llvm::SectionMemoryManager, std::allocator<llvm::SectionMemoryManager>, (__gnu_cxx::_Lock_policy)2>::_M_get_deleter(std::type_info const&)
    ()
(gdb) bt
#0  0x0000555555b5ff6b in std::_Sp_counted_ptr_inplace<llvm::SectionMemoryManager, std::allocator<llvm::SectionMemoryManager>, (__gnu_cxx::_Lock_policy)2>::_M_get_deleter(std::type_info const&) ()
#1  0x000055555596bcbe in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::_M_get_deleter(std::type_info const&) const ()
#2  0x0000555557adfd66 in std::__shared_ptr<llvm::SectionMemoryManager, (__gnu_cxx::_Lock_policy)2>::__shared_ptr<std::allocator<llvm::SectionMemoryManager>>(std::_Sp_make_shared_tag, std::allocator<llvm::SectionMemoryManager> const&) ()
#3  0x0000555557add95b in std::shared_ptr<llvm::SectionMemoryManager>::shared_ptr<std::allocator<llvm::SectionMemoryManager>>(std::_Sp_make_shared_tag, std::allocator<llvm::SectionMemoryManager> const&) ()
#4  0x0000555557adb814 in std::shared_ptr<llvm::SectionMemoryManager> std::allocate_shared<llvm::SectionMemoryManager, std::allocator<llvm::SectionMemoryManager>>(std::allocator<llvm::SectionMemoryManager> const&) ()
#5  0x0000555557ad9ccb in std::shared_ptr<llvm::SectionMemoryManager> std::make_shared<llvm::SectionMemoryManager>() ()
#6  0x0000555557ad70b1 in OrcJit::OrcJit(llvm::TargetMachine&)::{lambda()#1}::operator()() const ()
#7  0x0000555557adb8c8 in std::_Function_handler<std::shared_ptr<llvm::RuntimeDyld::MemoryManager> (), OrcJit::OrcJit(llvm::TargetMachine&)::{lambda()#1}>::_M_invoke(std::_Any_data const&)
    ()
#8  0x0000555555b64f3c in llvm::orc::RTDyldObjectLinkingLayer::addObject(std::shared_ptr<llvm::object::OwningBinary<llvm::object::ObjectFile> >, std::shared_ptr<llvm::JITSymbolResolver>) ()
#9  0x0000555555b6924a in llvm::orc::IRCompileLayer<llvm::orc::RTDyldObjectLinkingLayer, llvm::orc::SimpleCompiler>::addModule(std::shared_ptr<llvm::Module>, std::shared_ptr<llvm::JITSymbolResolver>) ()
#10 0x0000555557ad7885 in OrcJit::addModule(std::shared_ptr<llvm::Module>) ()
#11 0x0000555557ad4850 in LLVMAxiomOrcAddModule ()
#12 0x0000555555b449fa in maxim_create_runtime ()
#13 0x0000555555b3fb0a in MaximCompiler::Runtime::Runtime(bool, bool) ()
#14 0x000055555595988a in AxiomGui::MainWindow::MainWindow(AxiomBackend::AudioBackend*) ()
#15 0x000055555594c2e0 in AxiomEditor::AxiomEditor(AxiomApplication*, AxiomBackend::AudioBackend*) ()
#16 0x0000555555948b00 in main ()

[cpdt]

Hey, thanks for the stack trace. That certainly helps to narrow it down, I'm guessing the IR the compiler is providing to LLVM's JIT is invalid somehow in a subtle way, which I have seen cause this kind of problem before. Very possibly something target-specific, since I've never seen this specific issue occur on Windows or Mac.

Are you building it as 32-bit or 64-bit? I'll try to replicate it locally when I get the chance.

[nixpulvis]

Building on a 64-bit Intel machine for the same target. I've had to make just one minor change to get it to build (maybe the issue is with that).

diff --git a/editor/backend/PersistentParameters.h b/editor/backend/PersistentParameters.h
index 60bb1aa..1ce13bd 100644
--- a/editor/backend/PersistentParameters.h
+++ b/editor/backend/PersistentParameters.h
@@ -69,9 +69,9 @@ namespace AxiomBackend {
             stream << (uint32_t) _parameters.size();
             for (const auto &param : _parameters) {
                 if (param) {
-                    stream << (int64_t) param->id;
+                    stream << (qint64) param->id;
                 } else {
-                    stream << (int64_t) -1;
+                    stream << (qint64) -1;
                 }
             }
         }
@@ -82,12 +82,12 @@ namespace AxiomBackend {
                 return PersistentParameters();
             }
 
-            uint32_t parameterCount;
+            quint32 parameterCount;
             stream >> parameterCount;
 
             PersistentParameters parameters;
             for (uint32_t paramIndex = 0; paramIndex < parameterCount; paramIndex++) {
-                int64_t paramId;
+                qint64 paramId;
                 stream >> paramId;
 
                 if (paramId == -1) {

Otherwise, I'm happy to open PRs for Linux if/when this is all working.

[cpdt]

I've pushed a commit to fix those casts, however I haven't had any luck replicating the segfault on Linux (admittedly with WSL, but I don't think that should make a difference?), which is going to make this hard to resolve.

Are you able to make this change, and then provide the contents of the debuglib file in the standalone executable directory? That'll dump the LLVM IR that Axiom generates on startup, which I'm guessing causes the crash.

diff --git a/compiler/src/frontend/runtime.rs b/compiler/src/frontend/runtime.rs
index 4fdce87..3e2698f 100644
--- a/compiler/src/frontend/runtime.rs
+++ b/compiler/src/frontend/runtime.rs
@@ -146,6 +146,8 @@ impl Runtime {
         // deploy the library to the JIT
         let library_module = Runtime::codegen_lib(&context, &target);
         optimizer.optimize_module(&library_module);
+        use std::path::Path;
+        library_module.print_to_file(Path::new("debug")).unwrap();
         jit.deploy(&library_module);
         let library_pointers = LibraryPointers::new(&jit);