Christophe de Dinechin
2011-Apr-19 15:38 UTC
[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
Christophe de Dinechin
2011-Apr-19 16:49 UTC
[LLVMdev] Crash in llvm::JITDwarfEmitter::EmitDwarfTable on 2.8 and 2.9 release but not on trunk?
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
Reid Kleckner
2011-Apr-20 04:49 UTC
[LLVMdev] Crash in llvm::JITDwarfEmitter::EmitDwarfTable on 2.8 and 2.9 release but not on trunk?
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 >