[asterisk-bugs] [JIRA] (ASTERISK-24760) Invalid pointer in ast_context_destroy during shutdown

[Sean Bright (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-24760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sean Bright closed ASTERISK-24760.
----------------------------------

                  Resolution: Fixed
    Target Release Version/s: 13.23.0

I'm fairly confident this would have been fixed by:

https://gerrit.asterisk.org/c/asterisk/+/467

If you continue to experience this problem, please re-open.

> Invalid pointer in ast_context_destroy during shutdown
> ------------------------------------------------------
>
>                 Key: ASTERISK-24760
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-24760
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Core/PBX
>    Affects Versions: SVN, 13.18.4
>            Reporter: Scott Griepentrog
>            Severity: Minor
>      Target Release: 13.23.0
>
>
> During CLI "core stop gracefully", valgrind detects an invalid read in __ast_context_destroy:
> {noformat}
> ==6990== Invalid read of size 1
> ==6990==    at 0x4C2B89E: strcasecmp (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==6990==    by 0x58DA11: __ast_context_destroy (pbx.c:10671)
> ==6990==    by 0x58E298: ast_context_destroy (pbx.c:10816)
> ==6990==    by 0x1325985B: unload_module (func_periodic_hook.c:454)
> ==6990==    by 0x53CF38: ast_module_shutdown (loader.c:610)
> ==6990==    by 0x4543B0: really_quit (asterisk.c:1961)
> ==6990==    by 0x454049: quit_handler (asterisk.c:1876)
> ==6990==    by 0x455306: handle_stop_gracefully (asterisk.c:2371)
> ==6990==    by 0x4DB118: ast_cli_command_full (cli.c:2719)
> ==6990==    by 0x4DB263: ast_cli_command_multiple_full (cli.c:2742)
> ==6990==    by 0x452F0E: netconsole (asterisk.c:1516)
> ==6990==    by 0x602F83: dummy_start (utils.c:1232)
> ==6990==  Address 0xd1fa190 is not stack'd, malloc'd or (recently) free'd
> {noformat}
> Occasionally the leak will be detected as coming from previously freed memory from another unrelated random portion of the code -- for which reason I believe this is a corrupted pointer rather than reference to free'd memory.



--
This message was sent by Atlassian JIRA
(v6.2#6252)