ASTERISK-14975: [patch] Asterisk crashes with "Fixup failed on channel XXX, strange things may happen."

[Home]

Summary: ASTERISK-14975: [patch] Asterisk crashes with "Fixup failed on channel XXX, strange things may happen."

Reporter: Benny Amorsen (amorsen) Labels:

Date Opened: 2009-10-12 08:23:30 Date Closed: 2010-09-21 12:34:34

Priority: Critical Regression? No

Status: Closed/Complete Components: Core/General

Versions: Frequency of
Occurrence

Related
Issues:

Environment: Attachments: ( 0) backtrace.24118
( 1) bug16057.diff2.txt
( 2) bug16057.diff3.txt
( 3) bug16057.diff4.txt
( 4) gdb.txt
( 5) valgrind-cleaned.24118

Description: [Oct 12 11:26:07] WARNING[1684] channel.c: Fixup failed on channel Local/1127-0004132c4403-1@DialLine-3d9b;1<MASQ>, strange things may happen.
[Oct 12 11:26:07] WARNING[1684] channel.c: Hangup failed! Strange things may happen!
[Oct 12 11:26:07] WARNING[1684] channel.c: Failed to perform masquerade
[Oct 12 11:26:07] WARNING[1684] channel.c: Channel 'Local/1127-0004132c4403-1@DialLine-3d9b;1' may not have been hung up properly

The bug happens several times a day.

****** ADDITIONAL INFORMATION ******

Asterisk is 1.6.0.16rc2. Valgrind output is attached, the interesting bits are probably these:

==24119== Invalid write of size 8
==24119== at 0x8FF2C06: local_hangup (chan_local.c:568)
==24119== by 0x444623: ast_hangup (channel.c:1722)
==24119== by 0x499FF8: __ast_pbx_run (pbx.c:3853)
==24119== by 0x49AD7A: pbx_thread (pbx.c:3945)
==24119== by 0x4D0AA7: dummy_start (utils.c:861)
==24119== by 0x5B7A869: start_thread (in /lib64/libpthread-2.10.1.so)
==24119== by 0x54DC3BC: clone (in /lib64/libc-2.10.1.so)
==24119== Address 0x1c968f08 is 8 bytes before a block of size 16 free'd
==24119== at 0x4C2433D: free (vg_replace_malloc.c:323)
==24119== by 0x47B1DB: __ast_module_user_remove (loader.c:219)
==24119== by 0x493007: ast_func_read (pbx.c:2789)
==24119== by 0x493A58: pbx_substitute_variables_helper_full (pbx.c:2921)
==24119== by 0x493EC2: pbx_substitute_variables_helper_full (pbx.c:2993)
==24119== by 0x494D89: pbx_extension_helper (pbx.c:3035)
==24119== by 0x49537F: ast_spawn_extension (pbx.c:3585)
==24119== by 0x499D2E: __ast_pbx_run (pbx.c:3672)
==24119== by 0x49AD7A: pbx_thread (pbx.c:3945)
==24119== by 0x4D0AA7: dummy_start (utils.c:861)
==24119== by 0x5B7A869: start_thread (in /lib64/libpthread-2.10.1.so)
==24119== by 0x54DC3BC: clone (in /lib64/libc-2.10.1.so)
==24119==
==24119== Invalid read of size 8
==24119== at 0x47B1B1: __ast_module_user_remove (loader.c:216)
==24119== by 0x8FF2C15: local_hangup (chan_local.c:570)
==24119== by 0x444623: ast_hangup (channel.c:1722)
==24119== by 0x499FF8: __ast_pbx_run (pbx.c:3853)
==24119== by 0x49AD7A: pbx_thread (pbx.c:3945)
==24119== by 0x4D0AA7: dummy_start (utils.c:861)
==24119== by 0x5B7A869: start_thread (in /lib64/libpthread-2.10.1.so)
==24119== by 0x54DC3BC: clone (in /lib64/libc-2.10.1.so)
==24119== Address 0x8 is not stack'd, malloc'd or (recently) free'd

Comments: By: Elazar Broad (ebroad) 2009-10-12 09:47:59

Please recompile with DONT_OPTIMIZE(in make menuconfig -> Compiler Flags). Thanks!
By: Benny Amorsen (amorsen) 2009-10-12 10:06:50

Right, I thought I had done that, but RPM tricked me. I'll do that and provide another backtrace.
By: Benny Amorsen (amorsen) 2009-10-13 07:19:14

The affected Asterisk has now run 16 hours without crashing after disabling optimizations. It seems that disabling optimizations masks the bug or at least reduces the frequency of crashes.
By: Leif Madsen (lmadsen) 2009-10-21 09:57:40

Could you provide some additional information such as console output when the crash happens, and some dialplan logic, etc... in order for us to reproduce the issue? This issue is just bizarre :)
By: Benny Amorsen (amorsen) 2009-10-22 04:17:04

The problem hasn't recurred after disabling optimizations. The particular Asterisk instance has crashed once since then, Friday the 16th, but not with "Failed to perform masquerade", and the valgrind log doesn't say anything about local_hangup or similar.

The only interesting bit around the time of the crash is:

valgrind: m_mallocfree.c:243 (get_bszB_as_is): Assertion 'bszB_lo == bszB_hi' failed.
valgrind: Heap block lo/hi size mismatch: lo = 88, hi = 4294967295.
Probably caused by overrunning/underrunning a heap block's bounds.

which isn't very enlightening.
By: Leif Madsen (lmadsen) 2009-10-26 10:45:32

Marking as Acknowledged in the hopes another developer will have a better idea of what else to request. Next step may be valgrind output?
By: Benny Amorsen (amorsen) 2009-10-27 05:48:44

Well, the problem appears to be masked by disabling optimizations. I guess you'll have to close this bug until someone else hits it, but of course it will likely go away for them as well when they turn optimizations off.
By: Leif Madsen (lmadsen) 2009-10-27 10:46:14

Ya, I'm going to leave this open for now to see if someone has an idea of how to start debugging this.

What version of GCC do you happen to be using?
By: Theo Belder (tbelder) 2009-12-11 09:26:16.000-0600

I have several crashes after see the following in the logfile:
[Dec 11 13:42:48] WARNING[7479] channel.c: Fixup failed on channel SIP/1313-b7bd88d0<MASQ>, strange things may happen.
[Dec 11 13:42:48] WARNING[7479] channel.c: Hangup failed! Strange things may happen!
[Dec 11 13:42:48] WARNING[7479] channel.c: Masquerade failed
[Dec 11 13:42:48] WARNING[7479] channel.c: Channel 'SIP/1313-b7bd88d0' may not have been hung up properly

Asterisk crashes after 10-15 seconds when these warnings are logged.

I have compiled asterisk with DONT_OPTIMIZE.

I've attached a gdb backtrace.
By: daren ferreira (daren) 2010-03-09 04:55:13.000-0600

For information, i previously worked with the same dialplan on 1.4.25.1 on a 686 kernel machine and moved yesterday to a 1.4.29.1 amd64 kernel, and now i get the same issue on 1.4.29.1 once

If problem occurs again, i will try the DONT_OPTIMIZE flag, i'll keep you informed

[Mar 9 11:22:34] WARNING[3581] channel.c: Fixup failed on channel IAX2/sortie1-15429<MASQ>, strange things may happen.
[Mar 9 11:22:34] WARNING[3581] channel.c: Hangup failed! Strange things may happen!
[Mar 9 11:22:34] WARNING[3581] channel.c: Masquerade failed
[Mar 9 11:22:34] WARNING[3581] channel.c: Channel 'IAX2/sortie1-15429' may not have been hung up properly

Then asterisk crashes
By: Theo Belder (tbelder) 2010-03-15 03:04:34

Please could somebody take a look at this and try to figure out what is going on here and why this bug occurs.
At one of our customers this issue occurs weekly. Even when Asterisk is compiled with DONT_OPTIMIZE.

Around 300 SIP peers are registered at this PBX and mostly they have more than 20 active calls.
By: Ramon Peek-Fares (ramonpeek) 2010-06-08 10:29:12

Hi there...
I'm a colleague of tbelder and see something interesting;

This bug seems to be occurring in combination with the use of Local Channels.
In our case we dial a Local channel and from that Local channel dial multiple other Local Channels. When one of those Local channels is answered we execute a new Dialplan (through the use of the dial option "M()").
Directly after this part of the dialplan is executed the asterisk displays the "Fixup Failed" error and becomes unstable.

Can anyone confirm any similarities with our dialplan setup?
This might help in trying to find the reason why this error is occurring...
By: Ramon Peek-Fares (ramonpeek) 2010-06-29 05:23:47

When this error occurs, it always happens after a SIP device answers a call that was dialed via multiple LOCAL channels.

So, I've got a theory what might be going wrong;
--- maybe someone might see the light ;-) ---

Scenario:
-----------
- A call is made to an extension that initiates a call via a LOCAL channel to a new part of the dialplan.
- This part of the dialplan executes numerous dial statements for other LOCAL channels, resulting in two or more LOCAL channels based on the first LOCAL channel. (we do this to create special huntgroups)
- From these extra LOCAL channels different SIP devices are called.

My theory:
-----------
When one of the SIP devices answers the LOCAL channels are being bridged an removed from the channels list. But I think that in some cases the first LOCAL channel is being removed from the channels list before all other LOCAL channels that were initiated from this LOCAL channel were removed.
Because our traces indeed show that the first LOCAL channel was indeed removed before all other LOCAL channels were removed.

To test my theory I used the "/n" dial option on the dial statement for the first LOCAL channel and since that change this error hasn't occurred anymore.
However using the "/n" dial option is not really what I want and caused other problems for me, so we need a real solution instead of this workaround.

Also I can easily imagine that this problem can also occur on non-LOCAL channels, just as long as there is a chance that the "mother" channel is being removed from the channel list before all "child" channels this theory should stand.

Anyone with better knowledge about the asterisk code have any comment on this theory?
By: Paul Belanger (pabelanger) 2010-06-29 06:40:30

Please retest with 1.6.2
---
Per the Asterisk maintenance timeline page at http://www.asterisk.org/asterisk-versions maintenance (bug) support for the 1.6.0 and 1.6.1 branches has ended. For continued maintenance support please move to the 1.6.2 branch.

More information on this change can be found in the release announcement: http://www.asterisk.org/node/49924
By: Ramon Peek-Fares (ramonpeek) 2010-06-29 06:54:07

I'm running the latest "maintained" Asterisk 1.4.33.
Do you really want me to upgrade to Asterisk 1.6.2 for this issue? since that would involve a lot of changes to my system that I'm not so keen on doing ;-)
By: David Woolley (davidw) 2010-06-29 08:17:40

Please look at ASTERISK-16118. I think it may be related/duplicate. (Incidentally, I think that one should be confirmed, rather than just acknowledged.)
By: Paul Belanger (pabelanger) 2010-06-29 08:31:00

@ramonpeek: The original issue referenced 1.6.0.16-rc2, however 1.4.33 is also find. Updating issue.
By: Ramon Peek-Fares (ramonpeek) 2010-06-29 09:21:15

@davidw: I agree that issue ASTERISK-16118 seems related, but if that is the case, it would mean that the ChanRedirect feature invokes similar behavior as when Local Channels are being removed from the channels list during a bridge.

So am I a wrong in saying we might need to look towards the code responsible for cleaning up bridged channels?

By: David Woolley (davidw) 2010-06-29 09:23:56

ASTERISK-1712363 is a collision between a channel redirect and the removal (optimisation) of a local channel following a bridge. The important side is the local channel, because the masquerade is done in two steps, so it is possible for a conflicting masquerade to intervene.
By: Ramon Peek-Fares (ramonpeek) 2010-07-12 01:47:30

OK, I'll Try the patch attached to issue: ASTERISK-16118
But don't expect results to soon, it usually takes a couple of weeks for this error to occur in our situation :-(
By: Ramon Peek-Fares (ramonpeek) 2010-07-23 09:09:44

I've installed the patch but apparently it didn't really fix it.
Sadly I haven't got too much logging, however the new CLI output that I'm now getting (used to run 1.4.21) is more promising.

It makes me believe this case is related to issue ASTERISK-15819
All the signs really point into that direction
By: Ramon Peek-Fares (ramonpeek) 2010-07-23 11:25:08

I noticed that "tilghman" has closed issue ASTERISK-15819 because he considers it fixed.
However at least in the latest v1.4 branch it is not, since I'm seeing the exact same thing happening om my systems.

Also, I've looked at the code in ASTERISK-15819 but it differs too much in v1.4 for me to backport that code.

Any assistance is very much appreciated.
By: Alec Davis (alecdavis) 2010-09-15 05:06:29

ast_do_masquerade: Hangup failed! Strange things may happen!

Finally caught the following log: 2 planned masq's, but are recursive. 7->10 and 0->7<pre>
[Sep 15 19:57:24] DEBUG[26290] channel.c: Planning to masquerade channel Local/10007@phones-3e58;1 into the structure of Local/10010@phones-7008;1
[Sep 15 19:57:24] DEBUG[26290] channel.c: Done planning to masquerade channel Local/10007@phones-3e58;1 into the structure of Local/10010@phones-7008;1
[Sep 15 19:57:24] DEBUG[26290] chan_local.c: Not posting to queue since already masked on 'Local/10010@phones-7008;2'

[Sep 15 19:57:24] DEBUG[26293] channel.c: Planning to masquerade channel Local/10000@phones-5a27;1 into the structure of Local/10007@phones-3e58;1
[Sep 15 19:57:24] DEBUG[26293] channel.c: Done planning to masquerade channel Local/10000@phones-5a27;1 into the structure of Local/10007@phones-3e58;1
[Sep 15 19:57:24] DEBUG[26293] chan_local.c: Not posting to queue since already masked on 'Local/10007@phones-3e58;2'

[Sep 15 19:57:24] DEBUG[26293] chan_local.c: Not posting to queue since already masked on 'Local/10007@phones-3e58;2'

[Sep 15 19:57:24] DEBUG[26289] channel.c: Putting channel Local/10007@phones-3e58;1 in alaw/alaw formats
[Sep 15 19:57:24] DEBUG[26289] channel.c: Released clone lock on 'Local/10010@phones-7008;1<ZOMBIE>'
[Sep 15 19:57:24] DEBUG[26289] channel.c: Done Masquerading Local/10007@phones-3e58;1 (6)

[Sep 15 19:57:24] DEBUG[26293] chan_local.c: Not posting to queue since already masked on 'Local/10007@phones-3e58;2'

[Sep 15 19:57:24] DEBUG[26289] chan_local.c: Not posting to queue since already masked on 'Local/10007@phones-3e58;1'

[Sep 15 19:57:24] WARNING[26290] channel.c: Fixup failed on channel Local/10000@phones-5a27;1<MASQ>, strange things may happen.
[Sep 15 19:57:24] WARNING[26290] channel.c: Hangup failed! Strange things may happen!</pre>

patch bug16057.diff.txt is for trunk, the key here is to check the original->masqr if it's set then a planned masq, hasn't yet happened.

By: David Woolley (davidw) 2010-09-15 05:17:58

This patch is logically the same as ASTERISK-1712363, except that it includes the fourth variation. I called mine minimal, because I had excluded that variation, not because I didn't suspect it needed to be covered, but because I wanted to do the minimum change to actually cover the case that we observed.
By: Alec Davis (alecdavis) 2010-09-15 05:44:01

davidw: we are in agreeance then.
All 4 variations are required as per this patch, I'd only observed the original->masqr where a 'fixed failed on channel' would be reported.

I included the clonechan->masq as it seemed like the right thing to do, but as I've now found you already had found this.

Sorry, I was unaware of your fix until after I'd submitted patch, guess because I'd missed your note in this bug.

By: Alec Davis (alecdavis) 2010-09-15 06:01:55

dialplan to reliably reproduce this:
Dial 10020 for 20 loops.<pre>[test]
exten => _10000,1,Answer()
exten => _10000,n,Playback(test-tones-follow)
exten => _10000,n,Milliwatt()

exten => _1XXXX,1,Set(i=${MATH(${EXTEN}-1,int)})
exten => _1XXXX,n,Dial(Local/${i}@test,,r)</pre>

debug output with patch applied, and recursive masq triggered:<pre>[Sep 15 21:27:16] DEBUG[15560] channel.c: Planning to masquerade channel Local/10003@phones-d001;1 into the structure of Local/10004@phones-a560;1
[Sep 15 21:27:16] DEBUG[15560] channel.c: Done planning to masquerade channel Local/10003@phones-d001;1 into the structure of Local/10004@phones-a560;1
[Sep 15 21:27:16] DEBUG[15554] chan_dahdi.c: Requested indication 26 on channel DAHDI/33-1
[Sep 15 21:27:16] DEBUG[15560] chan_local.c: Not posting to queue since already masked on 'Local/10004@phones-a560;2'
[Sep 15 21:27:16] DEBUG[15560] chan_local.c: Not posting to queue since already masked on 'Local/10004@phones-a560;2'
[Sep 15 21:27:16] DEBUG[15561] channel.c: Planning to masquerade channel Local/10000@phones-9afa;1 into the structure of Local/10003@phones-d001;1
[Sep 15 21:27:16] WARNING[15561] channel.c: Local/10003@phones-d001;1 is already going to masquerade as Local/10004@phones-a560;1
[Sep 15 21:27:16] DEBUG[15561] chan_local.c: Not posting to queue since already masked on 'Local/10003@phones-d001;2'
[Sep 15 21:27:16] DEBUG[15561] chan_local.c: Not posting to queue since already masked on 'Local/10003@phones-d001;2'
[Sep 15 21:27:16] DEBUG[15562] channel.c: Bridge stops bridging channels Local/10002@phones-ad5e;2 and Local/10002@phones-ad5e;1<ZOMBIE></pre>

By: Alec Davis (alecdavis) 2010-09-15 07:15:15

bug16057.diff2.txt

refactored the original and clonechan checks, as a majority of the time the first test is the likely outcome.
By: Alec Davis (alecdavis) 2010-09-17 00:21:30

uploaded patch bug16057.diff3.txt

Includes previous patches from above notes.
Also defer ao2_unlock(channels) to end of ast_do_masquerade

Now a test call of 30 loops to the local channel, 'core show channles' never have a container left with a blank channel details.
Never after hanging up, are any ao2_containers left.

Also rformat and wformat, not collected until we have a sucessful lock.
By: Alec Davis (alecdavis) 2010-09-17 00:25:33

console output looped 48 times:<pre>
*CLI> core show channels verbose
Channel Context Extension Prio State Application Data CallerID Duration Accountcode PeerAccount BridgedTo
Local/10000@phones-9 phones 1 Up AppDial (Outgoing Line) 10048 00:00:18 SIP/GXP0001-00000002
Local/10000@phones-9 phones 10000 3 Up Milliwatt (Empty) GXP0001 00:00:18 (None)
SIP/GXP0001-00000002 trusted 10048 2 Up Dial Local/10047@phones GXP0001 00:00:18 Local/10000@phones-9
3 active channels
2 active calls
141 calls processed
</pre>
By: David Woolley (davidw) 2010-09-17 04:54:37

Checking for all for variants of conflicting masquerade is still needed, even if there is a secondary problem in failing to recover from failing to initiate the masquerade.
By: Alec Davis (alecdavis) 2010-09-17 06:43:41

We are now checking the 4 variants (orig/clone + masq/masqr), are you suggesting there are more?
By: David Woolley (davidw) 2010-09-17 07:09:08

No. There were changes last night including some that were deleted, but I got the impression that the problem was being re-analysed, and I just wanted to make sure that this part didn't get lost in the process.
By: Alec Davis (alecdavis) 2010-09-17 15:38:22

ramonpeek: your note at ~123996 exactly describes what the fixes in bug16057.diff3.txt please test and feedback.

When I get a couple of confirmeation that this fixes the issue, I'm happy to commit to maintained releases.
By: Ramon Peek-Fares (ramonpeek) 2010-09-18 14:19:11

alecdavis:
I will definitely test your patch, I've already applied the patch provided in ASTERISK-16118 which is clearly related, and it showed a large improvement on our systems.
However we have still seen the SIP channel failing to respond to new incoming messages, but felt it had more to do with issue ASTERISK-16593.
Nevertheless this last change in your patch seems to me to make a lot of sense, so I'll apply it asap.

However I don't have any real way to reproduce the issue on my system.
So it will be a matter of time to learn whether or not its really fixed.
Perhaps you know an easy way to reproduce it?

By: Ramon Peek-Fares (ramonpeek) 2010-09-18 14:32:41

PS: How about issue ASTERISK-16512?
I've read your comment in that issue, but does this mean the 'Bad Magic Number" issue is 100% related?
In other words; Is it wise to also apply the patch for that issue to my system?
By: Alec Davis (alecdavis) 2010-09-18 15:34:20

ramonpeek, watch the reviewboard link that I added to this report.
It's currently got a more relevant fix.
By: Ramon Peek-Fares (ramonpeek) 2010-09-20 02:00:29

alecdavis: We are using Asterisk 1.4.36 on our systems, so am I correct in assuming only the first part of this patch applies on 1.4.36 systems?
Because the code in "ast_do_masquerade" has changed so much that I don't see anyway to apply these parts. (perhaps they aren't even needed)
By: Alec Davis (alecdavis) 2010-09-20 04:48:45

ramonpeek: Your right, the first part in ast_channel_masquerade avoids the reported 'Fixup failed on channel' issue.

The 2nd part related to ao2_lock/unlock(channles) in ast_do_masquerade is not related to this bug, it's avoids the dreaded 'Bad Magic number' caused by masquerading - but doesn't fix whatever is actually causing the issue - another of those 'avoidance' techniques.
By: Digium Subversion (svnbot) 2010-09-20 17:57:50

Repository: asterisk
Revision: 287682

U branches/1.4/main/channel.c

------------------------------------------------------------------------
r287682 | alecdavis | 2010-09-20 17:57:49 -0500 (Mon, 20 Sep 2010) | 18 lines

ast_channel_masquerade: Avoid recursive masquerades.

Check all 4 combinations of (original/clonechan) * (masq/masqr).

Initially original->masq and clonechan->masqr were only checked.

It's possible with multiple masq's planned - and not yet executed, that
the 'original' chan could already have another masq'd into it - thus original->masqr
would be set, that masqr would lost.
Likewise for the clonechan->masq.

(closes issue ASTERISK-14975;ASTERISK-16118)
Reported by: amorsen;davidw,alecdavis
Patches:
bug16057.diff4.txt uploaded by alecdavis (license 585)
Tested by: ramonpeek, davidw, alecdavis

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

http://svn.digium.com/view/asterisk?view=rev&revision=287682
By: Digium Subversion (svnbot) 2010-09-20 18:15:26

Repository: asterisk
Revision: 287684

U branches/1.4/main/channel.c

------------------------------------------------------------------------
r287684 | alecdavis | 2010-09-20 18:15:26 -0500 (Mon, 20 Sep 2010) | 10 lines

ast_channel_masquerade: remove extra else if

(closes issue ASTERISK-16118,ASTERISK-14975)

Reported by: amorsen;davidw,alecdavis
Patches:
based on bug16057.diff4.txt uploaded by alecdavis (license 585)
Tested by: ramonpeek, davidw, alecdavis

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

http://svn.digium.com/view/asterisk?view=rev&revision=287684
By: Digium Subversion (svnbot) 2010-09-20 18:16:46

Repository: asterisk
Revision: 287685

U branches/1.6.2/main/channel.c

------------------------------------------------------------------------
r287685 | alecdavis | 2010-09-20 18:16:45 -0500 (Mon, 20 Sep 2010) | 18 lines

ast_channel_masquerade: Avoid recursive masquerades.

Check all 4 combinations of (original/clonechan) * (masq/masqr).

Initially original->masq and clonechan->masqr were only checked.

It's possible with multiple masq's planned - and not yet executed, that
the 'original' chan could already have another masq'd into it - thus original->masqr
would be set, that masqr would lost.
Likewise for the clonechan->masq.

(closes issue ASTERISK-14975;ASTERISK-16118)
Reported by: amorsen;davidw,alecdavis
Patches:
based on bug16057.diff4.txt uploaded by alecdavis (license 585)
Tested by: ramonpeek, davidw, alecdavis

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

http://svn.digium.com/view/asterisk?view=rev&revision=287685
By: Digium Subversion (svnbot) 2010-09-20 18:20:07

Repository: asterisk
Revision: 287701

_U branches/1.8/
U branches/1.8/main/channel.c

------------------------------------------------------------------------
r287701 | alecdavis | 2010-09-20 18:20:06 -0500 (Mon, 20 Sep 2010) | 24 lines

Merged revisions 287685 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2

........
r287685 | alecdavis | 2010-09-21 11:16:45 +1200 (Tue, 21 Sep 2010) | 18 lines

ast_channel_masquerade: Avoid recursive masquerades.

Check all 4 combinations of (original/clonechan) * (masq/masqr).

Initially original->masq and clonechan->masqr were only checked.

It's possible with multiple masq's planned - and not yet executed, that
the 'original' chan could already have another masq'd into it - thus original->masqr
would be set, that masqr would lost.
Likewise for the clonechan->masq.

(closes issue ASTERISK-14975;ASTERISK-16118)
Reported by: amorsen;davidw,alecdavis
Patches:
based on bug16057.diff4.txt uploaded by alecdavis (license 585)
Tested by: ramonpeek, davidw, alecdavis
........

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

http://svn.digium.com/view/asterisk?view=rev&revision=287701
By: Digium Subversion (svnbot) 2010-09-20 18:42:58

Repository: asterisk
Revision: 287756

_U trunk/
U trunk/main/channel.c

------------------------------------------------------------------------
r287756 | alecdavis | 2010-09-20 18:42:57 -0500 (Mon, 20 Sep 2010) | 24 lines

Merged revisions 287685 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2

........
r287685 | alecdavis | 2010-09-21 11:16:45 +1200 (Tue, 21 Sep 2010) | 18 lines

ast_channel_masquerade: Avoid recursive masquerades.

Check all 4 combinations of (original/clonechan) * (masq/masqr).

Initially original->masq and clonechan->masqr were only checked.

It's possible with multiple masq's planned - and not yet executed, that
the 'original' chan could already have another masq'd into it - thus original->masqr
would be set, that masqr would lost.
Likewise for the clonechan->masq.

(closes issue ASTERISK-14975;ASTERISK-16118)
Reported by: amorsen;davidw,alecdavis
Patches:
based on bug16057.diff4.txt uploaded by alecdavis (license 585)
Tested by: ramonpeek, davidw, alecdavis
........

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

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