[Spice-devel] [PATCH 2/5] channel: do not free rcc->stream in red_channel_client_disconnect

Frediano Ziglio fziglio at redhat.com
Fri Oct 16 04:23:07 PDT 2015


> 
> From: Marc-André Lureau <marcandre.lureau at gmail.com>
> 
> This fixes the following scary racy corruption after glib loop switch:
> 
> ==28173==
> ==28173== Debugger has detached.  Valgrind regains control.  We
> continue.
> ==28173== Invalid read of size 8
> ==28173==    at 0x4C7871E: reds_stream_read (reds.c:4521)
> ==28173==    by 0x4C2F9D7: red_peer_receive (red_channel.c:209)
> ==28173==    by 0x4C2FB59: red_peer_handle_incoming (red_channel.c:255)
> ==28173==    by 0x4C2FF36:
> red_channel_client_receive (red_channel.c:329)
> ==28173==    by 0x4C33D6D: red_channel_client_event (red_channel.c:1577)
> ==28173==    by 0x4C65098: watch_func (red_worker.c:10292)
> ==28173==    by 0x504DDAB: g_io_unix_dispatch (giounix.c:167)
> ==28173==    by 0x4FFACB6: g_main_dispatch (gmain.c:3065)
> ==28173==    by 0x4FFBA0D: g_main_context_dispatch (gmain.c:3641)
> ==28173==    by 0x4FFBBFF: g_main_context_iterate (gmain.c:3712)
> ==28173==    by 0x4FFC028: g_main_loop_run (gmain.c:3906)
> ==28173==    by 0x4C6ABF2: red_worker_main (red_worker.c:12180)
> ==28173==  Address 0x7d688e0 is 32 bytes inside a block of size 160
> free'd
> ==28173==    at 0x4A074C4: free (in
> /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==28173==    by 0x4C78A84: reds_stream_free (reds.c:4594)
> ==28173==    by 0x4C34E2E:
> red_channel_client_disconnect (red_channel.c:1865)
> ==28173==    by 0x4C30363:
> red_channel_client_default_peer_on_error (red_channel.c:417)
> ==28173==    by 0x4C3011B: red_peer_handle_outgoing (red_channel.c:372)
> ==28173==    by 0x4C3305F: red_channel_client_send (red_channel.c:1298)
> ==28173==    by 0x4C33FB6:
> red_channel_client_begin_send_message (red_channel.c:1616)
> ==28173==    by 0x4C5F4B4:
> display_begin_send_message (red_worker.c:8360)
> ==28173==    by 0x4C61DE8: display_channel_send_item (red_worker.c:9164)
> ==28173==    by 0x4C30C69:
> red_channel_client_send_item (red_channel.c:599)
> ==28173==    by 0x4C332BB: red_channel_client_push (red_channel.c:1351)
> ==28173==    by 0x4C33C3A:
> red_channel_client_handle_message (red_channel.c:1545)
> ---
>  server/red_channel.c | 39 +++++++++++++++++++++------------------
>  server/red_worker.c  |  2 ++
>  2 files changed, 23 insertions(+), 18 deletions(-)
> 
> diff --git a/server/red_channel.c b/server/red_channel.c
> index 8db3d6e..4d5066a 100644
> --- a/server/red_channel.c
> +++ b/server/red_channel.c
> @@ -1233,22 +1233,25 @@ static void red_channel_client_ref(RedChannelClient
> *rcc)
>  
>  static void red_channel_client_unref(RedChannelClient *rcc)
>  {
> -    if (!--rcc->refs) {
> -        spice_debug("destroy rcc=%p", rcc);
> -        if (rcc->send_data.main.marshaller) {
> -            spice_marshaller_destroy(rcc->send_data.main.marshaller);
> -        }
> +    spice_debug("rcc=%p", rcc);
>  
> -        if (rcc->send_data.urgent.marshaller) {
> -            spice_marshaller_destroy(rcc->send_data.urgent.marshaller);
> -        }
> +    if (--rcc->refs)
> +        return;
>  
> -        red_channel_client_destroy_remote_caps(rcc);
> -        if (rcc->channel) {
> -            red_channel_unref(rcc->channel);
> -        }
> -        free(rcc);
> -    }
> +    reds_stream_free(rcc->stream);
> +    rcc->stream = NULL;
> +
> +    if (rcc->send_data.main.marshaller)
> +        spice_marshaller_destroy(rcc->send_data.main.marshaller);
> +
> +    if (rcc->send_data.urgent.marshaller)
> +        spice_marshaller_destroy(rcc->send_data.urgent.marshaller);
> +
> +    red_channel_client_destroy_remote_caps(rcc);
> +    if (rcc->channel)
> +        red_channel_unref(rcc->channel);
> +
> +    free(rcc);
>  }
>  

This part looks quite a big change but mainly is style one.
However the debug string is printed at every reference change and not only
when really released.
I would rollback all these style changes.

>  void red_channel_client_destroy(RedChannelClient *rcc)
> @@ -1758,7 +1761,7 @@ void red_channel_pipes_add_empty_msg(RedChannel
> *channel, int msg_type)
>  int red_channel_client_is_connected(RedChannelClient *rcc)
>  {
>      if (!rcc->dummy) {
> -        return rcc->stream != NULL;
> +        return (rcc->stream != NULL) &&
> ring_item_is_linked(&rcc->channel_link);
>      } else {
>          return rcc->dummy_connected;
>      }
> @@ -1813,8 +1816,10 @@ static void red_channel_remove_client(RedChannelClient
> *rcc)
>                        rcc->channel->type, rcc->channel->id,
>                        rcc->channel->thread_id, pthread_self());
>      }
> +    spice_return_if_fail(ring_item_is_linked(&rcc->channel_link));
> +
>      ring_remove(&rcc->channel_link);
> -    spice_assert(rcc->channel->clients_num > 0);
> +    spice_return_if_fail(rcc->channel->clients_num > 0);

I think this WAS detecting an invalid internal state and the check was basically
made silent. Any reason?

>      rcc->channel->clients_num--;
>      // TODO: should we set rcc->channel to NULL???
>  }
> @@ -1854,8 +1859,6 @@ void red_channel_client_disconnect(RedChannelClient
> *rcc)
>          rcc->channel->core->watch_remove(rcc->stream->watch);
>          rcc->stream->watch = NULL;
>      }
> -    reds_stream_free(rcc->stream);
> -    rcc->stream = NULL;
>      if (rcc->latency_monitor.timer) {
>          rcc->channel->core->timer_remove(rcc->latency_monitor.timer);
>          rcc->latency_monitor.timer = NULL;
> diff --git a/server/red_worker.c b/server/red_worker.c
> index 6cc5a35..742edfc 100644
> --- a/server/red_worker.c
> +++ b/server/red_worker.c
> @@ -10135,6 +10135,8 @@ static gboolean watch_func(GIOChannel *source,
> GIOCondition condition,
>      SpiceWatch *watch = data;
>      int fd = g_io_channel_unix_get_fd(source);
>  
> +    spice_return_val_if_fail(!g_source_is_destroyed(watch->source), FALSE);
> +

Should glib call this function if the object is destroyed?

>      watch->func(fd, giocondition_to_spice_event(condition), watch->rcc);
>  
>      return TRUE;

Do we have a repro of this bug?

Frediano


More information about the Spice-devel mailing list