Advice on debugging?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Advice on debugging?

Talin-3
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
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Advice on debugging?

Talin-3
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
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Advice on debugging?

Evan Cheng-2
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
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Advice on debugging?

Duncan Sands
In reply to this post by Talin-3
> 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.
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Advice on debugging?

Talin-3
Duncan Sands wrote:
>> 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?
>  
Yes I did. And llvm-dis has no problem printing out the disassembled code.

>>> 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?
>  
I get the same result with -force-interpreter and without.

I'll file a bug as suggested.

>>> 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.
>  
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev