[asterisk-dev] [Code Review] 4389: Memory leak cleanups

[Mark Michelson]

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

(Updated Jan. 30, 2015, 10:47 a.m.)


Status
------

This change has been marked as submitted.


Review request for Asterisk Developers.


Changes
-------

Committed in revision 431468


Bugs: ASTERISK-24736
    https://issues.asterisk.org/jira/browse/ASTERISK-24736


Repository: Asterisk


Description
-------

John Hardin of Digium did some investigation into memory leaks he was seeing and created a set of patches that fixes them. I've already given these patches a look and have made a few small adjustments to them where necessary for coding guidelines reasons. Most of the leak fixes are pretty straightforward, but one of these bears a bit of explanation:

Prior to Asterisk 12, originating calls with channel variables required that you transfer ownership of the created ast_variables structure away when calling ast_pbx_outgoing_exten() or ast_pbx_outgoing_app(). This was presumably because these functions could spawn threads that required these variables to not be freed yet. However, in Asterisk 12, ast_pbx_outgoing_exten() and ast_pbx_outgoing_app() were rewritten to not use the variables in the spawned threads. However, we also stopped actually destroying the variables there, too. So with this patch, responsibility for freeing the variables lies with the original creator of the variables.


Diffs
-----

  /branches/13/res/res_pjsip_refer.c 431302 
  /branches/13/pbx/pbx_spool.c 431302 
  /branches/13/main/xmldoc.c 431302 
  /branches/13/main/stasis_channels.c 431302 
  /branches/13/main/pbx.c 431302 
  /branches/13/main/manager.c 431302 
  /branches/13/main/bridge_after.c 431302 
  /branches/13/channels/chan_pjsip.c 431302 

Diff: https://reviewboard.asterisk.org/r/4389/diff/


Testing
-------

John Hardin's testing with valgrind has shown that the memory leaks it had been reported are no longer present.


Thanks,

Mark Michelson

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20150130/31ae3271/attachment.html>