Fix a crash that occurred when a BYE was received on a replaced dialog.

Reference counting for the channel and its tech_pvt got messed up at
some point between 1.8 and 11. The result was that if a BYE for a dialog
that had been replaced (via an INVITE with Replaces) was received, Asterisk
would crash due to trying to access data on a channel that was no longer there.

The fix I introduced is to remove code that both unrefs the sip_pvt and sets
the channel's tech_pvt to NULL when an INVITE with Replaces is handled. This
way when a BYE is received, the tech_pvt will be non-NULL and so the BYE can
be processed and not cause a crash.

(closes issue ASTERISK-20929)
reported by Kristopher Lalletti
patches:
	ASTERISK-20929.patch uploaded by Mark Michelson (License #5049)
........

Merged revisions 381566 from http://svn.asterisk.org/svn/asterisk/branches/11

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@381568 65c4cc65-6c06-0410-ace0-fbb531ad65f3

diff --git a/channels/chan_sip.c b/channels/chan_sip.c
index ab30761..af79f4b 100644 (file)
--- a/channels/chan_sip.c
+++ b/channels/chan_sip.c
@@ -24815,9 +24815,6 @@ static int handle_invite_replaces(struct sip_pvt *p, struct sip_request *req, st
        ast_setstate(c, AST_STATE_DOWN);
        ast_channel_unlock(c);
 
-       /* The call should be down with no ast_channel, so hang it up */
-       ast_channel_tech_pvt_set(c, dialog_unref(ast_channel_tech_pvt(c), "unref dialog c->tech_pvt"));
-
        /* c and c's tech pvt must be unlocked at this point for ast_hangup */
        ast_hangup(c);
        /* this indicates to handle_request_do that the owner channel has already been unlocked */