DebugPage » History » Revision 2
« Previous |
Revision 2/4
(diff)
| Next »
matt, 10/22/2017 09:20 AM
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.
Updated by matt over 6 years ago · 2 revisions