Some help for those developing under linux

After breaking the code that I was working on in such a way that Torque hung the X mouse cursor, I came up with a simple way to dump the stack to a file in the case of a segfault. Since some of you may hit similar problems, or have bugs that only segfault during runtime, and not under gdb, I thought I would post it for everyone. I'd post it as a resource, but this will only work under linux (possibly OSX).

Fire up your editor of choice and open up: paltformX86UNIX/x86UNIXProcessControl.cc

At the top after the includes Add:

#include

Then, just before the function:

static void SignalHandler( int sigtype )

Add:

static void dumpStack() {
void *syms[64];
FILE *dump;
int step, num_syms;

dump = fopen( "Dump.txt", "w+");
num_syms = backtrace( syms, 64 );

for( step = 3; step < num_syms; step++ ) {
fprintf( dump, "%p\n", syms[step] );
}
fclose( dump );
}

Then in the SignalHandler function just after the line:

signal(SIGTRAP, SIG_DFL );

Add:

if( sigtype == SIGSEGV ) {
dumpStack();
}

Compile, and you are ready to crash....

So, your code runs, segfaults, and spits out some text to Dump.txt, for example you might get something like:

0x81e7ef9
0x81e86da
.....
0x5579a7f8

which means nothing to you, so open up the editor again, and in your example directory create viewdump.sh which contains:

#!/bin/sh
cat Dump.txt | addr2line -e torqueDemo_Debug.bin

Then do a "chmod a+x viewdump.sh", and run ./viewdump.sh
Now you get something like:

game/ODESimpleObject.cc:271
game/ODESimpleObject.cc:380
game/ODESimpleObject.ccc:478
game/gameProcess.cc:246
...
platformX86UNIX/x86UNIXWindow.cc:886
??:0

which is the stack trace for the program at the time it segfaulted.

This won't save your project, but it will at least point you to where you problems are.