[Spice-devel] [PATCH spice-gtk 1/4] channel-main: Fix dangling references to freed file-xfer-tasks on agent cancel

[Christophe Fergeau]

On Sun, Mar 03, 2013 at 05:52:02PM +0100, Hans de Goede wrote:
> While testing the agent error handling code I was triggering the
> agent-file-xfer-cancel code-path in sice-gtk. This crashes due to the

spice-gtk typo

> flushing queue still having a reference to the task in question when its
> gets cancelled from the agent side. This fixes this.
> 
> Signed-off-by: Hans de Goede <hdegoede at redhat.com>
> ---
>  gtk/channel-main.c | 17 +++++++++++++++++
>  spice-common       |  2 +-
>  2 files changed, 18 insertions(+), 1 deletion(-)
> 
> diff --git a/gtk/channel-main.c b/gtk/channel-main.c
> index 40d27cc..531b1e8 100644
> --- a/gtk/channel-main.c
> +++ b/gtk/channel-main.c
> @@ -1516,17 +1516,31 @@ static void file_xfer_task_free(SpiceFileXferTask *task)
>  }
>  
>  /* main context */
> +static void file_xfer_remove_flush(gpointer data, gpointer user_data)
> +{
> +    GAsyncResult *res = G_ASYNC_RESULT(data);
> +    SpiceFileXferTask *task = user_data;
> +    SpiceMainChannelPrivate *c = task->channel->priv;
> +
> +    if (g_async_result_get_user_data(res) == task) {
> +        c->flushing = g_slist_remove(c->flushing, res);

I don't know how many elements are typically in this loop, but calling
g_slist_remove from a g_list_foreach callback will give you quadratic
behaviour. Doing the iteration by hand could probably help avoiding this,
but if this list typically has few elements, it's probably not worth the
trouble.

Looks good otherwise,

Christophe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/spice-devel/attachments/20130304/3b2ca3a3/attachment.pgp>