Hello Alan, Thanks so much for your answer. Below, you can find the additionally information about us problem : - which OS && CPU (32 / 64-bit) ---> CentOs 5.2 - CPU: 32 bits - which version of the server - --> 2.1.6 - which command line was used to run the server --> ./radiusd - is this reproducible in non-threaded mode (radiusd -fs) - we did not try because we needed performance We have a question for you : Why is not there a protection for "null pointer" to avoid this kind of problem? Best Regards, Fabiana ------------------------------------------------------------------------------------------------------------------------------------------------ * To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> * Subject: Re: Crash due to fr_packet_cmp * From: Alan DeKok <aland@deployingradius.com> * Date: Sun, 15 Nov 2009 21:19:55 +0100 * In-reply-to: <828995.26169.qm@web26202.mail.ukl.yahoo.com> * References: <828995.26169.qm@web26202.mail.ukl.yahoo.com> * Reply-to: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> * User-agent: Thunderbird 2.0.0.23 (Macintosh/20090812) ________________________________ fabiana marvani wrote:
After some time with load the freeradius crashes
We first noticed this crash with our plugins activated, but then we deactivated all plugins and used "default" configuration:
There have been a few reports similar to this. They all require sending the server many 10s of millions of packets over a long time. This makes it hard to reproduce && debug. It's likely a race condition. But it's hard to say where, or why.
core.8555 Program terminated with signal 11, Segmentation fault. (gdb) bt #0 fr_packet_cmp (a=0xb4897cd8, b=0x0) at packet.c:139 ... #6 0x0806cf83 in received_request (listener=0x8d4f608, packet=0xb4897cd8, prequest=0xbf89d0dc, client=0x8d2fc80) at event.c:2723
The server keeps all packets in a hash, to ensure it catches duplicates, etc. The hash is keyed by the source packet (src/dst ip/port). The crash comes because the "request" structure is still in the hash, though the "packet" entry in that structure has become NULL. The only problem is... the packet entry is *only* set to NULL after the request has been deleted from hash. And *only* the main thread adds/deletes entries to the hash. And *only* the main thread allocates or free's request data structures. So this is a problem that should be avoided completely by the design of the server. Some questions: - which OS && CPU (32 / 64-bit) - which version of the server - which command line was used to run the server - is this reproducible in non-threaded mode (radiusd -fs) If you are using an older version of the server, please also try with the current git "stable" branch (see git.freeradius.org). It has some changes which give it only one code path for doing certain kinds of request mangling. This makes it less likely for there to be errors, race conditions, etc. Alan DeKok. ________________________________ * References: * Crash due to fr_packet_cmp * From: fabiana marvani <fabiana_marvani@yahoo.it> * Previous by Date: Re: DHCP in FR * Next by Date: Re: DHCP in FR * Previous by Thread: Crash due to fr_packet_cmp * Next by Thread: Deprecate the X-Ascend-* attributes in dictionary.ascend? * Freeradius-Users November 2009 archives indexes sorted by: [ thread ] [ subject ] [ author ] [ date ] * Freeradius-Users list archive Table of Contents * More information about the Freeradius-Users mailing list