[asterisk-bugs] [JIRA] (ASTERISK-25663) Segfault in queue from MOH

[Mark Michelson (JIRA)]

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

Mark Michelson commented on ASTERISK-25663:
-------------------------------------------

I had a look at the backtrace. It's hard to tell anything concrete, but something that stands out in the full backtrace is:

{noformat}
#1  0x00000000004d6b68 in ast_openstream_full (chan=0x7fc5a45775c8, filename=0x5f746e6567412f31 <Address 0x5f746e6567412f31 out of bounds>, 
{noformat}

Note that the address of the filename is out of bounds. That makes it seem like Asterisk is attempting to access memory it should not be. The address of the filename is part of the queue object itself, which may mean the queue is undergoing some sort of change (possibly due to a reload, shutdown, or restart) at the time when the crash occurred. I suspect that the problem here is that access to the sound file strings is not being properly lock-protected, but I'm not 100% sure. Do you happen to know if there were any reloads or anything similar happening at the time of the crash?

> Segfault in queue from MOH
> --------------------------
>
>                 Key: ASTERISK-25663
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-25663
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Applications/app_queue
>    Affects Versions: 11.19.0
>         Environment: Centos
>            Reporter: Conrad de Wet
>         Attachments: 2016-01-06.txt
>
>
> The one Asterisk box crashed yesterday with a segfault. The fault was generated in in "ast_openstream_full" (from backtrace)
> Yesterday was a particular busy day (not the most). This queue could have had up to 300 people waiting in it on for up to 1 hour. 
> Also of interest the core dump was not in /tmp/ but rather in the moh folder (/var/lib/asterisk/moh/..../core.31562). This was no big deal (other than tricky to find), but clearly pointed to the problem being part of moh or some playback sound file issue.
> Last time this happened (about 3 months ago), the exact same thing happened. It was then that i converted all the moh files from .wav to .g729, in an attempt to avoid transcoding (if any). Clearly this didn't help. I see also in this case the "say_periodic_announcement" appear in the bt output - would it help to convert the announcements to .g729 also?
> I know some of the values are "<value optimized out>" but please can you look at this anyway - its really the only issue we have left with Asterisk... Or give me some guidance to get the queues to operate under high load correctly. It does seem the issue is with "ast_openstream_full", just not sure what.



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