comparison libpurple/ft.c @ 30954: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.

30953:5eb2ea662d8c

{
	PurpleXferUiOps *ui_ops;
	char *msg = NULL;

	g_return_if_fail(xfer != NULL);

	purple_xfer_set_status(xfer, PURPLE_XFER_STATUS_CANCEL_LOCAL);
	xfer->end_time = time(NULL);

	if (purple_xfer_get_filename(xfer) != NULL)

30954:a76cf8ecb0c5

{
	PurpleXferUiOps *ui_ops;
	char *msg = NULL;

	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);

	if (purple_xfer_get_filename(xfer) != NULL)