[asterisk-dev] [Code Review] 4262: bridge: channel ref leak on blond_nonfinal_enter

[Scott Griepentrog]

> On Dec. 12, 2014, 6:30 p.m., rmudgett wrote:
> > /branches/12/main/bridge_basic.c, lines 2262-2264
> > <https://reviewboard.asterisk.org/r/4262/diff/1/?file=69672#file69672line2262>
> >
> >     Without looking further, the channel refs here seem to be mismatched.

The recall_target is created and destroyed by the transfer code only, so that is a correct implementation.

However the transfer_target has a reference to it that must be cleaned up on destruction of props-> structure, so to set it to NULL at this point is incorrect.

Because ast_channel_unref always returns NULL, the pattern of x=unref(x) only works where there is only one reference held to x in the context of x's lifetime, which is not the case here.


- Scott


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4262/#review13959
-----------------------------------------------------------


On Dec. 12, 2014, 4:10 p.m., Scott Griepentrog wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4262/
> -----------------------------------------------------------
> 
> (Updated Dec. 12, 2014, 4:10 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-24513
>     https://issues.asterisk.org/jira/browse/ASTERISK-24513
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> After a blond transfer to a destination that then hangs up, the Local;1 channel would suffer a reference leak.  This was due to blond_nonfinal_enter() resetting the props->transfer_target to NULL as it unref'd the channel for itself, later preventing the attended_transfer_properties_destructor() from releasing it's own reference, which was inherited during ast_bridge_impart with INDEPDENDENT.
> 
> This change prevents props->transfer_target from being set to NULL, and thus eliminates the leak.
> 
> 
> Diffs
> -----
> 
>   /branches/12/main/bridge_basic.c 429516 
> 
> Diff: https://reviewboard.asterisk.org/r/4262/diff/
> 
> 
> Testing
> -------
> 
> Newly created test 'atxfer_fail_blonde' (https://reviewboard.asterisk.org/r/4256/) now passes.  No other new test failures encountered.
> 
> 
> Thanks,
> 
> Scott Griepentrog
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20141216/b27f0b51/attachment-0001.html>