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

[Hans de Goede]

Hi,

On 03/04/2013 04:59 PM, Christophe Fergeau wrote:
> 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.

The list typically has few elements, and there will be only one flush in
the list per task, so g_slist_remove will be called once (or not at all).

Regards,

Hans