[Bug 43977] red_channel_remove_client: ASSERT pthread_equal(pthread_self(), rcc->channel->thread_id) failed
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Wed Dec 21 00:19:01 PST 2011
https://bugs.freedesktop.org/show_bug.cgi?id=43977
--- Comment #3 from Yonit Halperin <yhalperi at redhat.com> 2011-12-21 00:19:01 PST ---
(In reply to comment #0)
> Hi,
>
> I hit this when I reconnected after my client machine's kernel crashed (so no
> disconnect tcp packets from client to server). spice-server did the disconnect
> thingie for the currently attached client (as it was not configured for multi
> client), and when it did that I hit this, here is some debug output generated
> before the assert:
>
> reds_handle_auth_mechanism: Auth method: 1
> reds_handle_main_link:
> reds_disconnect:
> reds_client_disconnect:
> red_client_destroy: destroy client with #channels 5
> red_channel_client_disconnect: 0x555556a6cac0 (channel 0x5555569edc90 type 9 id
> 2)
> red_channel_client_disconnect: 0x555556a6c350 (channel 0x555556521b40 type 3 id
> 0)
> red_channel_client_disconnect: 0x7fff98620e90 (channel 0x7fff9846d4d0 type 2 id
> 0)
> red_channel_remove_client: ASSERT pthread_equal(pthread_self(),
> rcc->channel->thread_id) failed
>
> Regards,
>
> Hans
I assume that the client that was connected before the 2 clients discussed
above, was disconnected with "update timeout" in flush_display_commands. Then
red_disconnect_all_display_TODO_remove_me (!!!) was called. It sets
worker->display_channel = NULL (it shouldn't do it).
Then, when the next client was connected, ensure_display_channel_created was
called and created a new channel (we shouldn't do this as well, the display
channel is always alive) with the default disconnect callback, instead of the
dispatcher's one.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the spice-bugs
mailing list