changeset
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
Thu, 17 May 2007 14:29:17 +0000
- author
- Evan Schoenberg <evands@pidgin.im>
- date
- Thu, 17 May 2007 14:29:17 +0000
- changeset 17133
- 20a4a4077bba
- parent 17116
- 122d4dcce40e
- child 17134
- d01f076758af
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
--- 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;
