# HG changeset patch
# User Mark Doliner <mark@kingant.net>
# Date 1226993543 0
# Node ID 3d6fe79753c35999c98a7d5f93d05c4aeb6fc048
# Parent  caf82c1cebf2ceda1a5af7dd4681aac543bfa882
This should fix another crash I've seen.  We weren't correctly
cancelling the proxy connect when we destroyed the servconn
because we were only calling msn_servconn_disconnect() if we
had actually connected.

So always call msn_servconn_disconnect() from msn_servconn_destroy()
and let the disconnect function deal with only closing stuff that
is actually open.

Here's the backtrace:
#0  0x0000000000000000 in ?? ()
#1  0x00000000005f95e0 in connect_cb (data=0x2ab92ef6e7b0, source=7, error_message=0x0)
    at servconn.c:185
#2  0x000000000056e7da in purple_proxy_connect_data_connected (connect_data=0x2ab92ef70260)
    at proxy.c:598
#3  0x000000000056e90d in socket_ready_cb (data=0x2ab92ef70260, source=7, cond=PURPLE_INPUT_WRITE)
    at proxy.c:657
#4  0x00000000004db70c in pidgin_io_invoke (source=0x2ab92ee4be50, condition=G_IO_OUT,
    data=0x2ab92dfd3130) at gtkeventloop.cc:79

In frame 1, servconn is not valid (it has already been freed)

diff -r caf82c1cebf2 -r 3d6fe79753c3 libpurple/protocols/msn/servconn.c
--- a/libpurple/protocols/msn/servconn.c	Tue Nov 18 07:16:49 2008 +0000
+++ b/libpurple/protocols/msn/servconn.c	Tue Nov 18 07:32:23 2008 +0000
@@ -69,8 +69,7 @@
 		return;
 	}
 
-	if (servconn->connected)
-		msn_servconn_disconnect(servconn);
+	msn_servconn_disconnect(servconn);
 
 	if (servconn->destroy_cb)
 		servconn->destroy_cb(servconn);