[asterisk-bugs] [Asterisk 0009520]: realtime prune (and others) may segfault asterisk (timing issue)

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=9520 
====================================================================== 
Reported By:                kryptolus
Assigned To:                russell
====================================================================== 
Project:                    Asterisk
Issue ID:                   9520
Category:                   Channels/chan_sip/Registration
Reproducibility:            always
Severity:                   crash
Priority:                   normal
Status:                     assigned
Asterisk Version:            SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  1.2  
SVN Revision (number only!): 61305 
Disclaimer on File?:        Yes 
Request Review:              
====================================================================== 
Date Submitted:             04-11-2007 07:31 CDT
Last Modified:              03-19-2008 15:10 CDT
====================================================================== 
Summary:                    realtime prune (and others) may segfault asterisk
(timing issue)
Description: 
The function expire_register doesn't do any locking before mucking with the
peer. 
If it gets pre-empted, there's a chance that the peer might be destroyed
before the control returns to expire_register. 

If you execute a "prune realtime peer" at the right time, asterisk will
segfault. It is not limited to just this however, as I have experienced
several segfaults with this signature without any intervention. However,
looking at the code I can only see a problem with the pruning code, I don't
see any possible issues with any other place in sip.

My patch queues up peers to be destroyed and they are ultimately destroyed
from the monitor thread which should guarantee that expire_register cannot
be running  at the same time. The other alternative is to add a check to
expire_register to check if peer is still inside the peer list. However,
that has potential to impact performance because that check would block a
lot of things on every expire.




====================================================================== 

---------------------------------------------------------------------- 
 kpfleming - 03-19-08 15:10  
---------------------------------------------------------------------- 
There really isn't any point in not 'fully tracking refs'... doing so is
just an invitation to even harder to isolate problems because it *looks*
like the code is doing the right thing.

In spite of the work being done for 1.6, the existing reference counting
in 1.4 should be made as stable and reliable as it can be. If
expire_register() is operating on a peer object without holding a reference
to that object, then we are guaranteed to crash at some point. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
03-19-08 15:10  kpfleming      Note Added: 0084288                          
======================================================================