The magic incantation
LD_PRELOAD=/lib/libSegFault.so someapp
runs someapp with libSegFault.so providing backtrace information on a SIGSEGV as described in many different places.
Other than using signal(7)-like approaches to cause SIGABRT to invoke the SIGSEGV handler, is there some way to get libSegFault to provide backtrace information for assert(3) failures?
Note that the actual path to the preload library may differ. On my machine, I'd use
or
depending whether the application I was running was compiled 64-bit or 32-bit. (You can use
fileto check.)The source tells us there are three environment variables that define how
libSegFault.sobehaves:SEGFAULT_SIGNALS: The list of signals that cause a stack trace. The default isSIGSEGV. A defined but emptySEGFAULT_SIGNALSmeans no signals cause a stack trace. The supported values aresegv,ill,abrt,fpe,buson systems that have the SIGBUS signal,stkflton systems that have the SIGSTKFLT signal, andallfor all of these.SEGFAULT_USE_ALTSTACK: If defined in the environment,libSegFault.souses 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.sohaving 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.