[LLVMdev] Crash in llvm::JITDwarfEmitter::EmitDwarfTable on 2.8 and 2.9 release but not on trunk?

Christophe de Dinechin christophe at taodyne.com
Tue Apr 19 08:38:39 PDT 2011


I'd like some advice on a crash that we have observed on MacOSX with the 2.8 and 2.9 releases of LLVM, but not on the top of trunk. The crash is a null-deref in llvm::JITDwarfEmitter::EmitDwarfTable :

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
0x0000000100852203 in llvm::JITDwarfEmitter::EmitDwarfTable () at context.h:491
(gdb) bt
#0  0x0000000100852203 in llvm::JITDwarfEmitter::EmitDwarfTable () at context.h:491
#1  0x0000000100859a76 in (anonymous namespace)::JITEmitter::finishFunction () at context.h:491
#2  0x0000000100871a6a in (anonymous namespace)::Emitter<llvm::JITCodeEmitter>::runOnMachineFunction () at stl_tree.h:1050
#3  0x0000000100b1381d in llvm::MachineFunctionPass::runOnFunction () at stl_tree.h:1050
#4  0x0000000100ee15f0 in llvm::FPPassManager::runOnFunction () at stl_tree.h:1050
#5  0x0000000100ee178c in llvm::FunctionPassManagerImpl::run () at stl_tree.h:1050
#6  0x0000000100ee1a79 in llvm::FunctionPassManager::run () at stl_tree.h:1050
#7  0x000000010084a29a in llvm::JIT::jitTheFunction () at context.h:491
#8  0x000000010084a821 in llvm::JIT::getPointerToFunction () at context.h:491
#9  0x00000001007924cc in XL::OCompiledUnit::Finalize (this=0x7fff5fbfdee0) at ../tao/xlr/xlr/symbols.cpp:2359
#10 0x000000010079a2dc in XL::Symbols::CompileAll (this=0x10572b740, source=0x104890200, nullIfBad=false, keepAlternatives=false, noData=false) at ../tao/xlr/xlr/symbols.cpp:375
[From there on, it's our stuff, snip]

I first observed this with the 2.8 release tag, and now again on the 2.9 release tag, but not with any top-of-trunk I tried (currently, r129756).

The problem goes away if our code does not set JITEmitDebugInfo to true.

If I install the 2.9 release and do not rebuild our code, there is no crash either. This seems to imply that the problem is somewhere in the header files.

Did anybody else see something similar? Are we doing something incorrect that the verifier and asserts don't catch?3

To reproduce :

- git clone git://xlr.git.sourceforge.net/gitroot/xlr/xlr
- cd xlr/xlr
- export BUILDENV=macosx
- make
- gdb ./xl
- r tests/00.Parser/bug346.xl (practically any other test in the test suite will do)


More information about the llvm-dev mailing list