[asterisk-dev] [Code Review] Fixes SIP registry ref count error

[Russell Bryant]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.digium.com/r/282/#review846
-----------------------------------------------------------



/trunk/channels/chan_sip.c
<http://reviewboard.digium.com/r/282/#comment2061>

    This is an interesting comment.
    
    The container has a reference.  So, while traversing the container, it should not be possible for the object to disappear.  If that's possible, then this change does not remove the race condition, it only decreases its possibility.
    
    If the object can disappear, the bug is that the container lock is not held here.  You shouldn't need a reference on the object unless you are going to hold on to it after you unlock the container.


- Russell


On 2009-06-11 08:56:05, David Vossel wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.digium.com/r/282/
> -----------------------------------------------------------
> 
> (Updated 2009-06-11 08:56:05)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> During a sip reload, the list of sip_registry objects are supposed to be traversed, unlinked, and destroyed, but destruction never takes place due to a ref counting error.  This causes a memory leak when registry items are removed from sip.conf and reloaded.  While the registries are removed from the global list, they are not removed from the scheduler.  Because of this, SIP register attempts continue to be sent out for the item even though it may no longer be in the .conf.
> 
> 
> Diffs
> -----
> 
>   /trunk/channels/chan_sip.c 199818 
> 
> Diff: http://reviewboard.digium.com/r/282/diff
> 
> 
> Testing
> -------
> 
> added register in sip.conf, started Asterisk, took out of sip.conf, reloaded, no more register attempts were made and item was destroyed.
> 
> 
> Thanks,
> 
> David
> 
>