cvs current with SIGSEGV; how to track down

[Jason Ornstein]

* Alan DeKok <aland at ox.org> [2005-05-31 14:58:17 -0400]:

>   Ok, I've fixed that in CVS.  Does the resulting executable work?

[this is kinda long...but it kinda points to where the problem might be]

Not at the moment.

        [rc.radius start with ARGS set to -sfxx]
        Module: Instantiated radutmp (radutmp)
        Initializing the thread pool...
        Listening on authentication address * port 1812
        Listening on accounting address * port 1813
        Segmentation Fault - core dumped
        radiusd

That's a step backards from Friday.  I'm having the same issues as last
week when the backtrace wasn't there.  After I start gdb it reads in 
all the symbols and then when I look at the backtrace I see this:

        (gdb) bt
        #0  0x00000000 in ?? ()

        (gdb) bt full
        #0  0x00000000 in ?? ()
        No symbol table info available.

and if I put a breakpoint on line 415 and print out the listener....


...
Initializing the thread pool...

Breakpoint 1, main (argc=2, argv=0xffbffbc4) at radiusd.c:412
412             for (listener = mainconfig.listen;
(gdb) next
415                     listener->print(listener, buffer,
sizeof(buffer));
(gdb)
416                     switch (listener->type) {
(gdb)
422                             DEBUG("Listening on accounting address
%s", buffer);
(gdb)

Breakpoint 2, main (argc=2, argv=0xffbffbc4) at radiusd.c:418
418                             DEBUG("Listening on authentication
address %s", buffer);
(gdb)
430                             DEBUG("Listening on detail file %s",
buffer);
(gdb) n
Listening on authentication address * port 1812
412             for (listener = mainconfig.listen;
(gdb)
415                     listener->print(listener, buffer,
sizeof(buffer));
(gdb)
416                     switch (listener->type) {
(gdb)
422                             DEBUG("Listening on accounting address
%s", buffer);
(gdb)
430                             DEBUG("Listening on detail file %s",
buffer);
(gdb) print buffer
$9 = "* port 1813", '\0' <repeats 361 times>, "ÿ>óà", '\0' <repeats 20
times>, "¡\224H¹", '\0' <repeats 132 times>, "þç\000\000ÿ>ç´", '\0'
<repeats 20 times>,
"ÿ¿ôT\000\000\000\022\000\000\000\005\200\000\002\002\000\000\000\003\000\000\000\000ÿ¿íÀÿ;F|ÿ¿íÈÿ;F|ÿ¿ó¤ÿ?\fðÿ:\000\203\000\000\000\000ÿ¿ó\234\000\000\000\000ÿ;q`\000\000\000\003\000\000ÿ\000ÿ>à0\000\000\000\000ÿ>ç´ÿ>à0\201\001\001\000ÿ¿ôT\000\000\000\003ÿ¿ò\210ÿ>óào.1\000o.1\000ÿ¿î
ÿ;R|ÿ¿î(ÿ"...
(gdb) n
Listening on accounting address * port 1813
412             for (listener = mainconfig.listen;
(gdb) print mainconfig.listen
$10 = (rad_listen_t *) 0x3fbc0
(gdb) s
415                     listener->print(listener, buffer,
sizeof(buffer));
(gdb) print sizeof(buffer)
$11 = 4096
(gdb) print buffer
$12 = "* port 1813", '\0' <repeats 361 times>, "ÿ>óà", '\0' <repeats 20
times>, "¡\224H¹", '\0' <repeats 132 times>, "þç\000\000ÿ>ç´", '\0'
<repeats 20 times>,
"ÿ¿ôT\000\000\000\022\000\000\000\005\200\000\002\002\000\000\000\003\000\000\000\000ÿ¿íÀÿ;F|ÿ¿íÈÿ;F|ÿ¿ó¤ÿ?\fðÿ:\000\203\000\000\000\000ÿ¿ó\234\000\000\000\000ÿ;q`\000\000\000\003\000\000ÿ\000ÿ>à0\000\000\000\000ÿ>ç´ÿ>à0\201\001\001\000ÿ¿ôT\000\000\000\003ÿ¿ò\210ÿ>óào.1\000o.1\000ÿ¿î
ÿ;R|ÿ¿î(ÿ"...
(gdb) print listener
$13 = (rad_listen_t *) 0x4b5a0
(gdb) print listener->print
$14 = 0
(gdb) step

Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()


So, two things.

1.  Each time through the switch statment it looks like two case 
    statements are being called.  The real one and then the one
    for RAD_LISTEN_DETAIL (line 430)

2.  From that last print out, you can see that, for some reason, that
    listener->print is pointing to zero and that just isn't good.  So
    I looked a little closer

  (gdb) print *listener
  $18 = {next = 0x4ea20, type = RAD_LISTEN_AUTH, fd = 5, identity = 0x0,
    rl = 0x4b5d0, recv = 0x23b0c <auth_socket_recv>,
    send = 0x23920 <auth_socket_send>, update = 0x24a6c <generic_update>,
    print = 0x238b0 <socket_print>, data = 0x4ced8}

  (gdb) print *listener
  $20 = {next = 0x4b5a0, type = RAD_LISTEN_ACCT, fd = 6, identity = 0x0,
    rl = 0x4bde0, recv = 0x23c54 <acct_socket_recv>,
    send = 0x23a30 <acct_socket_send>, update = 0x24a6c <generic_update>,
    print = 0x238b0 <socket_print>, data = 0x4a2b0}

  (gdb) print *listener
  $22 = {next = 0x0, type = RAD_LISTEN_PROXY, fd = 7, identity = 0x0, rl = 0x0,
    recv = 0, send = 0, update = 0, print = 0, data = 0x4a2d0}

On a hunch, I changed radiusd.conf not to use proxy.conf

        [was this]
        proxy_requests  = yes
        $INCLUDE  ${confdir}/proxy.conf

        [is now this]
        proxy_requests  = no

and I restarted radius and it started witout dumping core and it doesn't 
dump core when it receives a radius packet.    

If I look at proxy.conf and look at the non-comment lines I have this

        proxy server {
                retry_delay = 5
                retry_count = 3
                dead_time = 120
                default_fallback = yes
                post_proxy_authorize = yes
        }

        realm LOCAL {
                type            = radius
                authhost        = LOCAL
                accthost        = LOCAL
        }

        realm sybase.com {
                type            = radius
                authhost        = dub-token-1.sybase.com:1645
                secret          = rad1usn0w
        }

But I can comment either or both realm statements and the server still
dumps core.

Does that help at all?


-jason