* Alan DeKok <aland@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