changeset 31395:a76cf8ecb0c5

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.
author Mark Doliner <mark@kingant.net>
date Mon, 22 Nov 2010 09:16:49 +0000
parents 5eb2ea662d8c
children 6f9a43a2b716
files libpurple/ft.c
diffstat 1 files changed, 14 insertions(+), 0 deletions(-) [+]
line wrap: on
line diff
--- a/libpurple/ft.c	Mon Nov 22 07:43:56 2010 +0000
+++ b/libpurple/ft.c	Mon Nov 22 09:16:49 2010 +0000
@@ -1488,6 +1488,20 @@
 
 	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);