> On Dec. 3, 2014, 10:48 a.m., Joshua Colp wrote: > > branches/13/res/res_pjsip_outbound_publish.c, lines 1221-1229 > > <https://reviewboard.asterisk.org/r/4178/diff/2/?file=69153#file69153line1221> > > > > This is duplicating code from above. Would it not be better to assume > > that states may be NULL when setting it up above? > > > > Of course I made the assumption of the global container being used like > > elsewhere. > > > > If you can't do that then this can become a non-swappable regular > > container I'd say.
I had done this originally since on config file reloads current states were empty and it would cause a crash on lookup, but with a bit of refactoring I can remove it from here and check for it when applying an object. > On Dec. 3, 2014, 10:48 a.m., Joshua Colp wrote: > > branches/13/res/res_pjsip_outbound_publish.c, lines 1089-1091 > > <https://reviewboard.asterisk.org/r/4178/diff/2/?file=69153#file69153line1089> > > > > Is it actually possible for this to happen? It shouldn't, but had added based upon a previous review recommendation. However with the new changes I'll this can actually be NULL, but I'll move the check a bit later and assume if it is empty it is the initial load. > On Dec. 3, 2014, 10:48 a.m., Joshua Colp wrote: > > branches/13/res/res_pjsip_outbound_publish.c, lines 1268-1269 > > <https://reviewboard.asterisk.org/r/4178/diff/2/?file=69153#file69153line1268> > > > > You need to be in a loop here. It's possible for this to get spuriously > > triggered. > > > > As for the time limit - can things be in a state where that is safe to > > do? > > > > Some logging would also be useful so people know what is going on if it > > waits a bit. What do you mean by putting it in a loop or being spuriously triggered? Also as far as the time limit goes I think things should be fine. If it times out then the module won't unload, so anything left could still finish up. I mainly put it in so it wouldn't potentially sit there forever if a problem occurred or something took too long. - Kevin ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4178/#review13875 ----------------------------------------------------------- On Nov. 20, 2014, 3:43 p.m., Kevin Harwell wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/4178/ > ----------------------------------------------------------- > > (Updated Nov. 20, 2014, 3:43 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 428498 > > 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 > >
-- _____________________________________________________________________ -- 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
