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

[Reid Kleckner]

The assumption was that JITEmitDebugInfo is controlled by a command
line flag, so it should be set at initialization time and never
change.  Where ever you are wrapping LLVM's command line parsing logic
you can feed it -jit-emit-debug to get it to do the right thing.

Reid

On Tue, Apr 19, 2011 at 12:49 PM, Christophe de Dinechin
<christophe at taodyne.com> wrote:
> I found the problem : my code sets JITEmitDebugInfo after creating the JIT. This causes the JITDwarfEmitter DE to not be constructed in the ctor of JITEmitter (JITEmitter.cpp around line 375).
>
> Not sure if it's documented anywhere that JITEmitDebugInfo must be set before constructing the JIT, but looking at the code, it makes sense. Easy enough to fix on my side.
>
>
> Christophe
>
> On 19 avr. 2011, at 17:38, Christophe de Dinechin wrote:
>
>> Hello,
>>
>>
>> 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)
>>
>>
>> Thanks
>> Christophe
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>