[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=228945#comment-228945 ] 

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

Thanks for the information. In this case, I don't suspect the filesystem to be the problem, but literally the name of the file as stored in Asterisk's memory. You are correct that the problem occurred when attempting to play a periodic announcement.  If the periodic announcements were being changed in the database, that could be a possible explanation for the issue.

The queue contains an array of strings, which are the names of files to play back to a caller when waiting in a queue. I suspect that if the database's periodic announcements were changed, then that may mean that one thread in Asterisk was attempting to modify the array of file names while a separate thread was trying to access the array. Those operations should be mutually exclusive, but since they are not, it leads to the possibility of attempting to read freed/corrupted/incorrect memory from the array. I think the proper code fix within Asterisk is to ensure mutual exclusion on the operations involving the periodic announcement filenames.

As far as a workaround until the code is fixed, the only thing that I can think of is to perform database maintenance/alterations/etc. for the queue during times of inactivity if at all possible.

> 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)