[asterisk-dev] [Code Review] 4114: Prevent stringfields from accumulating unused memory

[rmudgett]

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

Ship it!


Minor nit.

Does the patch still fix the reporter's memory leak?


/branches/11/include/asterisk/stringfields.h
<https://reviewboard.asterisk.org/r/4114/#comment24171>

    Use __p__ instead of ptr to reduce potential confusion here because of the mixed use of __p__ and ptr.


- rmudgett


On Nov. 3, 2014, 11:55 a.m., Corey Farrell wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4114/
> -----------------------------------------------------------
> 
> (Updated Nov. 3, 2014, 11:55 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-24307
>     https://issues.asterisk.org/jira/browse/ASTERISK-24307
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> Any time a stringfield is blanked it currently prevents any currently allocated memory from being freed.  If a stringfield is repeatedly set to blank then set to a non-blank value, it causes new pools to be continuously allocated and never freed.
> 
> I'm unsure if the loop can be optimized, maybe the break can be re-added to the original location on the condition that ptr == __ast_string_field_empty?
> 
> 
> Diffs
> -----
> 
>   /branches/11/main/utils.c 427111 
>   /branches/11/include/asterisk/stringfields.h 427111 
> 
> Diff: https://reviewboard.asterisk.org/r/4114/diff/
> 
> 
> Testing
> -------
> 
> Manual test using https://github.com/elessard1/asterisk-lab/blob/master/examples/lab_stringfields_leak.c to verify that old pools are now freed.
> 
> Full testsuite against Asterisk 13.
> 
> 
> Thanks,
> 
> Corey Farrell
> 
>

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