comparison libpurple/protocols/msn/slpcall.c @ 17114:8ed7b2d32ad1

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

17113:0b7110b9e368

	msn_slplink_remove_slpcall(slpcall->slplink, slpcall);

	if (slpcall->end_cb != NULL)
		slpcall->end_cb(slpcall, session);

	g_free(slpcall);
}

void

17114:8ed7b2d32ad1

	msn_slplink_remove_slpcall(slpcall->slplink, slpcall);

	if (slpcall->end_cb != NULL)
		slpcall->end_cb(slpcall, session);

	if (slpcall->xfer != NULL)
		purple_xfer_unref(slpcall->xfer);

	g_free(slpcall);
}

void