Can one use libSegFault.so to get backtraces for SIGABRT?

Question

The magic incantation

LD_PRELOAD=/lib/libSegFault.so someapp

runs someapp with libSegFault.so providing backtrace information on a

Answer 1

env SEGFAULT_SIGNALS="abrt segv" LD_PRELOAD=/lib/libSegFault.so someapp

Note that the actual path to the preload library may differ. On my machine, I'd use

env SEGFAULT_SIGNALS="abrt segv" LD_PRELOAD=/lib/x86_64-linux-gnu/libSegFault.so some-64bit-app

or

env SEGFAULT_SIGNALS="abrt segv" LD_PRELOAD=/lib/i386-linux-gnu/libSegFault.so some-32bit-app

depending whether the application I was running was compiled 64-bit or 32-bit. (You can use file to check.)

---

The source tells us there are three environment variables that define how libSegFault.so behaves:

• SEGFAULT_SIGNALS: The list of signals that cause a stack trace. The default is SIGSEGV. A defined but empty SEGFAULT_SIGNALS means no signals cause a stack trace. The supported values are segv, ill, abrt, fpe, bus on systems that have the SIGBUS signal, stkflt on systems that have the SIGSTKFLT signal, and all for all of these.

• SEGFAULT_USE_ALTSTACK: If defined in the environment, libSegFault.so uses an altenate stack for the stack trace signals. This may come in handy if you are debugging stack corruption.

• SEGFAULT_OUTPUT_NAME: If defined in the environment, the stack trace is written to this file instead of standard error.

To be honest, I found these initially by examining the library with strings /lib/libSegFault.so | sed -e '/[^0-9A-Z_]/ d'. All standard libraries (libSegFault.so having become a part of GNU C library) are tunable via environment variables, so using something like that command to dump any strings that look like environment variable names is a quick way to find stuff to search for. Doing a web search on "SEGFAULT_SIGNALS" "SEGFAULT_OUTPUT_NAME" produces a number of useful links; seeing that it was part of the GNU C library nowadays, I went to the source git archives, found the actual source file for the library, and posted my answer.

Answer 2

In a similar vein, the glibc exception handler writes a stack dump to /dev/console on heap corruption errors.

If you are running your executable in a non tty (i.e. a systemd process or other detached process), the crash output goes to /dev/null, which is not so useful.

There is an undocumented feature to redirect the output to /dev/stderr. Set the following environment variable:

export LIBC_FATAL_STDERR_=1

This can be used in conjunction with libSegFault.so for maximal forensics.

It is also worth mentioning that this might give you two stack traces if you also enable backtraces for SIGABRT, as the glibc first does a stack trace, then signals SIGABRT ... and then libSegFault gives a second stack trace.