not logged in | [Login]
Always use radiusd -X
when debugging!
For non-exploits use http://bugs.freeradius.org to create a bug report, do not post bug reports to the users or developers list, you will be directed here.
For sensitive defects, exploits, or potential exploits (buffer overflows etc...) post to the developers list, and one of the core developers will contact you off list.
Please compile from source with the configure flag --enable-developer
, and no CFLAGS
set in the environment. This will disable optimisation at compile time, and add additional debugging symbols.
Provide a backtrace using GDB:
gdb <path to freeradius bin> run -xfl stdout # Trigger the crash bt
Provide details of any configuration changes you think are relevant, or even better, a pared down configuration and radclient/eapol-test input that will reliably reproduce the crash.
As above, recompile with developer debugging enabled, and use GDB to attach to the stuck process.
Provide a backtrace using GDB:
gdb <process ID> thread apply all bt or echo "thread apply all bt" > /tmp/gdb.cmd gdb -x /tmp/gdb.cmd <process ID> > /tmp/gdb.bt
Please run with a minimally sized thread pool if possible to keep the output down.
Provide output of valgrind:
valgrind --leak-check=full --time-stamp=yes --log-file=/tmp/<output>.vg <path to freeradius bin> <freeradius options> pid=$! # Load the server until you're sure the memory leak has occurred kill $pid
Provide details of any configuration changes you think are relevant, or even better, a pared down configuration and radclient/eapol-test input that will reliably trigger the leak.
Last edited by Arran Cudbard-Bell (arr2036), 2015-04-21 11:49:17
Sponsored by Network RADIUS