I've been using lli to do most of my unit tests for the compiler that I'm writing. However, when I get a test that crashes, its difficult to find which instruction it was that caused the crash. I tried running bugpoint, but it didn't seem to work for me, and upon reading the documentation, it seems to be intended for a different purpose than finding bugs in my source program; It seems to be related more to finding errors in the various optimizer passes. So for example, when I run lli on my program: ---------------------------------------------------------- Assertion failed: (V == V2 && "Didn't find key?"), function RemoveKey, file StringMap.cpp, line 177. 0 lli 0x0049edcd _ZN40_GLOBAL__N_Signals.cpp_00000000_B58D0A3815PrintStackTraceEv + 45 1 lli 0x0049efc9 _ZN40_GLOBAL__N_Signals.cpp_00000000_B58D0A3813SignalHandlerEi + 323 2 libSystem.B.dylib 0x9534297b _sigtramp + 43 3 ??? 0xffffffff 0x0 + 4294967295 4 libSystem.B.dylib 0x953bb782 raise + 26 5 libSystem.B.dylib 0x953cad3f abort + 73 6 libSystem.B.dylib 0x953bc923 __assert_rtn + 101 7 lli 0x00491ca7 _ZN4llvm13StringMapImpl9RemoveKeyEPNS_18StringMapEntryBaseE + 127 8 lli 0x00461946 _ZN4llvm9StringMapIPNS_5ValueENS_15MallocAllocatorEE6removeEPNS_14StringMapEntryIS2_EE + 24 9 lli 0x00461094 _ZN4llvm16ValueSymbolTable15removeValueNameEPNS_14StringMapEntryIPNS_5ValueEEE + 24 10 lli 0x0040aabe _ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE18removeNodeFromListEPS1_ + 94 11 lli 0x003cbd66 _ZN4llvm6iplistINS_10BasicBlockENS_12ilist_traitsIS1_EEE6removeERNS_14ilist_iteratorIS1_EE + 254 ...etc... ---------------------------------------------------------- But when I run bugpoint, I get: ---------------------------------------------------------- Read input file : 'out/Debug/test/stdlib/test08.bcc' *** All input ok Found gcc: /usr/bin/gcc Initializing execution environment: Running the code generator to test for a crash: <cbe> Generating reference output from raw program: <cbe><cbe><gcc><program>Reference output is: bugpoint.reference.out *** Checking the code generator... <cbe><gcc><program> *** Debugging miscompilation! Checking to see if '' compile correctly: <cbe><gcc><program> yup. *** Optimized program matches reference output! No problem detected... bugpoint can't help you with your problem! ---------------------------------------------------------- To be honest, I am not sure what this all means. In any case, what I'd like is a way to find out more about the source of the crash. I don't suppose anyone is working on a version of lli that supports single-step debugging from the command line? Or do I need to compile to assembly and use gdb? What's the best strategy for solving this type of problem? -- Talin
Ping? Still looking for advice in figuring out how and why my generated code is causing lli to crash... Talin wrote:> I've been using lli to do most of my unit tests for the compiler that > I'm writing. However, when I get a test that crashes, its difficult to > find which instruction it was that caused the crash. I tried running > bugpoint, but it didn't seem to work for me, and upon reading the > documentation, it seems to be intended for a different purpose than > finding bugs in my source program; It seems to be related more to > finding errors in the various optimizer passes. > > So for example, when I run lli on my program: > ---------------------------------------------------------- > Assertion failed: (V == V2 && "Didn't find key?"), function RemoveKey, > file StringMap.cpp, line 177. > 0 lli 0x0049edcd > _ZN40_GLOBAL__N_Signals.cpp_00000000_B58D0A3815PrintStackTraceEv + 45 > 1 lli 0x0049efc9 > _ZN40_GLOBAL__N_Signals.cpp_00000000_B58D0A3813SignalHandlerEi + 323 > 2 libSystem.B.dylib 0x9534297b _sigtramp + 43 > 3 ??? 0xffffffff 0x0 + 4294967295 > 4 libSystem.B.dylib 0x953bb782 raise + 26 > 5 libSystem.B.dylib 0x953cad3f abort + 73 > 6 libSystem.B.dylib 0x953bc923 __assert_rtn + 101 > 7 lli 0x00491ca7 > _ZN4llvm13StringMapImpl9RemoveKeyEPNS_18StringMapEntryBaseE + 127 > 8 lli 0x00461946 > _ZN4llvm9StringMapIPNS_5ValueENS_15MallocAllocatorEE6removeEPNS_14StringMapEntryIS2_EE > + 24 > 9 lli 0x00461094 > _ZN4llvm16ValueSymbolTable15removeValueNameEPNS_14StringMapEntryIPNS_5ValueEEE > + 24 > 10 lli 0x0040aabe > _ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE18removeNodeFromListEPS1_ > + 94 > 11 lli 0x003cbd66 > _ZN4llvm6iplistINS_10BasicBlockENS_12ilist_traitsIS1_EEE6removeERNS_14ilist_iteratorIS1_EE > + 254 > ...etc... > ---------------------------------------------------------- > > But when I run bugpoint, I get: > ---------------------------------------------------------- > Read input file : 'out/Debug/test/stdlib/test08.bcc' > *** All input ok > Found gcc: /usr/bin/gcc > Initializing execution environment: Running the code generator to test > for a crash: <cbe> > Generating reference output from raw program: > <cbe><cbe><gcc><program>Reference output is: bugpoint.reference.out > > *** Checking the code generator... > <cbe><gcc><program> > *** Debugging miscompilation! > Checking to see if '' compile correctly: <cbe><gcc><program> yup. > *** Optimized program matches reference output! No problem detected... > bugpoint can't help you with your problem! > ---------------------------------------------------------- > > To be honest, I am not sure what this all means. > > In any case, what I'd like is a way to find out more about the source > of the crash. > > I don't suppose anyone is working on a version of lli that supports > single-step debugging from the command line? Or do I need to compile > to assembly and use gdb? What's the best strategy for solving this > type of problem? > > -- Talin > >
There is simply not enough information here to make an educated guess. But I'd say this is most likely not an optimization issue. Can you run lli in gdb to see where it is failing? Also you can add command line option -debug-only=jit. That should tell you which function is tripping lli up. Evan On Mar 31, 2008, at 8:54 PM, Talin wrote:> Ping? Still looking for advice in figuring out how and why my > generated > code is causing lli to crash... > > Talin wrote: >> I've been using lli to do most of my unit tests for the compiler that >> I'm writing. However, when I get a test that crashes, its difficult >> to >> find which instruction it was that caused the crash. I tried running >> bugpoint, but it didn't seem to work for me, and upon reading the >> documentation, it seems to be intended for a different purpose than >> finding bugs in my source program; It seems to be related more to >> finding errors in the various optimizer passes. >> >> So for example, when I run lli on my program: >> ---------------------------------------------------------- >> Assertion failed: (V == V2 && "Didn't find key?"), function >> RemoveKey, >> file StringMap.cpp, line 177. >> 0 lli 0x0049edcd >> _ZN40_GLOBAL__N_Signals.cpp_00000000_B58D0A3815PrintStackTraceEv + 45 >> 1 lli 0x0049efc9 >> _ZN40_GLOBAL__N_Signals.cpp_00000000_B58D0A3813SignalHandlerEi + 323 >> 2 libSystem.B.dylib 0x9534297b _sigtramp + 43 >> 3 ??? 0xffffffff 0x0 + 4294967295 >> 4 libSystem.B.dylib 0x953bb782 raise + 26 >> 5 libSystem.B.dylib 0x953cad3f abort + 73 >> 6 libSystem.B.dylib 0x953bc923 __assert_rtn + 101 >> 7 lli 0x00491ca7 >> _ZN4llvm13StringMapImpl9RemoveKeyEPNS_18StringMapEntryBaseE + 127 >> 8 lli 0x00461946 >> _ZN4llvm9StringMapIPNS_5ValueENS_15MallocAllocatorEE6removeEPNS_14StringMapEntryIS2_EE >> + 24 >> 9 lli 0x00461094 >> _ZN4llvm16ValueSymbolTable15removeValueNameEPNS_14StringMapEntryIPNS_5ValueEEE >> + 24 >> 10 lli 0x0040aabe >> _ZN4llvm21SymbolTableListTraitsINS_10BasicBlockENS_8FunctionEE18removeNodeFromListEPS1_ >> + 94 >> 11 lli 0x003cbd66 >> _ZN4llvm6iplistINS_10BasicBlockENS_12ilist_traitsIS1_EEE6removeERNS_14ilist_iteratorIS1_EE >> + 254 >> ...etc... >> ---------------------------------------------------------- >> >> But when I run bugpoint, I get: >> ---------------------------------------------------------- >> Read input file : 'out/Debug/test/stdlib/test08.bcc' >> *** All input ok >> Found gcc: /usr/bin/gcc >> Initializing execution environment: Running the code generator to >> test >> for a crash: <cbe> >> Generating reference output from raw program: >> <cbe><cbe><gcc><program>Reference output is: bugpoint.reference.out >> >> *** Checking the code generator... >> <cbe><gcc><program> >> *** Debugging miscompilation! >> Checking to see if '' compile correctly: <cbe><gcc><program> yup. >> *** Optimized program matches reference output! No problem >> detected... >> bugpoint can't help you with your problem! >> ---------------------------------------------------------- >> >> To be honest, I am not sure what this all means. >> >> In any case, what I'd like is a way to find out more about the source >> of the crash. >> >> I don't suppose anyone is working on a version of lli that supports >> single-step debugging from the command line? Or do I need to compile >> to assembly and use gdb? What's the best strategy for solving this >> type of problem? >> >> -- Talin >> >> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> Ping? Still looking for advice in figuring out how and why my generated > code is causing lli to crash...Did you run your code through the verifier?> > So for example, when I run lli on my program: > > ---------------------------------------------------------- > > Assertion failed: (V == V2 && "Didn't find key?"), function RemoveKey, > > file StringMap.cpp, line 177.This looks like either an lli bug, or invalid bitcode (see my remark on the verifier above). If it passes the verifier, please reduce a testcase and open a bug report. How were you running lli by the way - interpreter or jit?> > But when I run bugpoint, I get:...> > bugpoint can't help you with your problem! > > ---------------------------------------------------------- > > > > To be honest, I am not sure what this all means.It means that the problem is lli specific. Try running bugpoint with -run-int or -run-jit (depending on whether you were using the JIT or the interpreter version of lli). Ciao, Duncan.