changeset 17135:acde78931954

slpcall now explicitlt references its xfer and unreferences it when it is destroyed. While it *looks* like this should *probably* have happened anyways due to the interactins between xfer_init, xfer_end, and xfer_cancel_remote, having the xfer's owner make this explicit makes the process less fragile and more obvious, and it may fix a crash as the slp is destroyed. Fixes #1070
author Evan Schoenberg <evan.s@dreskin.net>
date Thu, 17 May 2007 14:29:17 +0000
parents 10c7c5d4ea25
children 0b7110b9e368
files libpurple/protocols/msn/slp.c libpurple/protocols/msn/slpcall.c libpurple/protocols/msn/slplink.c
diffstat 3 files changed, 6 insertions(+), 0 deletions(-) [+]
line wrap: on
line diff
--- a/libpurple/protocols/msn/slp.c	Sun May 13 10:26:08 2007 +0000
+++ b/libpurple/protocols/msn/slp.c	Thu May 17 14:29:17 2007 +0000
@@ -363,6 +363,8 @@
 			purple_xfer_set_cancel_recv_fnc(xfer, msn_xfer_cancel);
 
 			slpcall->xfer = xfer;
+			purple_xfer_ref(slpcall->xfer);
+
 			xfer->data = slpcall;
 
 			purple_xfer_request(xfer);
--- a/libpurple/protocols/msn/slpcall.c	Sun May 13 10:26:08 2007 +0000
+++ b/libpurple/protocols/msn/slpcall.c	Thu May 17 14:29:17 2007 +0000
@@ -120,6 +120,9 @@
 	if (slpcall->end_cb != NULL)
 		slpcall->end_cb(slpcall, session);
 
+	if (slpcall->xfer != NULL)
+		purple_xfer_unref(slpcall->xfer);
+
 	g_free(slpcall);
 }
 
--- a/libpurple/protocols/msn/slplink.c	Sun May 13 10:26:08 2007 +0000
+++ b/libpurple/protocols/msn/slplink.c	Thu May 17 14:29:17 2007 +0000
@@ -763,6 +763,7 @@
 	slpcall->progress_cb = msn_xfer_progress_cb;
 	slpcall->cb = msn_xfer_completed_cb;
 	slpcall->xfer = xfer;
+	purple_xfer_ref(slpcall->xfer);
 
 	slpcall->pending = TRUE;