> 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 > >
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
