Re: Re: Re: Radius server crash due to 35# bug
Date: Thu, 08 Apr 2010 18:21:26 +0200 From: Alan DeKok <aland@deployingradius.com> Subject: Re: Radius server crash due to 35# bug To: FreeRadius developers mailing list <freeradius-devel@lists.freeradius.org> Message-ID: <4BBE0286.50509@deployingradius.com> Content-Type: text/plain; charset=ISO-8859-1
Liu Linyong wrote:
4K requests/sec. start_servers = 5 and max_servers = 32. But totally 9 threads were created.(That is: 3 more threads were created after initializing)
Oh, I've set max_requests = 102400 in radiusd.conf.
Hmm... I've tested it with sustained 30K packets/s for ~12 hours, and haven't seen an issue.
This seems to be a hard problem to reproduce.
Alan DeKok.
[V2-1-7] Maybe the test environments are different, so I can always reproduce the problem in an hour or so in my test ;) Yesterday, I removed the codes associated to 'hash' when receiving a request from NAS. That is: In main/event.c received_request(), will not find node from hash table, nor inserte into. BUT just add to FIFOs by thread_pool_addrequest(). Then test it for 12 hours, it work fine!! There may be something wrong with the 'hash' codes, I guess ;) Hmm... it's hard for me to understand the fr_hash_table_fixup(), then I think this 'black box' may have something wrong, haha... Besides, in src/main/event.c Ln1199, should "#ifdef WTH_COA " to be "#ifdef WITH_COA "? V2-1-8 also has this code.
Liu Linyong wrote:
Maybe the test environments are different, so I can always reproduce the problem in an hour or so in my test ;)
OS, libraries, CPU are all different...
Yesterday, I removed the codes associated to 'hash' when receiving a request from NAS. That is: In main/event.c received_request(), will not find node from hash table, nor inserte into. BUT just add to FIFOs by thread_pool_addrequest().
Then test it for 12 hours, it work fine!!
Well... yes. If you don't use the relevant code, it won't have problems.
There may be something wrong with the 'hash' codes, I guess ;)
Nope. You simply bypassed the problem by deleting it. It's like fixing a flat tire by throwing away the rubber tire, and running your car on the steel rims. The wheels aren't flat, but it's not a good way to run the car.
Hmm... it's hard for me to understand the fr_hash_table_fixup(), then I think this 'black box' may have something wrong, haha...
It's been tested in isolation (simple test app) with valgrind && static memory checkers. It seems to be OK.
Besides, in src/main/event.c Ln1199, should "#ifdef WTH_COA " to be "#ifdef WITH_COA "? V2-1-8 also has this code.
That will be fixed in 2.1.9, thanks. Alan DeKok.
participants (2)
-
Alan DeKok -
Liu Linyong