Hi! I still have a problem described there : http://lists.freeradius.org/pipermail/freeradius-devel/2005-August/008670.ht... (see a thread) The FreeRadius sources is from the CVS a week ago. I can't use FreeRADIUS on the heavy load at all... It dies **every** 2..3 min :( There is no such problem under lite load (upto ~1req/ per sec.). Fri Sep 16 12:10:51 MSD 2005: Radius died, restarting.. /opt/radiusd_credit/sbin/radwatch: line 50: 8419 Aborted $RADIUSD -f $* Fri Sep 16 12:11:47 MSD 2005: Radius died, restarting.. /opt/radiusd_credit/sbin/radwatch: line 50: 8444 Aborted $RADIUSD -f $* Fri Sep 16 12:15:16 MSD 2005: Radius died, restarting.. /opt/radiusd_credit/sbin/radwatch: line 50: 8471 Aborted $RADIUSD -f $* Fri Sep 16 12:10:51 2005 : Error: Assertion failed in request_list.c, line 577 Fri Sep 16 12:11:01 2005 : Info: Ready to process requests. Fri Sep 16 12:11:01 2005 : Auth: Login OK: [user] (from client c5850a port 1144 cli 2222222) I've increased a number of severs in the radiusd.conf, no changes. Is there any way to avoid this problem ? My platform is Linux/PPC64 so I can't use valgrind tool to debug a problem. Is it possible to add more information It seems there is some problems with main request queue list. May be, some atomic locking around list access will save us ? Is it possible to change multithread model insted of the NPTL ? Could you add some debug info (request queue status/statistics) in the 'assert' ? I've noticed one static definition of the array : === src/main/request_list.c: 57 ======== struct request_list_t { REQUESTINFO request_list[256]; =========== May be, it exceeds a limit on the heavy load ? -- -=AV=-