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.

Files (0)

Updated by matt over 6 years ago · 4 revisions

Add picture from clipboard (Maximum size: 48.8 MB)