[asterisk-dev] [Code Review] 4596: res_pjsip_phoneprov_provider: Fix leaked OBJ_MULTIPLE iterator (2nd try)

[Joshua Colp]

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


Can you update the description with the current analysis of what is going on and how this fixes it? The load order, the unload order, what happens when, that sort of thing.

- Joshua Colp


On April 8, 2015, 6:09 p.m., George Joseph wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4596/
> -----------------------------------------------------------
> 
> (Updated April 8, 2015, 6:09 p.m.)
> 
> 
> Review request for Asterisk Developers and Corey Farrell.
> 
> 
> Bugs: ASTERISK-24935
>     https://issues.asterisk.org/jira/browse/ASTERISK-24935
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> Original issue:  res_pjsip_phoneprov_provider was using ao2_callback with OBJ_MULTIPLE, then ignoring the return.  This resulted in a reference leak.  Added OBJ_NODATA flag.
> 
> Unfortunately, this highlighted a module unload order issue where res_phoneprov and res_pjsip_phoneprov_provider were unloading before res_pjsip_config_wizard, which needed them.
> 
> res_pjsip_config_wizard is itself a sorcery wizard so there are some complexities to it's load order (it's long story) but I've removed the GLOBAL_SYMBOLS flag from res_pjsip_config_wizard so it loads later and unloads earlier and also triggered a reload of res_pjsip_phoneprov_provider.  Now they load and unload in the correct order.
> 
> 
> Diffs
> -----
> 
>   branches/13/res/res_pjsip_phoneprov_provider.c 434423 
>   branches/13/res/res_pjsip_config_wizard.c 434423 
> 
> Diff: https://reviewboard.asterisk.org/r/4596/diff/
> 
> 
> Testing
> -------
> 
> Checked load/unload order and make sure there were no FRACKs on unload.
> 
> 
> Thanks,
> 
> George Joseph
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20150409/55076ca8/attachment.html>