[asterisk-bugs] [JIRA] (ASTERISK-20792) Segfault during calloc, core dump shows logging string at requested pointer address

[Emiel Suilen (JIRA)]

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

Emiel Suilen commented on ASTERISK-20792:
-----------------------------------------

I attached the full log (verbose level 10) for 2 minutes up to the crash, and a shortened version of it. Both were anonymized. The line which we see more frequently around crashes are the following two:
[Nov 28 11:56:57] VERBOSE[2463] res_musiconhold.c: [Nov 28 11:56:57]     -- Stopped music on hold on SIP/192.168.15.11-00002e2f
[Nov 28 11:56:57] VERBOSE[399] pbx.c: [Nov 28 11:56:57]   == Spawn extension (default, 1001, 90) exited non-zero on 'SIP/991operator1-00002e75<ZOMBIE>'

We also saw this for version 1.8.17.2
                
> Segfault during calloc, core dump shows logging string at requested pointer address
> -----------------------------------------------------------------------------------
>
>                 Key: ASTERISK-20792
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-20792
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: General
>         Environment: CentOS 6.3 (Final)
> Kernel 2.6.32-279.9.1el6.x86_64
> 4 Gb memory, single Intel Xeon E6520
> Asterisk 1.8.7.2
>            Reporter: Emiel Suilen
>            Severity: Critical
>         Attachments: bt, bt_full, edited_full, edited_full_short, p_addr
>
>
> In an environment with many calls (>4k calls/24 hours)  and full logging turned on, our customer experiences occasional crashes. A backtrace of the core dump shows this happens during channel creation, and that the pointer used for the channel is overwriting a string used by the logger.
> Attached are the backtrace, full backtrace, and an examination of the relevant frame in GDB, which shows that the allocated pointer already holds information, that starts several blocks earlier.
> A full core dump cannot be provided, due to the size. The core dump originated from 1.8.7.2, but the same core dumps were also found in higher versions. Unfortunately, these were compiled without debug info. We are unable to reproduce this for other customers, or on single user machines.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira