[asterisk-bugs] [JIRA] (ASTERISK-22467) [patch] memory leaks 1.8+

Wed Oct 23 11:58:03 CDT 2013

    [ https://issues.asterisk.org/jira/browse/ASTERISK-22467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=211059#comment-211059 ] 

Jonathan Rose edited comment on ASTERISK-22467 at 10/23/13 11:56 AM:
---------------------------------------------------------------------

{{checklist}}
{{---------}}

app_voicemail-1.8.patch
app_voicemail-11up.patch
ast_app_parse_timelen-fail-zero-length.patch
astobj2-clean-debug-cli-1.8-11.patch
astobj2-clean-debug-cli-12up.patch
{color:orange}chan_dahdi-free_pfds.patch - I have doubts about this one. It seems safe since there should only be one thread working on pfds at a time, but I kind of feel that the thread should simply be responsible for cleaning up after itself in all paths rather than having a post pthread_join cleanup like this. Consider the use of pthread_cleanup_push perhaps? Alternatively just make sure that the thread can't cancel until it has taken care of pfds.{color}
{color:blue}chan_sip-parse_contact_header_test-free-contacts.patch - accepted, awaiting commit{color}
clicompat.patch
{color:blue}cli-filename-completion-leak.patch - accepted, awaiting commit{color}
codecs-ilbc-doCPLC.patch
data-cleanup-test-registration.patch
{color:blue}func_math.patch - accepted, awaiting commit{color}
jitterbuf-jb_reset-leak-1.8.patch
jitterbuf-jb_reset-leak-11up.patch
main-asterisk-kill-listener.patch
{color:blue}main-test-cleanup.patch - accepted, awaiting commit{color}
main-utils-1.8.patch
main-utils-11.patch
main-utils-12up.patch
{color:blue}test_dlinklists.patch - accepted, awaiting commit{color}
test_linkedlists-1.8.patch
test_linkedlists-11up.patch

      was (Author: jrose):
    {{checklist}}
{{---------}}

app_voicemail-1.8.patch
app_voicemail-11up.patch
ast_app_parse_timelen-fail-zero-length.patch
astobj2-clean-debug-cli-1.8-11.patch
astobj2-clean-debug-cli-12up.patch
{color:orange}chan_dahdi-free_pfds.patch - I have doubts about this one. It seems safe since there should only be one thread working on pfds at a time, but I kind of feel that the thread should simply be responsible for cleaning up after itself in all paths rather than having a post pthread_join cleanup like this. Consider the use of pthread_cleanup_push perhaps? Alternatively just make sure that the thread can't cancel until it has taken care of pfds.{color}
chan_sip-parse_contact_header_test-free-contacts.patch
clicompat.patch
{color:blue}cli-filename-completion-leak.patch - accepted, awaiting commit{color}
codecs-ilbc-doCPLC.patch
data-cleanup-test-registration.patch
{color:blue}func_math.patch - accepted, awaiting commit{color}
jitterbuf-jb_reset-leak-1.8.patch
jitterbuf-jb_reset-leak-11up.patch
main-asterisk-kill-listener.patch
{color:blue}main-test-cleanup.patch - accepted, awaiting commit{color}
main-utils-1.8.patch
main-utils-11.patch
main-utils-12up.patch
{color:blue}test_dlinklists.patch - accepted, awaiting commit{color}
test_linkedlists-1.8.patch
test_linkedlists-11up.patch

> [patch] memory leaks 1.8+
> -------------------------
>
>                 Key: ASTERISK-22467
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-22467
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Applications/app_voicemail, Channels/chan_dahdi, Channels/chan_sip/General, Codecs/codec_ilbc, Core/General, Core/Jitterbuffer, Functions/func_math, Tests/General
>    Affects Versions: SVN, 1.8.24.0, 11.6.0, 12.0.0-alpha1
>            Reporter: Corey Farrell
>            Assignee: Jonathan Rose
>            Severity: Minor
>         Attachments: app_voicemail-11up.patch, app_voicemail-1.8.patch, ast_app_parse_timelen-fail-zero-length.patch, ast_app_parse_timelen-initialize-vars.patch, astobj2-clean-debug-cli-12up.patch, astobj2-clean-debug-cli-1.8-11.patch, chan_dahdi-free_pfds.patch, chan_sip-parse_contact_header_test-free-contacts.patch, clicompat.patch, cli-filename-completion-leak.patch, codecs-ilbc-doCPLC.patch, data-cleanup-test-registration.patch, func_math.patch, jitterbuf-jb_reset-leak-11up.patch, jitterbuf-jb_reset-leak-1.8.patch, main-asterisk-kill-listener.patch, main-test-cleanup.patch, main-utils-11.patch, main-utils-12up.patch, main-utils-1.8.patch, test_dlinklists.patch, test_linkedlists-11up.patch, test_linkedlists-1.8.patch
>
>
> Patches for memory leaks found with 'test execute all'.  Compile/run tests done for 1.8/11.  Compile only test for 12, for trunk I only verified that the patches applied.
> channels/sip/reqresp_parser.c: parse_contact_header_test leaks contacts
> channels/chan_dahdi.c: pfds from do_monitor() leaks
> codecs/ilbc/doCPLC.c: doThePLC() possible uninitialized use of max_per (reported as error by gcc with dev-mode and codec's embedded)
> funcs/func_math.c: test_MATH_function leaks expr + result
> main/editline/readline.c: filename completion leaks filename/dirname
> main/app.c: ast_app_parse_timelen() can use 'amount' uninitialized (reported by valgrind)
> main/asterisk.c: listener thread not joined, sig_alert_pipe not closed
> main/astobj2.c: AO2_DEBUG/TEST_FRAMEWORK cli commands not unregistered
> main/data.c: test not unregistered
> main/test.c: cli commands not unregistered
> tests/test_dlinklist.c: dll_tests leaks test container and record "b"
> apps/app_voicemail.c:  result of find_user is leaked in some places
> -- test_voicemail_msgcount (all versions)
> -- acf_vm_info in (11+).
> main/jitterbuffer.c:
> -- jb_reset() causes frame cache (jb->free) to leak.
> -- switch jb_new to ast_calloc to prevent uninitialized field access during first jb_reset.
> main/utils.c:
> -- DEBUG_THREADS cli commands not unregistered (all versions)
> -- dev_urandom_fd is not closed (11+)
> -- handle_show_locks leaks ast_str_create (1.8/11)
> tests/test_linkedlist.c:
> -- single_ll_tests leaks buf (all versions)
> -- double_ll_tests leaks buf (11+)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira