Bug 614958 - Part 2: Protect the destruction of the callback objects the same way as the event sink object to avoid possible deadlock scenarios; r=bzbarsky a=blocking-beta8+

netwerk/base/src/nsSocketTransport2.cpp

@@ -1613,10 +1613,12 @@ nsSocketTransport::OnSocketDetached(PRFileDesc *fd)
     // the transport lock) possibly closing the socket. Also release our
     // listeners to break potential refcount cycles.
 
-    // We should be careful not to release mEventSink while we're locked,
+    // We should be careful not to release mEventSink and mCallbacks while
-    // because releasing it might require acquiring the lock again, so
+    // we're locked, because releasing it might require acquiring the lock
-    // we just null out mEventSink while we're holding the lock, and let
+    // again, so we just null out mEventSink and mCallbacks while we're
-    // ourEventSink's destuctor take care of destroying it if needed.
+    // holding the lock, and let the stack based objects' destuctors take
+    // care of destroying it if needed.
+    nsCOMPtr<nsIInterfaceRequestor> ourCallbacks;
     nsCOMPtr<nsITransportEventSink> ourEventSink;
     {
         nsAutoLock lock(mLock);
@@ -1632,7 +1634,7 @@ nsSocketTransport::OnSocketDetached(PRFileDesc *fd)
         // link with UI and security callbacks on next connection attempt 
         // round. That would lead e.g. to a broken certificate exception page.
         if (NS_FAILED(mCondition)) {
-            mCallbacks = nsnull;
+            mCallbacks.swap(ourCallbacks);
             mEventSink.swap(ourEventSink);
         }
     }