[asterisk-dev] [Code Review] 4178: res_pjsip_outbound_publish: stack overflow when using non-default sorcery wizard

[Kevin Harwell]

> On Dec. 4, 2014, 12:28 p.m., Joshua Colp wrote:
> > branches/13/res/res_pjsip_outbound_publish.c, line 688
> > <https://reviewboard.asterisk.org/r/4178/diff/3/?file=69522#file69522line688>
> >
> >     Should this also be in the lock? Is there a possible race condition here?

Hmmm, I don't think it is since the only time this is called is when the object is released and since the current_states container has a ref to it it won't be called until the container releases it while unloading, but prior to freeing the container the is_unloading is set to true, so reading it here without a lock should be fine.


- Kevin


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


On Dec. 4, 2014, 12:13 p.m., Kevin Harwell wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4178/
> -----------------------------------------------------------
> 
> (Updated Dec. 4, 2014, 12:13 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-24514
>     https://issues.asterisk.org/jira/browse/ASTERISK-24514
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> When using a non-default sorcery wizard (in this instance realtime) for outbound publishes Asterisk will crash after a stack overflow occurs due to the code infinitely recursing.  The fix entails removing the outbound publish state dependency from the outbound publish sorcery object and instead keeping an in memory container that can be used to lookup the state when needed.
> 
> 
> Diffs
> -----
> 
>   branches/13/res/res_pjsip_outbound_publish.c 428944 
> 
> Diff: https://reviewboard.asterisk.org/r/4178/diff/
> 
> 
> Testing
> -------
> 
> On top of running the current testsuite tests I also manually tested various configurations and scenarios using a static configuration file as well as dynamic realtime.  Verified that the crash no longer occurs and the potentially affected functionality works as expected (for instance, module [re]loading).
> 
> 
> Thanks,
> 
> Kevin Harwell
> 
>

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