[asterisk-users] res_musiconhold.c Bug - Patch to solve?
John Novack
jnovack at stromberg-carlson.org
Mon Nov 22 07:32:33 CST 2010
Hasn't this been fixed in later versions?
1.4.37 is current, or at least it was in the last few days.
Upgrading with no reason isn't suggested, but in this case you have a
good reason, and if you dig deep enough you may find the fix is already
in place.
John Novack
Danny Dias wrote:
> Hello Asterisk community,
>
> We are having some problems with crashes in Asterisk, my asterisk
> versions are 1.4.24.1 and 1.4.23.2. I have found this:
>
> "~/work/asterisk-branch-1.4$ svn log -c 260345
> ------------------------------------------------------------------------
> r260345 | mmichelson | 2010-04-30 22:08:15 +0200 (Fri, 30 Apr 2010) | 18 lines
>
> Fix potential crash from race condition due to accessing channel data
> without the channel locked.
>
> In res_musiconhold.c, there are several places where a channel's
> stream's existence is checked prior to calling ast_closestream on it. The issue
> here is that in several cases, the channel was not locked while checking the
> stream. The result was that if two threads checked the state of the channel's
> stream at approximately the same time, then there could be a situation where
> both threads attempt to call ast_closestream on the channel's stream. The result
> here is that the refcount for the stream would go below 0, resulting in a crash.
>
> I have added proper channel locking to res_musiconhold.c to ensure that
> we do not try to check chan->stream without the channel locked. A
> Digium customer has been using this patch for several weeks and has not
> had any crashes since applying the patch.
>
> ABE-2147
> "
>
> How can i apply this patch on my asterisk versions: 1.4.24.1 and
> 1.4.23.2? do i have to apply this patch manually?
>
> Thanks in advance for your help
>
>
--
Dog is my Co-pilot
More information about the asterisk-users
mailing list