[asterisk-bugs] [Asterisk 0019114]: [patch] segfault res_musiconhold.so when called party puts call on hold

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=19114 
====================================================================== 
Reported By:                RcRaCk2k
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   19114
Category:                   Resources/res_musiconhold
Reproducibility:            sometimes
Severity:                   minor
Priority:                   normal
Status:                     feedback
Asterisk Version:           SVN 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): 1.8 
SVN Revision (number only!): 306540 
Request Review:              
====================================================================== 
Date Submitted:             2011-04-13 03:46 CDT
Last Modified:              2011-05-04 07:18 CDT
====================================================================== 
Summary:                    [patch] segfault res_musiconhold.so when called
party puts call on hold
Description: 
Dear Digitum,

we used Asterisk 1.6.0 a long tome before. Now we switched over to
Asterisk 1.8.3. The existing configuration worked without any
modifications.

The problem:
When a called party puts our line on hold to transfer the call, asterisk
is quit with a segfault in res_musiconhold.so. We can hear our MOH-Class
for a random time (2 - 20 seconds that might be the time to transfer), but
we have to hear the MOH from the other party, not the MOH from our
Asterisk-Server!

The big problem to track the bug down is, that this problem is not always
reproducible. Sometimes asterisk crashes, sometimes not. But asterisk
always crashes, when we can hear our MOH. Asterisk does not crash when we
can hear the MOH from the other party.

Our peer is a IAX2-Peer (pbx-network.de).
We considered this problem also on our backup IAX2-Peer (xlink.at).

Currently we run a trunk version of asterisk at revision 306540 but this
problem is still not fixed.

That is the syslog-message when asterisk quits:

Apr  1 09:34:37 voip-01 kernel: [10366699.967654] asterisk[11071]:
segfault at 6c003630 ip 00007f598962ba6f sp 00007f59700bfec0 error 4 in
res_musiconhold.so[7f5989625000+a000]
Apr  6 11:22:35 voip-01 kernel: [10805178.329682] asterisk[26102]:
segfault at 68003a00 ip 00007f758594da6f sp 00007f756c2c2ec0 error 4 in
res_musiconhold.so[7f7585947000+a000]
Apr  7 10:13:52 voip-01 kernel: [10887455.598158] asterisk[26676]:
segfault at c4004ba0 ip 00007f94e41aaa6f sp 00007f94caf26ea0 error 4 in
res_musiconhold.so[7f94e41a4000+a000]

The Asterisk is currently in a Live-Production field, so we could not put
our asterisk into a debug-state.
====================================================================== 

---------------------------------------------------------------------- 
 (0134414) mickeyratt (reporter) - 2011-05-04 07:18
 https://issues.asterisk.org/view.php?id=19114#c134414 
---------------------------------------------------------------------- 
Dear All

I encountered this problem with latest (1.6) 1.6.2.18 asterisk version
too. 
I using on production server for 1 month, so it is very frustrating. In
kern.log:

May  4 13:44:08 digium kernel: [3472685.931049] asterisk[26715]: segfault
at 880074a0 ip 00007f05acfec5db sp 00007f05945b4740 error 4 in
res_musiconhold.so[7f05acfe6000+a000]

Dear RcRaCk2k, can you share your "crontab" solution? Or may I use
safe_asterisk "to eliminate" this crash-problem? 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2011-05-04 07:18 mickeyratt     Note Added: 0134414                          
======================================================================