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

[Conrad de Wet (JIRA)]

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

Conrad de Wet commented on ASTERISK-25663:
------------------------------------------

Right, some background:
1 - The queues run from the MySQL real time system. So they don't go through a reload at any point.
2 - There are about 1300 queues in the database.
3 - The music on hold files have not changed in months.
4 - It's possible (but quite unlikely) the the periodic announcements where being fiddled with at the time of the crash - although i notice that the  bt also mentions "say_periodic_announcement", so maybe the  "ast_openstream_full" was trying to play a periodic announcement at the time of the crash.
5 - The only other handling of the media files is that, they (both announcements and moh), are synced from a src folder. This is kind of like a "staged" and "live" system to avoid these kind of issues. The command is: rsync -a --delete --bwlimit=500 /var/lib/asterisk/sounds-src/ /var/lib/asterisk/sounds/. All uploads get put in sounds-src, and the rsync does a sync every few minutes. 

So maybe in rsync getting a lock on the file exactly at the same time that Asterisk is attempting to read it - its causing an issue. However, I don't see how this would cause "the address of the filename is out of bounds". Then again i have no idea of the file locks etc etc behind rsync.

That's, all i can think of for now,
Thanks for the feedback.

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