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

[George Joseph]

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

(Updated April 8, 2015, 12:09 p.m.)


Review request for Asterisk Developers and Corey Farrell.


Changes
-------

Several things changed.

res_pjsip_phoneprov_provider now uses it's own sorcery instance for the phoneprov objects instead of res_pjsip's.  This should allow it to unload independently of res_pjsip.  It still has to use res_pjsip's instance to retrieve endpoint, transport and auth details but that's ok.

res_pjsip_config_wizard now handles res_pjsip_phoneprov_provider's sorcery instance and it now observes sorcery instance destroys so that it can unload independently of res_pjsip.

I've run tests/phoneprov/res_phoneprov_pjsip/ several times and it's neither FRACKing not leaking.


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 (updated)
-----

  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/20150408/e51df15b/attachment.html>