Alan DeKok <al...@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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html