OP25

h1. Debugging Segmentation Faults

Of course, you are such a clever programmer that your code never aborts, but the code written by that other guy regularly crashes, so you get a "Segmentation Fault".

The GNU Radio Wiki page mentions a method of catching the error by running your application under GDB.  However I've found in some cases that GDB might slow down the app.  This page shows an alternative way of getting the stack backtrace.

First you must enable core dumps (which are mostly disabled by default these days).  The @ulimit -a@ command queries the current limits:

@

$ ulimit -a

core file size          (blocks, -c) 0

@

We use the @ulimit@ command to turn off the limit:

@

$ ulimit -c unlimited

$ ulimit -a

core file size          (blocks, -c) unlimited

@

Now run the app, and wait for the crash.  It should generate a file called @core@ or @core.@PID in the current directory.  There are a few other obscure reasons that could also prevent the core file from appearing at this point (already a file with the same name but not owned by the user; user does not own the directory; executable is setuid, etc).

For this example assume the core file is named @core.12345@.  Now do

@gdb /usr/bin/python core.12345@

This should load the core dump into GDB.  Now you can do

@i stack@

to display the call trace.