----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3042/#review10304 -----------------------------------------------------------
/trunk/channels/chan_pjsip.c <https://reviewboard.asterisk.org/r/3042/#comment19690> You need to put in the oldchan and bump the reference count on it to ensure it sticks around. The fixup process essentially steals and moves the ref from this pvt to another pvt. /trunk/channels/chan_pjsip.c <https://reviewboard.asterisk.org/r/3042/#comment19689> As this is now changed by a task in an async manner this is no longer safe, check needs to go into the task. - Joshua Colp On Dec. 4, 2013, 6:32 p.m., Jonathan Rose wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/3042/ > ----------------------------------------------------------- > > (Updated Dec. 4, 2013, 6:32 p.m.) > > > Review request for Asterisk Developers, Joshua Colp, Mark Michelson, and > rmudgett. > > > Bugs: ASTERISK-22936 > https://issues.asterisk.org/jira/browse/ASTERISK-22936 > > > Repository: Asterisk > > > Description > ------- > > This is a pretty severe locking problem which if triggered will cause > Asterisk to become unusable. Basically when attended transferring a bridge in > a way that triggers a masquerade, the ast_sip_push_task_synchronous function > is unable to complete and we are stuck holding the channels container lock > forever. The only simple answer to this problem is to not push the task > synchronously and allow the fixup function to run some time later. > > According to Josh and Mark, this hasn't been done before and there is a bit > of fear that allowing the task processor to operate on a zombie channel could > cause problems. > > > Diffs > ----- > > /trunk/channels/chan_pjsip.c 403308 > > Diff: https://reviewboard.asterisk.org/r/3042/diff/ > > > Testing > ------- > > Performed the attended transfer described on the issue without ending up in a > state with locks being held. Prior to the patch, this would occur 100% of the > time. > > > Thanks, > > Jonathan Rose > >
-- _____________________________________________________________________ -- 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
