Mercurial > pidgin
changeset 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.
| 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);