Hi,
Today I've been trying to debug a weird bug that makes JIT crash with
certain code and when using the inliner. This may sound weird, but if I
disable the inliner, it doesn't crash.
I include an example gdb dump below. Does something looks wrong? Do you
think it's a bug in JIT or it's just some other piece of code that is
writing on the JIT memory?.. I don't really know how to debug this..
Any help/tips/whatever would be greatly appreciated.
Thanks,
Nuno
---------------------
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7531910 (LWP 22213)]
0xb7798cec in memcpy () from /lib/libc.so.6
(gdb) bt
#0 0xb7798cec in memcpy () from /lib/libc.so.6
#1 0xb76d2942 in std::string::_S_copy_chars () from
/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libstdc++.so.6
#2 0xb7302315 in std::string::_S_construct<char const*> (__beg=0x9fe020c
"!I4\thC6\tH#6\nçÃ6\npÆF·+", __end=0x13344334 <Address 0x13344334
out of
bounds>,
__a=@0xbf856e3f) at
/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include/g++-v4/bits/basic_string.tcc:152
#3 0xb7302361 in std::string::_S_construct_aux<char const*>
(__beg=0x9fe020c "!I4\thC6\tH#6\nçÃ6\npÆF·+", __end=0x13344334
<Address
0x13344334 out of bounds>,
__a=@0xbf856e3f) at
/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include/g++-v4/bits/basic_string.h:1449
#4 0xb730238b in std::string::_S_construct<char const*> (__beg=0x9fe020c
"!I4\thC6\tH#6\nçÃ6\npÆF·+", __end=0x13344334 <Address 0x13344334
out of
bounds>,
__a=@0xbf856e3f) at
/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include/g++-v4/bits/basic_string.h:1464
#5 0xb73023ad in basic_string<const char*> (this=0xbf856eb4,
__beg=0x9fe020c "!I4\thC6\tH#6\nçÃ6\npÆF·+", __end=0x13344334
<Address
0x13344334 out of bounds>,
__a=@0xbf856e3f) at
/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include/g++-v4/bits/basic_string.tcc:241
#6 0xb730198b in llvm::Value::getNameStr (this=0x9344910) at Value.cpp:162
#7 0xb6d8c641 in llvm::Value::getName (this=0x9344910) at
/cvs/llvm/include/llvm/Value.h:110
#8 0xb6f241c7 in (anonymous namespace)::JITResolver::JITCompilerFn
(Stub=0xb5667620) at JITEmitter.cpp:267
#9 0xb6de70e4 in X86CompilationCallback2 (StackPtr=0xbf856f60,
RetAddr=-1251576288) at X86JITInfo.cpp:350
#10 0xb6de6d31 in X86CompilationCallback_SSE () from phpllvm.so
#11 0xb5667624 in ?? ()
#12 0x0a295548 in ?? ()
#13 0x00000001 in ?? ()
#14 0x0a2920d0 in ?? ()
#15 0x00000000 in ?? ()
(gdb) up 8
#8 0xb6f241c7 in (anonymous namespace)::JITResolver::JITCompilerFn
(Stub=0xb5667620) at JITEmitter.cpp:267
267 << I->first << "\n";
(gdb) p *F
$1 = {<llvm::GlobalValue> = {<llvm::Constant> = {<llvm::User>
=
{<llvm::Value> = {_vptr.Value = 0x9fd1708, SubclassID = 0, SubclassData =
0,
VTy = {Ty = 0x9fd1716},
UseList = 0x9364128, Name = 0x9fe0204}, OperandList = 0xa36c3d9,
NumOperands = 167583628}, <No data fields>}, Parent = 0x0, Linkage = 27,
Visibility = 0,
Alignment = 64063, Section = {static npos = 4294967295,
_M_dataplus = {<std::allocator<char>> =
{<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No
data fields>},
_M_p = 0xb746c670
"TÉ,·\"É,·\222''·\204ò'·Ìâ+·"}}},
<llvm::Annotable> = {AnnotationList = 0x2b},
<llvm::ilist_node<llvm::Function>> = {Prev = 0x930e810,
Next = 0x9fe0a80},
BasicBlocks = {<llvm::ilist_traits<llvm::BasicBlock>> =
{<llvm::SymbolTableListTraits<llvm::BasicBlock,llvm::Function>> =
{<llvm::ilist_default_traits<llvm::BasicBlock>> =
{<llvm::ilist_nextprev_traits<llvm::BasicBlock>> = {<No data
fields>},
<llvm::ilist_sentinel_traits<llvm::BasicBlock>> = {<No data
fields>}, <No
data fields>}, <No data fields>}, <No data fields>}, Head =
0xa36c018},
ArgumentList = {<llvm::ilist_traits<llvm::Argument>> =
{<llvm::SymbolTableListTraits<llvm::Argument,llvm::Function>> =
{<llvm::ilist_default_traits<llvm::Argument>> =
{<llvm::ilist_nextprev_traits<llvm::Argument>> = {<No data
fields>},
<llvm::ilist_sentinel_traits<llvm::Argument>> = {<No data
fields>}, <No data
fields>}, <No data fields>}, <No data fields>}, Head =
0x9344910}, SymTab =
0x3, ParamAttrs = {PAList = 0x9fd1f8c}}
Hi,> Today I've been trying to debug a weird bug that makes JIT crash with > certain code and when using the inliner. This may sound weird, but if I > disable the inliner, it doesn't crash. > I include an example gdb dump below. Does something looks wrong? Do you > think it's a bug in JIT or it's just some other piece of code that is > writing on the JIT memory?.. I don't really know how to debug this..my guess is that the code you are jitting is scribbling over memory.> Any help/tips/whatever would be greatly appreciated.Try running under valgrind. Ciao, Duncan.
>> Today I've been trying to debug a weird bug that makes JIT crash with >> certain code and when using the inliner. This may sound weird, but if I >> disable the inliner, it doesn't crash. >> I include an example gdb dump below. Does something looks wrong? Do you >> think it's a bug in JIT or it's just some other piece of code that is >> writing on the JIT memory?.. I don't really know how to debug this.. > > my guess is that the code you are jitting is scribbling over > memory.ok, so, my previous code was making bad things, because it was writing the bitcode to file after each function translation. The problem is that WriteBitcodeToFile() releases the memory and thus the 2nd compilation would have pointers to IR that had been already freed. After fixing this problem in my code, I still get the very same problem: the program crashes when I run the inliner. Running valgrind on the program without the inliner doesn't show any error. If I run the program with the inliner (just uncoment 1 line), valgrind gives a few errors. Example of one of the errors: ==11384== Invalid read of size 4 ==11384== at 0x54B6F04: llvm::StringMapEntryBase::getKeyLength() const (StringMap.h:47) ==11384== by 0x59C6CFD: llvm::Value::getNameStr() const (Value.cpp:162) ==11384== by 0x544FE54: llvm::Value::getName() const (Value.h:110) ==11384== by 0x55E7DA8: (anonymous namespace)::JITResolver::JITCompilerFn(void*) (JITEmitter.cpp:269) ==11384== by 0x54AA47B: X86CompilationCallback2 (X86JITInfo.cpp:350) ==11384== by 0x54AA0C8: (within /usr/local/lib/php/extensions/no-debug-non-zts-20071006/phpllvm.so) ==11384== by 0x8F74D78: ??? ==11384== by 0x55E15BF: llvm::JIT::runFunction(llvm::Function*, std::vector<llvm::GenericValue, std::allocator<llvm::GenericValue> > const&) (JIT.cpp:323) ==11384== by 0x544D9B6: phpllvm::execute(_zend_op_array*) (phpllvm_execute.cpp:200) ==11384== by 0x8FA3365: ??? ==11384== by 0x55E15BF: llvm::JIT::runFunction(llvm::Function*, std::vector<llvm::GenericValue, std::allocator<llvm::GenericValue> > const&) (JIT.cpp:323) ==11384== by 0x544D9B6: phpllvm::execute(_zend_op_array*) (phpllvm_execute.cpp:200) ==11384== Address 0x5ec7778 is 0 bytes inside a block of size 32 free'd ==11384== at 0x402266C: operator delete(void*) (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) ==11384== by 0x54C5034: __gnu_cxx::new_allocator<llvm::SDValue>::deallocate(llvm::SDValue*, unsigned) (new_allocator.h:96) ==11384== by 0x54C505E: std::_Vector_base<llvm::SDValue, std::allocator<llvm::SDValue> >::_M_deallocate(llvm::SDValue*, unsigned) (stl_vector.h:133) ==11384== by 0x54C5097: std::_Vector_base<llvm::SDValue, std::allocator<llvm::SDValue> >::~_Vector_base() (stl_vector.h:119) ==11384== by 0x54C50F9: std::vector<llvm::SDValue, std::allocator<llvm::SDValue> >::~vector() (stl_vector.h:272) ==11384== by 0x5683471: llvm::SelectionDAGLowering::~SelectionDAGLowering() (SelectionDAGISel.cpp:496) ==11384== by 0x567683D: llvm::SelectionDAGISel::BuildSelectionDAG(llvm::SelectionDAG&, llvm::BasicBlock*, std::vector<std::pair<llvm::MachineInstr*, unsigned>, std::allocator<std::pair<llvm::MachineInstr*, unsigned> > >&, llvm::FunctionLoweringInfo&) (SelectionDAGISel.cpp:5252) ==11384== by 0x56768C0: llvm::SelectionDAGISel::SelectBasicBlock(llvm::BasicBlock*, llvm::MachineFunction&, llvm::FunctionLoweringInfo&, std::vector<std::pair<llvm::MachineInstr*, unsigned>, std::allocator<std::pair<llvm::MachineInstr*, unsigned> > >&, llvm::RecyclingAllocator<llvm::BumpPtrAllocator, llvm::SDNode, 136, 4>&) (SelectionDAGISel.cpp:5469) ==11384== by 0x5676A14: llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function&, llvm::MachineFunction&, llvm::FunctionLoweringInfo&) (SelectionDAGISel.cpp:5452) ==11384== by 0x5677609: llvm::SelectionDAGISel::runOnFunction(llvm::Function&) (SelectionDAGISel.cpp:4904) ==11384== by 0x54C4BCC: (anonymous namespace)::X86DAGToDAGISel::runOnFunction(llvm::Function&) (X86ISelDAGToDAG.cpp:123) ==11384== by 0x59A59CF: llvm::FPPassManager::runOnFunction(llvm::Function&) (PassManager.cpp:1260) Does this error makes sense to anyone? Thanks, Nuno