Segmentation fault trying to run oclgrind on MacOS

[romix]

Hi,

I'm trying to run oclgrind under MacOS. But the tool segfaults almost immediately after start. I tried the prebuilt binary and my own build. Both crash in the same way. Any ideas?

Here is the trace under LLDB:

* thread #2, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x30)
    frame #0: 0x0000000104734e10 liboclgrind.dylib`llvm::PMTopLevelManager::addImmutablePass(llvm::ImmutablePass*) + 192
liboclgrind.dylib`llvm::PMTopLevelManager::addImmutablePass:
->  0x104734e10 <+192>: movq   0x30(%rax), %r12
    0x104734e14 <+196>: movq   0x38(%rax), %r13
    0x104734e18 <+200>: cmpq   %r13, %r12
    0x104734e1b <+203>: jne    0x104734e71               ; <+289>
Target 0: (loader) stopped.
(lldb) bt
* thread #2, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x30)
  * frame #0: 0x0000000104734e10 liboclgrind.dylib`llvm::PMTopLevelManager::addImmutablePass(llvm::ImmutablePass*) + 192
    frame #1: 0x0000000104734805 liboclgrind.dylib`llvm::PMTopLevelManager::schedulePass(llvm::Pass*) + 2021
    frame #2: 0x0000000104734736 liboclgrind.dylib`llvm::PMTopLevelManager::schedulePass(llvm::Pass*) + 1814
    frame #3: 0x000000010488c92b liboclgrind.dylib`llvm::PassManagerBuilder::populateModulePassManager(llvm::legacy::PassManagerBase&) + 299
    frame #4: 0x0000000103992ce8 liboclgrind.dylib`clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*, clang::BackendAction, std::__1::unique_ptr<llvm::raw_pwrite_stream, std::__1::default_delete<llvm::raw_pwrite_stream> >) + 15336
    frame #5: 0x0000000103b532f1 liboclgrind.dylib`clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 961
    frame #6: 0x0000000103c0f482 liboclgrind.dylib`clang::ParseAST(clang::Sema&, bool, bool) + 466
    frame #7: 0x00000001037441f3 liboclgrind.dylib`clang::FrontendAction::Execute() + 67
    frame #8: 0x00000001036feed8 liboclgrind.dylib`clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 1096
    frame #9: 0x000000010366f31b liboclgrind.dylib`oclgrind::Program::build(char const*, std::__1::list<std::__1::pair<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, oclgrind::Program const*>, std::__1::allocator<std::__1::pair<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, oclgrind::Program const*> > >) + 5467
    frame #10: 0x0000000102eef4ee liboclgrind-rt.dylib`clBuildProgram + 1854
    frame #11: 0x00000001001d5d1c loader`createProgram(this=0x0000000105d91a30, source="kernel source is here"..., options=size=1, queue=0x0000000105d92a90) at testopencl.cpp:163
   [snip]
    frame #18: 0x0000000100006221 loader`main(argc=6, argv=0x00007ffeefbff460) at loader.cpp:237
    frame #19: 0x00007fff5d851015 libdyld.dylib`start + 1

[jrprice]

Hmm. When you did you own build, did you try running make test? Have you tried any other OpenCL codes? Just trying to work out whether it's just crashing for this one code or for everything.

[romix]

I tried "make test" and there are no failures.

[romix]

My app is using LLVM as a library internally (it does some JITting). And oclgrind is using LLVM as well. Could it be that there is some kind of conflict because of that?

Or may be there are other things worth checking?

[jrprice]

Ah yes, all sorts of strange things tend to happen when there are multiple users of LLVM in play. If Oclgrind is working fine with other codes, then this is likely to be the issue.

Unfortunately I'm not sure there are any workarounds. Presumably your application is using the same version of LLVM that you built Oclgrind against?

[romix]

Presumably your application is using the same version of LLVM that you built Oclgrind against?

Yes. I also tried with another version, but got the same kind of crash.