Debugaroos

The picture is just to keep people entertained while I talk about debugging for the secret guild of the infinite cats and the long long %p sight that reads machine code. The image is something from blender that I was testing with my model render extension.

So I learned a few new things and I will give a link to the free source code that can be integrated into a package so you can get this info when developing. The link at Tux Linux User Group has some code and explanation of stack frames and signal interception code.

What I learned while including some code from another source is that it can be more useful when applied with some extras.

This is used on the dissassembled source to find a reference in a specific address range.

cat antsd.dsm | grep ' 403a'

This is used to dissassemble source in Intel format.

objdump -S prog -M intel >antsd.dsm

This is used to dissassemble source in ATT format.

objdump -S prog >antsd.dsm

This is just too cool. It gives you the file and line of the source.

addr2line 404840 -f -e antfarmgl

If you include this in your source code:

system('addr2line $codeaddress -f -e antfarmgl');

Then it will display to STDOUT during the SIGSEGV ( or whatever SIG ) handler

ADDED: For those of who NEED to know: Here is a link to explain what it does at KERNEL.ORG and here is some code for extending SIGSEGV handler, with quick fix code lines to lookup.

sz = backtrace(bt, 30);
strings = backtrace_symbols(bt, sz);
sprintf(syscom,"addr2line %x -f -e antfarmgl",bt[0]);
system(syscom);

So what this does ( in technical terms ) is create a command to find where the f'up is, with the doo doo that is on the stack.

ADDED MORE:

for (i=0; i < sz; i++)
{
if ( bt[i] < (void *)0x40a000 && bt[i] > (void *)0x400000)
 {
 sprintf(syscom,"addr2line %p -f -e antfarmgl",bt[i]);
 system(syscom);
 }
};

This is probably a little better WORSE. I wouldn't recommend this method to anybody (except the truly and deeply masochistic). It can lead to some recursion and double faults and glibc issues that could make things more difficult to diagnose. It is better to trap stderr to a file and extract the information there, if you want it automated. Your mileage may vary. I was using "kate" editor, with its own terminal shell ( which it does some odd thing to ), doing "pipe to console" from a script, opening 2 simultaneous glx contexts, using ATI fglrx, openGL, and then running auto debug SIGSEGV with a second shell from within a crashed program. I think I just confused myself quite enough for today.