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