[Home]

Summary:ASTERISK-12741: [patch] Crash in res_musiconhold
Reporter:Francois-Alexandre St-Onge Aubut (fst-onge)Labels:
Date Opened:2008-09-16 12:57:51Date Closed:2009-02-12 00:36:48.000-0600
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Resources/res_musiconhold
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) bt.txt
( 1) bt2.txt
( 2) filestream_frame_1_4.diff
Description:We have experienced a crash with music on hold module . all our files are in WAV format
Comments:By: Francois-Alexandre St-Onge Aubut (fst-onge) 2008-09-16 13:00:33

we did not recompile asterisk without optimization as this is the first time we experienced that
By: Francois-Alexandre St-Onge Aubut (fst-onge) 2008-10-06 14:28:20

recurring issue, no change in versions, running kernel 2.6.18-8.el5 x64
By: Francois-Alexandre St-Onge Aubut (fst-onge) 2008-10-06 14:35:17

could this issue be linked with the system library not up2date?, should whe upgrade Glibc to the latest version?
By: Leif Madsen (lmadsen) 2008-10-06 14:37:30

Can you provide some additional information? The backtraces here won't be useful as the values are optimized out, so you'll need to reproduce with DONT_OPTIMIZE. Also, what does your configuration look like in regards to Music on Hold? Whatever information you can provide to help us reproduce the issue would make this move forward much faster.

Thanks!
By: Francois-Alexandre St-Onge Aubut (fst-onge) 2008-10-06 14:49:25

this system is in production, can DONT_OPTIMIZE affect calls?

moh config

[default]
mode=files
directory=/var/lib/asterisk/mohmp3
random=yes

moh file is in 8000hz 8bits mono
By: Leif Madsen (lmadsen) 2008-10-07 12:12:22

DONT_OPTIMIZE has very little effect on the system, and is safe to run in production. When you have a backtrace that is useful, please attach it here.
By: Mark Michelson (mmichelson) 2008-11-12 15:34:15.000-0600

I believe to have found the source of this crash.

The problem comes from the fact that we are trying to refer to a frame which is embedded in a structure which has been previously freed. I have written a patch for this called filestream_frame_1_4.diff.

This patch was created against the 1.4 branch, but I expect that it will apply cleanly to most later 1.4 releases as well. If there are any troubles when attempting to apply the patch, let me know and I'll make a new one for whichever release it did not apply cleanly to.

Thanks!
By: Mark Michelson (mmichelson) 2008-11-20 12:03:22.000-0600

I know it's a bit unorthodox to commit something before the reporter of the issue has confirmed that the issue is fixed, but in this particular case, my valgrind tests plus confirmation from an external source lead me to believe this issue is fixed and can be closed. Please fee free to re-open if you experience the same crash again.
By: Mark Michelson (mmichelson) 2008-11-20 13:28:30.000-0600

This is fixed in revision 158126 of 1.4 and revision 158133 of trunk.
By: Digium Subversion (svnbot) 2008-12-22 10:30:21.000-0600

Repository: asterisk
Revision: 166278

U   branches/1.6.0/include/asterisk/file.h
U   branches/1.6.0/include/asterisk/frame.h
U   branches/1.6.0/main/file.c
U   branches/1.6.0/main/frame.c

------------------------------------------------------------------------
r166278 | mmichelson | 2008-12-22 10:30:21 -0600 (Mon, 22 Dec 2008) | 8 lines

When merging the fix for issue ASTERISK-13252, I found that
the issue didn't affect 1.6.0, but in this case that's
not an especially good thing, because it means that
the fix for issue ASTERISK-12741 was not merged into 1.6.0 in
the first place. This commit kills two birds with one
stone by putting both fixes in the 1.6.0 branch


------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=166278