pidgin.2.7.7: 587b2bb9: Apply Mark's specific changes listed bel...

rekkanoryo at pidgin.im rekkanoryo at pidgin.im
Wed Nov 24 01:06:39 EST 2010


----------------------------------------------------------------------
Revision: 587b2bb9fe22fc4c15ba1c1ef8175be06025ea9d
Parent:   162d843fc380614e09a87fd411b7d3cddcad49d3
Author:   rekkanoryo at pidgin.im
Date:     11/23/10 23:28:07
Branch:   im.pidgin.pidgin.2.7.7
URL: http://d.pidgin.im/viewmtn/revision/info/587b2bb9fe22fc4c15ba1c1ef8175be06025ea9d

Changelog: 

Apply Mark's specific changes listed below to the 2.7.7 branch.

*** Plucked rev 05ca7c0f8c782c05e9866a9ac6ccc03acc7d2c7f (markdoliner at pidgin.im):
Close open requests related to this xfer when the request is canceled
locally.  For oscar this includes disconnecting when you have an
incoming transfer request.  Without this change Pidgin will crash if
the user tries to interact with the dialog.  This change fixes #11666.

Now instead of crashing we'll leak.  See the lengthy comment in the
code if anyone wants to fix this.

*** Plucked rev 089c261f1de00667abd623ce3c5b471e91b09016 (markdoliner at pidgin.im):
I noticed a NULL printf crash from the first chunk of this change.
In the second chunk I changed the code to match the error message from
the first chunk.  I prefer this message.

*** Plucked rev 6e8da78b6e5ccdafa85c8afebff37e426d9a58d3 (markdoliner at pidgin.im):
Move the call to flap_connection_schedule_destroy from oscar_chat_kill
to oscar_chat_leave.  This avoids having flap_connection_schedule_destroy
called from purple_connerr, which itself is called by flap_connection_destroy_cb
I'm hoping this change fixes #5927, the oscar crash when a flap connection
is disconnected.

Changes against parent 162d843fc380614e09a87fd411b7d3cddcad49d3

  patched  libpurple/ft.c
  patched  libpurple/protocols/oscar/clientlogin.c
  patched  libpurple/protocols/oscar/oscar.c

-------------- next part --------------
============================================================
--- libpurple/protocols/oscar/oscar.c	3815ff8cf1c62f3eaee5077a094ec10ceae80461
+++ libpurple/protocols/oscar/oscar.c	82395d2f22f147eb06810bb105108d79273f48ab
@@ -283,7 +283,6 @@ oscar_chat_kill(PurpleConnection *gc, st
 
 	/* Destroy the chat_connection */
 	od->oscar_chats = g_slist_remove(od->oscar_chats, cc);
-	flap_connection_schedule_destroy(cc->conn, OSCAR_DISCONNECT_DONE, NULL);
 	oscar_chat_destroy(cc);
 }
 
@@ -4451,6 +4450,7 @@ oscar_chat_leave(PurpleConnection *gc, i
 			purple_conversation_get_name(conv));
 
 	cc = find_oscar_chat(gc, purple_conv_chat_get_id(PURPLE_CONV_CHAT(conv)));
+	flap_connection_schedule_destroy(cc->conn, OSCAR_DISCONNECT_DONE, NULL);
 	oscar_chat_kill(gc, cc);
 }
 
============================================================
--- libpurple/ft.c	89aed01fc8502b575f70a455a6853d38403486ec
+++ libpurple/ft.c	25f2e7cdb8cac8635d2f2085f5c3216d9440613d
@@ -1488,6 +1488,20 @@ purple_xfer_cancel_local(PurpleXfer *xfe
 
 	g_return_if_fail(xfer != NULL);
 
+	/* TODO: We definitely want to close any open request dialogs associated
+	   with this transfer.  However, in some cases the request dialog might
+	   own a reference on the xfer.  This happens at least with the "%s wants
+	   to send you %s" dialog from purple_xfer_ask_recv().  In these cases
+	   the ref count will not be decremented when the request dialog is
+	   closed, so the ref count will never reach 0 and the xfer will never
+	   be freed.  This is a memleak and should be fixed.  It's not clear what
+	   the correct fix is.  Probably requests should have a destroy function
+	   that is called when the request is destroyed.  But also, ref counting
+	   xfer objects makes this code REALLY complicated.  An alternate fix is
+	   to not ref count and instead just make sure the object still exists
+	   when we try to use it. */
+	purple_request_close_with_handle(xfer);
+
 	purple_xfer_set_status(xfer, PURPLE_XFER_STATUS_CANCEL_LOCAL);
 	xfer->end_time = time(NULL);
 
============================================================
--- libpurple/protocols/oscar/clientlogin.c	94c6dd09616a8e8796556e7f66919851c6ba886b
+++ libpurple/protocols/oscar/clientlogin.c	30188d491ff7cf374cab732632f12a63b2ef4c5d
@@ -335,7 +335,8 @@ static void start_oscar_session_cb(Purpl
 		/* Note to translators: The first %s is a URL, the second is an
 		   error message. */
 		tmp = g_strdup_printf(_("Error requesting %s: %s"),
-				get_start_oscar_session_url(od), error_message);
+				get_start_oscar_session_url(od), error_message ?
+				error_message : _("The server returned an empty response"));
 		purple_connection_error_reason(gc,
 				PURPLE_CONNECTION_ERROR_NETWORK_ERROR, tmp);
 		g_free(tmp);
@@ -568,12 +569,9 @@ static void client_login_cb(PurpleUtilFe
 
 	if (error_message != NULL || len == 0) {
 		gchar *tmp;
-		if (error_message != NULL)
-			tmp = g_strdup_printf(_("Error requesting %s: %s"),
-					get_client_login_url(od), error_message);
-		else
-			tmp = g_strdup_printf(_("Error requesting %s"),
-					get_client_login_url(od));
+		tmp = g_strdup_printf(_("Error requesting %s: %s"),
+				get_client_login_url(od), error_message ?
+				error_message : _("The server returned an empty response"));
 		purple_connection_error_reason(gc,
 				PURPLE_CONNECTION_ERROR_NETWORK_ERROR, tmp);
 		g_free(tmp);


More information about the Commits mailing list