Hi, I have the exact same problem (almost same gdb trace running on Linux too.
It seems that the proxy.c is giving problem. I setup two clients (using radclient) to send the acct records to the radius daemon which then proxied to another server. With 1 client everything is fine. Once the next client kicks in, the daemon crashed. /hh On Wed, 16 Jan 2002, Mitchell, Michael wrote: > Hello list, > > I'm currently testing freeradius-snapshot-20020114 (configured as a proxy > only) on Solaris 8 and running into a problem. > > radiusd will run for a short (seemingly random) period of time (any where > from say 10 seconds to 30 seconds) and happily processing requests until it > simply dies with a signal 9 (SIGKILL??) and core dumps. The problem also > seems to relate to the load put on the server. At 4 or 5 requests per second > it will start to exhibit the crashing behaviour within about 30 seconds. At > 2 or 3 requests per second it is taking several minutes for the problem to > appear. > > The problem also has only so far appeared for accounting requests. > > Maybe there is a timing issue somewhere, since accounting requests take that > much longer to process as my proxy has to wait for a response to come back > from the second radius server? > > Using gdb it appears that radiusd is crashing at at least a few different > places, which is not very helpful, and kind of suggests it may not be an > actual bug in FreeRADIUS? > > Here are three back traces that I captured: > > #0 0x188b4 in proxy_send (request=0x9cb18) at proxy.c:317 > 317 request->proxy->timestamp = request->timestamp; > (gdb) bt > #0 0x188b4 in proxy_send (request=0x9cb18) at proxy.c:317 > #1 0x15480 in rad_respond (request=0x9cb18, fun=0x170a0 <rad_accounting>) > at radiusd.c:1527 > #2 0x1ecf8 in request_handler_thread (arg=0x98110) at threads.c:169 > > ---------------------------------------------------------------------------- > - > > #0 0xff141da4 in t_delete () from /usr/lib/libc.so.1 > (gdb) bt > #0 0xff141da4 in t_delete () from /usr/lib/libc.so.1 > #1 0xff141998 in realfree () from /usr/lib/libc.so.1 > #2 0xff14226c in cleanfree () from /usr/lib/libc.so.1 > #3 0xff1413a0 in _malloc_unlocked () from /usr/lib/libc.so.1 > #4 0xff141294 in malloc () from /usr/lib/libc.so.1 > #5 0x22538 in rad_decode (packet=0xa00f8, original=0xa3b68, > secret=0x98dec "gloople") at radius.c:1060 > #6 0x15208 in rad_respond (request=0x98da0, fun=0x170a0 <rad_accounting>) > at radiusd.c:1437 > #7 0x1ecf8 in request_handler_thread (arg=0x982f0) at threads.c:169 > > ---------------------------------------------------------------------------- > - > > #0 0x23220 in pairfind (first=0x190, attr=41) at valuepair.c:97 > 97 first = first->next; > (gdb) bt > #0 0x23220 in pairfind (first=0x190, attr=41) at valuepair.c:97 > #1 0x1888c in proxy_send (request=0x9d728) at proxy.c:312 > #2 0x15480 in rad_respond (request=0x9d728, fun=0x170a0 <rad_accounting>) > at radiusd.c:1527 > #3 0x1ecf8 in request_handler_thread (arg=0xa70f0) at threads.c:169 > > This appears to point back to the threading, but whether it is a Solaris > issue or a FreeRADIUS issue I'm not really sure. > > The log files don't appear (to me) to give a definitive answer to what is > happening here, except that at the time of the "crash", I'm getting > incomplete attribute logging such as: > > Thread 2 handling request 167, (17 handled so far) > Proxy-State = 0x313639 > Sending Accounting-Response of id 169 to 203.108.109.27:62729 > Finished request 167 > Going to the next request > Thread 2 waiting to be assigned a request > NAS-IP-Address = 203.108.109.27 > = 1 > = Async > = Start > = "123" > Proxy-State = "169" > = UNKNOWN-TYPE > > When I run the server with the "-s" option it seems to fun fine and does not > exhibit this behaviour. > > Once again this appears to point towards a problem with threading? > > I know there are at least a couple of people running FreeRADIUS on Solaris 8 > and just wondering if anyone can possibly point me in a direction to start > looking for the problem, or if there is a known issue with solaris that > requires a patch or something similar? > > > Many thanks for your time and effort, > Michael > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
