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

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

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

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
>