How to get a good Stack Trace for debugging crashes
There are several obstacles to this which need worked around:
Open a bash shell, and go to the X3 source directory (Where you run ./configure from)
First, set CFLAGS not to include -O2, but to still include symbols:
$ export CFLAGS='-g'
Then, re-run your ./configure command, but add --enable-debug to allow X3 to be run in debug mode. (Hint: the last configure arguments you used are at the top of config.log if you forgot them!)
$ head config.log #Just to remind me what configure arguments i used last
$ ./configure --prefix=/home/rubin/x3 --enable-modules=memoserv,snoop --enable-debug #Only the modules you are using though
Now confirm that this worked: Open src/Makefile and searh for "-O2" (thats capital oh, two) and make sure there is not a line something like "CFLAGS=-g -O2 ..." in it.
Then compile and install X3:
$ make clean
$ make install
Now your version of X3 is re-compiled without all the magical changes by the C compiler that make following allong with code execution hard. Now we run X3 in the gdb debugger:
Change to where you run X3 from:
$ cd /home/rubin/x3
Run gdb on the x3 binary:
$ gdb x3 # Or maybe bin/x3? Wherever you told configure to put things...
Now you get a gdb prompt like this. Setup X3 to run:
(gdb) set args -d -f
And finally, run X3 inside gdb
(gdb) run
Now just do whatever it is you normally do to cause the crash. Instead of crashing, gdb will tell you about the prompt, and let you examine what happened. X3 wont even split from your network until you tell gdb to continue.
Program received signal SIGSEG, Segmentation Fault
followed by a bunch of other information. Now is the magic: Give the command:
(gdb) bt full
This will print out the full path the code took to get to where it crashed. We can use this information to help you figure out where things went wrong, or fix a bug with X3. Send us a cut and paste of this backtrace.
When you are done:
$ CFLAGS=''
and re-run configure, make clean, make install.
Thanks!