The Shibboleth V2 IdP and SP software have reached End of Life and are no longer supported. This documentation is available for historical purposes only. See the IDP v4 and SP v3 wiki spaces for current documentation on the supported versions.

NativeSPDebuggingNonWindows

To get a stack trace identifying where a crash occurs, the usual starting point is a core dump file (called core).

A helpful link that discusses how to get system daemons (like shibd) to produce core dumps can be found at http://www.unixinfo.nl/?p=391.

For RPM-based installations, more useful information can be obtained by installing the symbol files found in the "debuginfo" packages:

$ yum install log4shib-debuginfo xerces-c-debuginfo xml-security-c-debuginfo \
    xmltooling-debuginfo opensaml-debuginfo shibboleth-debuginfo

Assuming a core dump can be obtained, and the gdb package is installed a stack trace can be obtained like so (assuming one is in the directory with the core dump):

$ gdb /usr/sbin/shibd core
(gdb) where

If a core dump isn't obtainable, then it's possible to execute the crashing process under the debugger, if the crash can be reproduced. In the case of shibd, you can do something like this as root:

gdb /usr/sbin/shibd
(gdb) set args -F
(gdb) run

You should be able to trigger the crash and see it caught by the debugger, at which point a stack trace can be obtained.