/pidgin/main: 3f47965d439f: Possibly fix the crash mentioned in ...

[Mark Doliner]

Changeset: 3f47965d439f7b5dbb1c5a705b45473d1a11276e
Author:	 Mark Doliner <mark at kingant.net>
Date:	 2013-02-25 22:12 -0800
Branch:	 default
URL: https://hg.pidgin.im/pidgin/main/rev/3f47965d439f

Description:

Possibly fix the crash mentioned in #15067.

It's weird that this code was setting connect_data to NULL without
calling purple_proxy_connect_cancel().  Like, if there's a chance
that connect_data is non-NULL then you need to cancel the existing
connection attempt before making a new one.

I'm not sure if this happens in legitimate circumstances.  It seems
like if the server gives us duplicate NS_BYTESTREAMS responses then
maybe we would call jabber_bytestreams_parse twice with the same jsx
which could lead to a dangling callback.

diffstat:

 libpurple/protocols/jabber/si.c |  11 ++++++++++-
 1 files changed, 10 insertions(+), 1 deletions(-)

diffs (21 lines):

diff --git a/libpurple/protocols/jabber/si.c b/libpurple/protocols/jabber/si.c
--- a/libpurple/protocols/jabber/si.c
+++ b/libpurple/protocols/jabber/si.c
@@ -266,7 +266,16 @@ static void jabber_si_bytestreams_attemp
 
 	streamhost = jsx->streamhosts->data;
 
-	jsx->connect_data = NULL;
+	if (jsx->connect_data) {
+		purple_debug_info("jabber",
+				"jabber_si_bytestreams_attempt_connect: "
+				"cancelling existing connection attempt and restarting\n");
+		purple_proxy_connect_cancel(jsx->connect_data);
+		jsx->connect_data = NULL;
+		if (jsx->connect_timeout > 0)
+			purple_timeout_remove(jsx->connect_timeout);
+		jsx->connect_timeout = 0;
+	}
 	if (jsx->gpi != NULL)
 		purple_proxy_info_destroy(jsx->gpi);
 	jsx->gpi = NULL;