Project

General

Profile

DebugPage » History » Version 4

matt, 10/22/2017 09:21 AM

1 2 matt
h1. Debugging Segmentation Faults
2 1 zecke
3 1 zecke
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".
4 1 zecke
5 1 zecke
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.
6 1 zecke
7 3 matt
First you must enable core dumps (which are mostly disabled by default these days).  The @ulimit -a@ command queries the current limits:
8 2 matt
@
9 1 zecke
$ ulimit -a
10 1 zecke
core file size          (blocks, -c) 0
11 2 matt
@
12 1 zecke
13 2 matt
We use the @ulimit@ command to turn off the limit:
14 2 matt
@
15 1 zecke
$ ulimit -c unlimited
16 1 zecke
$ ulimit -a
17 1 zecke
core file size          (blocks, -c) unlimited
18 2 matt
@
19 1 zecke
20 2 matt
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).
21 1 zecke
22 2 matt
For this example assume the core file is named @core.12345@.  Now do
23 1 zecke
24 2 matt
@gdb /usr/bin/python core.12345@
25 1 zecke
26 1 zecke
This should load the core dump into GDB.  Now you can do
27 1 zecke
28 2 matt
@i stack@
29 1 zecke
30 1 zecke
to display the call trace.
Add picture from clipboard (Maximum size: 48.8 MB)