Debugging the easy way

I had occasion again to debug my code , as I like to stress things until they break. The easy answer is what I have blogged about before. They are here sighandler.c and here to get symbols from the file.

signal_segv
/home/moteyhardy/Desktop/src/autodist/puzzler/puzzler_sighandler.c:114
generateRules
/home/moteyhardy/Desktop/src/autodist/puzzler/puzzler_game.c:174
createPuzzle
/home/moteyhardy/Desktop/src/autodist/puzzler/puzzler_game.c:107
main
/home/moteyhardy/Desktop/src/autodist/puzzler/puzzler.c:218
_start

This gives me the line where the fault occurs. I looked at this code again and it is strange, but now it is vastly more clear. Before the register issues were like old friends, the address conversion was familiar, but the code itself and some of the hoops that have to be cleared for gcc, C, symbol conflicts, multiple systems, and such were like voodoo and now they are old friends and the process is very clear. This will be a useful tool to include on option with the "-g" to include debug symbols. I am really pleased, as this saves a lot of debug time as I can go directly to the file that causes the fault at the line where it happens. If I can get that close I can invariably see what is causing the fault without going to gdb.

I wish I had continued to use this code. The problem was that I could not maintain it then as it was too complex, and now it seems simple. What a difference a year of experience makes.

And so it is, 30 seconds and I have the answer. It took 10 minutes to make this post and 30 seconds to find the err line, fix the flaw, recompile, and test. This is a sweet way to debug and I will certainly keep this code close and warm.

I used this and did some more stressing of the limits of the code and found another flaw. I thought the code was clean. I had an array index that was weakly defined in the code and it produced results that were not immediately obvious, because it was applied once and then reapplied properly later in the code. It required a use of that in the period when it was in an indeterminate state. Those kind of bugs are tough to pin down when they happen. It makes me feel more confident about this code. So here is a section of that code I use and it is all in the game that I will tar up and save to Google when I feel it is clean enough. bt is an array of "back traces", the stack. syscom is the string that I use to pass the command to the system, thus "sys"=system "com"=command. The code must be compiled with "-g" so that debug symbols are present. This makes the code slower, usually. The range to 0x42 is arbitrary and your code size will certainly be different, I suppose I could have made some auto-magic to find the last line of code, but I am merely a mortal.

if ( bt[i] < (void *)0x420000 && bt[i] > (void *)0x400000)
 {
 sprintf(syscom,"addr2line %p -f -e puzzler",bt[i]);
 system(syscom);
 }