Unexpected "Exiting normally" 2.1.8?

[Bjørn Mork]

Alan DeKok <aland at 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