[asterisk-commits] oej: branch 10 r335323 - in /branches/10: ./ channels/chan_sip.c

[SVN commits to the Asterisk project]

Author: oej
Date: Mon Sep 12 08:47:13 2011
New Revision: 335323

URL: http://svnview.digium.com/svn/asterisk?view=rev&rev=335323
Log:
Merged revisions 335319 via svnmerge from 
https://origsvn.digium.com/svn/asterisk/branches/1.8

........
  r335319 | oej | 2011-09-12 15:25:30 +0200 (Mån, 12 Sep 2011) | 12 lines
  
  Lock the peer->mvipvt to avoid crashes with SIP history enabled
  
  After the launch of 1.6 event-based MWI we have two threads handling the peer->mwipvt,
  which cause issues with SIP history additions in combination with the max limit for
  number of history entries.
  
  Review: https://reviewboard.asterisk.org/r/1373/
  
  (closes issue ASTERISK-18288)
  
  Thanks to irrot for peer review. Work with this bug funded by IPvision AS
........

Modified:
    branches/10/   (props changed)
    branches/10/channels/chan_sip.c

Propchange: branches/10/
------------------------------------------------------------------------------
Binary property 'branch-1.8-merged' - no diff available.

Modified: branches/10/channels/chan_sip.c
URL: http://svnview.digium.com/svn/asterisk/branches/10/channels/chan_sip.c?view=diff&rev=335323&r1=335322&r2=335323
==============================================================================
--- branches/10/channels/chan_sip.c (original)
+++ branches/10/channels/chan_sip.c Mon Sep 12 08:47:13 2011
@@ -14341,9 +14341,7 @@
 {
 	struct sip_peer *peer = userdata;
 
-	ao2_lock(peer);
 	sip_send_mwi_to_peer(peer, 0);
-	ao2_unlock(peer);
 }
 
 static void network_change_event_subscribe(void)
@@ -24909,9 +24907,7 @@
 			ast_set_flag(&p->flags[1], SIP_PAGE2_DIALOG_ESTABLISHED);
 			transmit_response(p, "200 OK", req);
 			if (p->relatedpeer) {	/* Send first notification */
-				ao2_lock(p->relatedpeer); /* was WRLOCK */
 				sip_send_mwi_to_peer(p->relatedpeer, 0);
-				ao2_unlock(p->relatedpeer);
 			}
 		} else if (p->subscribed != CALL_COMPLETION) {
 
@@ -25649,14 +25645,18 @@
 		}
 		ast_app_inboxcount(mailbox_str->str, &newmsgs, &oldmsgs);
 	}
+	ao2_lock(peer);
 
 	if (peer->mwipvt) {
 		/* Base message on subscription */
 		p = dialog_ref(peer->mwipvt, "sip_send_mwi_to_peer: Setting dialog ptr p from peer->mwipvt-- should this be done?");
 	} else {
 		/* Build temporary dialog for this message */
-		if (!(p = sip_alloc(NULL, NULL, 0, SIP_NOTIFY, NULL)))
+		if (!(p = sip_alloc(NULL, NULL, 0, SIP_NOTIFY, NULL))) {
+			ao2_unlock(peer);
 			return -1;
+		}
+
 		/* If we don't set the socket type to 0, then create_addr_from_peer will fail immediately if the peer
 		 * uses any transport other than UDP. We set the type to 0 here and then let create_addr_from_peer copy
 		 * the peer's socket information to the sip_pvt we just allocated
@@ -25684,11 +25684,17 @@
 		sip_scheddestroy(p, DEFAULT_TRANS_TIMEOUT);
 	}
 
+	/* We have multiple threads (mwi events and monitor retransmits) working with this PVT and as we modify the sip history if that's turned on,
+	   we really need to have a lock on it */
+	sip_pvt_lock(p);
+
 	/* Send MWI */
 	ast_set_flag(&p->flags[0], SIP_OUTGOING);
 	/* the following will decrement the refcount on p as it finishes */
 	transmit_notify_with_mwi(p, newmsgs, oldmsgs, peer->vmexten);
+	sip_pvt_unlock(p);
 	dialog_unref(p, "unref dialog ptr p just before it goes out of scope at the end of sip_send_mwi_to_peer.");
+	ao2_unlock(peer);
 	return 0;
 }