<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 13, 2014 at 10:07 AM, Christophe Fergeau <span dir="ltr"><<a href="mailto:cfergeau@redhat.com" target="_blank">cfergeau@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id=":df6" class="" style="overflow:hidden">Ah, this is the bit I was missing thanks! The commit log needs to be<br>
much more detailed and accurate, and mention explicitly the various code<br>
paths involved to trigger the error, where the looping occurs, ...</div></blockquote></div><br>What about?<br><br>migration: set connecting state before fd request<br><br>During migration, the main channel initiating the process is waiting on<br>connection completion of all channels in migrate_channel_event_cb() or<br>it will abort migration for unexpected channel events, such as<br>SPICE_CHANNEL_CLOSED.<br><br>If the migration is cancelled before connection completes, but the<br>channels state are still SPICE_CHANNEL_STATE_UNCONNECTED, no events will<br>be emitted in channel_disconnect(), and the source session main channel<br>will remain frozen waiting for migration completion or failure.<br><br>Currently, for client-fd channels, the channel state remains UNCONNECTED<br>until the fd is provided. But if cancellation occurs, no channel events are<br>emitted and the source session is stuck.<br><br>Before requesting the fd, set the channel state to connecting, so it                                                                                                                                                              <br>will emit an error if disconnect happens, and it will finish cancelling<br>the migration in source session main channel.<br><br><br clear="all"><br>-- <br><div class="gmail_signature">Marc-André Lureau</div>
</div></div>