Crash due to fr_packet_cmp

[fabiana marvani]

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 at lists.freeradius.org>
	* Subject: Re: Crash due to fr_packet_cmp
	* From: Alan DeKok <aland at deployingradius.com>
	* Date: Sun, 15 Nov 2009 21:19:55 +0100
	* In-reply-to: <828995.26169.qm at web26202.mail.ukl.yahoo.com>
	* References: <828995.26169.qm at web26202.mail.ukl.yahoo.com>
	* Reply-to: FreeRadius users mailing list <freeradius-users at 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 at 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  


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20091118/b16329f9/attachment.html>