thebeachmaster / travis-coredump Goto Github PK

WARNING: only sudo:true machines can produce coredumps currently on travis (springmeyer#6)

On travis you might see a cryptic error like:

/home/travis/build.sh: line 41:  2300 Segmentation fault

Or:

*** glibc detected *** ./test: double free or corruption (top): ***

Yay, your app segfaulted or hit a double-free. And you can't reproduce locally. And running your program in the gdb interpreter won't work on a remote machine. What now?

You have come to the right place.

This repo contains a demo of:

• How to enable coredumps for linux (ulimit -c unlimited)
• A c++ program that will simulate a crash
• The gdb incantation to make the crash backtrace visible in the travis logs

See .travis.yml for detailed instructions you can copy into your own .travis.yml. See sample logs at https://travis-ci.org/springmeyer/travis-coredump/. This repo is configured so that with two runs in the travis matix:

• One run tests a program that does not crash and therefore the build should cleanly pass
• The other run tests a program that does crash, reports the backtrace, then exits the run with the same errorcode as generated by the crash.

The backtrace should reveal to you the file and line number of the bug:

Core was generated by `./test'.
Program terminated with signal 11, Segmentation fault.
#0  0x00007f438532302c in free () from /lib/x86_64-linux-gnu/libc.so.6
Thread 1 (LWP 2611):
#0  0x00007f438532302c in free () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00000000004005d6 in main () at might_crash.cpp:6

To experiment locally:

1. Build the test program

make

2. Enable core files

ulimit -c unlimited -S

3. Run test program and make it crash

CRASH_PLEASE=1 ./test

You should see a nasty error show up with (core dumped) in the last line.

4. Generate a backtrace

Great, so now that you've confirmed it crashed, let's get more fancy.

To script the auto generation of the backtrace we can collect the PID and use that to find the core file and generate a backtrace:

On OS X for this to work (unfortunely) you need a very recent lldb version.

CRASH_PLEASE=1 ./test & pid=$! && fg;
lldb --core /cores/core.$pid --batch --one-line "bt"

sudo apt-get install gdb
CRASH_PLEASE=1 ./test
gdb $(pwd)/test core -ex "thread apply all bt" -ex "set pagination 0" -batch

If you are on OS X, you don't need to worry about these steps, just look inside:

~/Library/Logs/DiagnosticReports/

And a backtrace should be present for any program that just crashed.

If you are on Windows, let me know if you have tips on generating backtraces for crashes on the command line.