[asterisk-dev] [Code Review] 4302: bridge: channel ref leak after failed blond transfer

[Matt Jordan]

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



/branches/13/main/bridge_basic.c
<https://reviewboard.asterisk.org/r/4302/#comment24580>

    I'm not sure we should be clearing the reference here.
    
    Clearly, we need to clear the reference to props->recall_target if the channel answers. In that case, however, that could be done on line 2341.
    
    If, however, the target doesn't answer, then we may still have to do something with the recall_target. That, of course, depends on the current state that the state machine is in - but here, it looks like we've blown away any chance for the state machine to use the original recall_target reference, regardless of the outcome of the dial operation.
    
    When the leak occurs, what state is the state machine in? Are there states in the state machine that would like to reference the recall_target channel?
    


- Matt Jordan


On Dec. 30, 2014, 3:23 p.m., Scott Griepentrog wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4302/
> -----------------------------------------------------------
> 
> (Updated Dec. 30, 2014, 3:23 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 supposed to be fixed by review 4262, but that caused an extra unreference on nominal blond transfer (somehow missed that in testing).  This correction to the original problem reverts the prior change which had incorrectly mucked with moving the referenced transfer_target channel to recall_target in blond_nonfinal_enter(), and instead resolves the issue by insuring that the reference in recall_target is not lost by releasing it in recall_enter() before it is repalced on a successful dial.
> 
> 
> Diffs
> -----
> 
>   /branches/13/main/bridge_basic.c 430163 
> 
> Diff: https://reviewboard.asterisk.org/r/4302/diff/
> 
> 
> Testing
> -------
> 
> Both the blond_nominal and atxfer_fail_blond (r/4256) tests pass without error.
> 
> 
> Thanks,
> 
> Scott Griepentrog
> 
>

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