setting DRAW_ALL define doesn't produce correct rendering. Using
update_area instead of red_draw_qxl_drawable will work but it shouldn't
be required. This is not work I intend to do right now, so marking it
for anyone looking at this in the future.
150 seconds is way too long period for holding the guest driver and
waiting for a response for the client. This timeout was 15 seconds, but
when off-screen surfaces ware introduced it was arbitrarily multiplied by
10.
Other existing related bugs emphasize why it is important to decrease
the timeout:
(1) 994211 - the qxl driver waits for an async-io reponse for 60 seconds
and after that, it switches to sync-io mode. Not only that the
driver might use invalid data (since it didn't wait for the query to
complete), falling back to sync-io mode introduces other errors.
(2) 994175 - spice server sometimes doesn't recognize that the client
has disconnected.
(3) There might be cache inconsistency between the client and the server,
and then the display channel waits indefinitely for a cache item (e.g., bug
977998)
This patch changes the timeout to 30 seconds. I tested it under wifi +emulating 2.5Mbps network,
together with playing video on the guest and changing resolutions in a loop. The timeout didn't expired
during my tests.
This bug is related to rhbz#964136 (but from rhbz#964136 info it is still not
clear why the client wasn't responsive).
The snd channels has one reference as long as their socket is active.
The playback channel has an additional reference for each frame that is
currently filled by the sound device.
Once the channel is disconnected (the socket has been freed and the
first reference is released) snd_disconnect_channel shouldn't release
a reference again.
When the sequence of calls bellow occurs, the PlaybackChannel
is not released (snd_channel_put is not called for the
samples that refer to the channel).
spice_server_playback_get_buffer
snd_channel_disconnect
spice_server_playback_put_samples
When we want to disconnect the main channel from a callback, it is
safer to use red_channel_client_shutdown, instead of directly
destroying the client. It is also more consistent with how other
channels treat errors.
red_channel_client_shutdown will trigger socket error in the main channel.
Then, main_channel_client_on_disconnect will be called,
and eventually, main_dispatcher_client_disconnect.
I didn't replace calls to reds_disconnect/reds_client_disconnect in
places where those calls were safe && that might need immediate client
disconnection.
Fixes rhbz#918169
Some channels make direct calls to reds/main_channel routines. If
these routines try to read/write to the socket, and they get socket
error, main_channel_client_on_disconnect is called, and triggers
red_client_destroy. In order to prevent accessing expired references
to RedClient, RedChannelClient, or other objects (inside the original call, after
red_client_destroy has been called) I made the call to
red_client_destroy asynchronous with respect to main_channel_client_on_disconnect.
I added MAIN_DISPATCHER_CLIENT_DISCONNECT to main_dispatcher.
main_channel_client_on_disconnect pushes this msg to the dispatcher,
instead of calling directly to reds_client_disconnect.
The patch uses RedClient ref-count in order to handle a case where
reds_client_disconnect is called directly (e.g., when a new client connects while
another one is connected), while there is already CLIENT_DISCONNECT msg
pending in the main_dispatcher.
Examples:
(1) snd_worker.c
snd_disconnect_channel()
channel->cleanup() //snd_playback_cleanup
reds_enable_mm_timer()
.
.
main_channel_push_multi_media_time()...socket_error
.
.
red_client_destory()
.
.
snd_disconnect_channel()
channel->cleanup()
celt051_encoder_destroy()
celt051_encoder_destory() // double release
Note that this bug could have been solved by changing the order of
calls: e.g., channel->stream = NULL before calling cleanup, and
some other changes + reference counting. However, I found other
places in the code with similar problems, and I looked for a general
solution, at least till we redesign red_channel to handle reference
counting more consistently.
(2) inputs_channel.c
inputs_connect()
main_channel_client_push_notify()...socket_error
.
.
red_client_destory()
.
.
red_channel_client_create() // refers to client which is already destroyed
(3) reds.c
reds_handle_main_link()
main_channel_push_init() ...socket error
.
.
red_client_destory()
.
.
main_channel_client_start_net_test(mcc) // refers to mcc which is already destroyed
This can explain the assert in rhbz#964136, comment #1 (but not the hang that occurred before).
Fixes: leaks of pipe items & "red_client_destroy: assertion `rcc->send_data.size == 0'"
red_channel_disconnect clears the pipe. It is called only once. After,
it was called, not items should be added to the pipe.
An example of when this assert can occur:
on_new_cursor_channel (red_worker.c), pushes 2 pipe items.
When it pushes the first pipe item, if the client has disconnected,
it can hit a socket error, and then, red_channel_client_disconnect is called.
The second call to adding a pipe item, will add the item to
the pipe. red_channel_client_pipe_add_type also calls
red_channel_client_push, which will update the send_data.size.
Then, the push will also hit a socket error, but red_channel_client_disconnect
won't clear the pending pipe item again, since it was already called.
When red_client_destory is called, we hit assertion `rcc->send_data.size
== 0'.
Note that if a pipe item is added to the pipe after
red_channel_client_disconnect was called, but without pushing it,
we should hit "spice_assert(rcc->pipe_size == 0)".
The ioctl on sockets is actually named SIOCOUTQ though its value
is identical to TIOCOUTQ which is for terminals.
SIOCOUTQ is linux specific so we add a header check and ifdef based
on the presence of the header
This prevents bogus ioctls on non-Linux platforms
In this case, make syntax-check is wrong, and we actually do
need the cast.
A cast is needed when types are uint64_t <--> pointer
Using a local "ptr" variable makes both gcc and syntax-check happy.
Earlier in this function, test->target_surface is set to 1, which
is the only allowed non-primary surface currently.
If surface parameters are given (and specifically data is checked)
they are being used, otherwise a default surface is used.
Earlier in this function, "command" is set to a non-NULL value.
Thus, the else part was unreachable code, which is fixed now.
When surface_id == 0, primary is used.
Otherwise (currently 1), secondary is used.
Also, remove unused test_width and test_height.
Since commit caea769943,
test->width and test->height are used.
This was originally intended to fix the problem fixed by
commit 53488f0275.
What is left are FOREACH loops that are at less risk and maybe safe (no
read/write or disconnect/destroy are called from within them).
Specifically, the loop in red_pipes_add_draw can cause spice to abort.
In red_worker.c (WORKER_FOREACH_DCC):
red_pipes_add_drawable
red_pipe_add_drawable
red_handle_drawable_surfaces_client_synced
red_push_surface_image
red_channel_client_push
red_channel_client_send
red_peer_handle_outgoing
reds_stream_writev (if fails -- EPIPE)
handler->cb->on_error = red_channel_client_disconnect()
red_channel_remove_client()
ring_remove() -- of rcc from channel.clients ring.
RCC_FOREACH may be dangerous
The following patches replace FOREACH loops with a SAFE version.
Using unsafe loops may cause spice-server to abort (assert fails).
Specifically a read/write fail in those loops, may cause the client
to disconnect, removing the node currently iterated, which cause spice
to abort in ring_next():
-- assertion `pos->next != NULL && pos->prev != NULL' failed
Currently, both red_channel_pipes_add_type() and
red_channel_pipes_add_empty_msg() use plaing RING_FOREACH() which is not
safe versus removals from the ring within the loop body.
Although it's rare, such a removal can occur in both cases. In the case
of red_channel_pipes_add_type() we have:
red_channel_pipes_add_type()
-> red_channel_client_pipe_add_type()
-> red_channel_client_push()
And in the case of red_channel_client_pipes_add_empty_msg() we have:
red_channel_client_pipes_add_empty_msg()
-> red_channel_client_pipe_add_empty_msg()
-> red_channel_client_push()
But red_channel_client_push() can cause a removal from the clients ring if
a network error occurs:
red_channel_client_push()
-> red_channel_client_send()
-> red_peer_handle_outgoing()
-> handler->cb->on_error callback
= red_channel_client_default_peer_on_error()
-> red_channel_client_disconnect()
-> red_channel_remove_client()
-> ring_remove()
When this error path does occur, the assertion in RING_FOREACH()'s
ring_next() trips, and the process containing the spice server is aborted.
i.e. your whole VM dies, as a result of an unfortunately timed network
error on the spice channel.
Please apply.
Signed-off-by: David Gibson <dgibson@redhat.com>
The image descriptor flags shouldn't be copied as is from the flags that
were set by the driver. Specifically, the CACHE_ME flag shouldn't be copied,
since it is possible that (a) the image won't be cached (b) the image
is already cached, but in its lossy version, and we may want to set the bit for
CACHE_REPLACE_ME, in order to cache it in its lossless version.
In case (b), the client first looks for the CACHE_ME flag, and only if
it is not set it looks for CACHE_REPLACE_ME (see canvas_base.c). Since both flags where set,
the client ignored REPLACE_ME, and didn't turned off the lossy flag of the
cach item. Then, when a request from this lossles item reached the
client (FROM_CACHE_LOSSLESS), the client display channel waited
endlessly for the lossless version of the image.
The assert:
spice_assert(pthread_equal(pthread_self(), client->thread_id))
and the assert:
spice_assert(pthread_equal(pthread_self(), rcc->channel->thread_id))
were coded in order to protect data that is accessed from the main
context (red_client and most of the channels), from
access by threads of other channels (namely, the display and cursor
channels), and vice versa.
However, some of the calls to the sound channel interface,
and also the char_device interface, can be done from the vcpu thread.
It doesn't endanger these channels internal data, since qemu use global
mutex for the vcpu and io threads.
Thus, pthread_self() can be != channel->thread_id, if one of them is
the vcpu thread and the other is the io-thread, and we shouldn't assert.
Future plans: A more complete and complicated solution would be to manage our own thread for
spice-channels, and push input from qemu to this thread, instead of
counting on the global mutex of qemu
rhbz#823472
If client_migrate_info was called once with cert-host-subject and
then again without cert-host-subject, on a third call to
client_migrate info, the cert-host-subject from the first call would
have been freed for the second time.
It's not always obvious what address spice-server will bind to,
in particular when the 'addr' parameter is omitted on QEMU
commandline. The decision of what address to bind to is made
in reds_init_socket with a call to getaddrinfo. Surprisingly,
that function had a call to getnameinfo() already, but it does
not seem to be using the result of that call in any way.
This commit moves this call after the socket is successfully bound
and add a log message to indicate which address it's bound to.
