Alan DeKok <aland@deployingradius.com> writes:
Bjørn Mork wrote:
I don't have that symbol. Did you mean fr_event_loop_exit?
Sure.
Anyway, I ran the server (this time a lab-/test-server with some traffic but nothing near any real load) using
Breakpoint 1, radius_signal_self (flag=2) at event.c:3733 3733 event.c: No such file or directory. in event.c (gdb) cont
Arg... PLEASE give the stack trace for this! "bt", or "thread apply all bt full".
Simply continuing means that you've ignored the break point.
Sorry, that was a mere cut'n paste error from an initial test (no the actual bug, just tested that I'd actually break on SIGTERM). I apologise for the confusion this caused.
And I got:
The same stack trace as before, LONG after the useful information has been lost.
Yes. Just to be sure, I've repeated the process and the trace is the same: Useless: (gdb) bt full #0 0x000000390d8306f7 in kill () from /lib64/libc.so.6 No symbol table info available. #1 0x0000000000423b6a in main (argc=4, argv=0x7fff3ada9b18) at radiusd.c:419 rcode = 0 argval = -1 spawn_flag = 1 dont_fork = 1 flag = 0 act = {__sigaction_handler = {sa_handler = 0x423d41 <sig_fatal>, sa_sigaction = 0x423d41 <sig_fatal>}, sa_mask = {__val = { 0 <repeats 16 times>}}, sa_flags = 0, sa_restorer = 0} Which I guess tells us that there is some other path here than through fr_event_loop_exit and radius_signal_self with flag==2? What that could possibly be is beyond my imagination, I must admit... Bjørn