Core dump in Linux

Question

I want to create a core dump whenever my process crashes. Currently I am following this approach:

1. Build a special \"debug\" version of the program using \"-g\"

Answer 1

1. There is no such thing as a "release" version and "debug" version on Linux. You just build a program with debugging information when use "-g". You can strip this information.

Updated
Actually I think I should say about one possible difference between debug and release versions that I didn't mention in my message. Release versions might be built with the NDEBUG define in order to get rid of all assert() in the program. Debug versions on the contrary should be built without defining NDEBUG as assert() helps in finding bugs.

However if you don't use assert() there will be no difference.

2. A user can set ulimit -c unlimited in his or her profile.

3. Backtrace of an program compiled with some optimization often doesn't give a line number which is useful.

4. You can build a version with debugging information and put in your archive. Then strip it and deliver the stripped binaries to your customers. If a customer gives you a core file then just use the version with debugging information and the core file from the customer.

5. How to create a core dump in the "release" build of a program? It's not your responsibility, it's responsibility of the OS.

Answer 2

You will hardly get a decent stacktrace in human form if the code is a release mode/highly optimized version. Use the -g switch or forget about doing a stacktrace altogether...you cannot have both!! Which brings back to this point - it sounds like you are anticipating the code to crash even in production environment???

Why don't you fix the code and ensure it works first...code smells .... sniff sniff

Edit: Ok, I may have come across a bit harsh in my comment above, I did not intend to be harsh there...for the benefit of the readers, I have included a link to another question posted here, and in that answer I gave, uses signals to create a stack-trace and redirect to a file. It will be of help to the OP's question and aid him in troubleshooting...

Answer 3

The usual solution is to build with -g and to strip off the debug information before releasing the file. Look for the 'strip' command. You keep the file with debug information and use it to debug core dumps you get from customers.

If you want to print the human readable backtrace on the users machine you'll need to distribute binaries with (some) debug information. Look for the 'backtrace()' function in glibc.

Note that core dumps will be created (if ulimit is set appropriately) even if your binary doesn't contain debug information.

The best way to ensure the creation of a core dump is probably to execute your binary from a script which sets ulimit before running the binary.

Answer 4

• Regarding the core limit, you can do it yourself in C by calling setrlimit.
• On a GNU (glibc) or BSD system, you can get a backtrace by calling backtrace and related system calls. You will then have to translate the function addresses into function names by running addr2line (or duplicating its functionality).
• Just don't use -g, you can still get a backtrace (except that inlined functions will not appear).

Answer 5

You can try google-coredumper:

A neat tool for creating GDB readable coredumps from multithreaded applications -- while the program is running. The coredumper library can be compiled into applications to create core dumps of the running program, without terminating.

http://sourceforge.net/projects/goog-coredumper/