Re: guest Linux Kernel hangs and reports CPU lockup/stuck gitlab bug

[Gerd Hoffmann]

> The last thing the X11 server sends is:
> 
> 113.10: Client 1 -->   24 bytes
>          ............REQUEST: ConvertSelection
>                    requestor: WIN 03c00b9b      <--- qemu window
>                    selection: <CLIPBOARD>
>                       target: ATM 00000201
>                     property: ATM 00000185
>                         time: TIM 1b3500de
> 
> However, the clipboard owner is an entity inside the guest (due to
> ssh -X) and it can never reply because the guest is paused.
> 
> So the GTK waits until IDLE_ABORT_TIME, i.e. 30 iterations of
> gtk_selection_retrieval_timeout (1000 ms).
> 
> I'm not familiar with the gtk code, but I understand from the
> documentation that we would want to use gtk_clipboard_request_contents,
> which allows for a callback when the text is actually available (i.e.,
> the clipboard owner has eventually replied).
> 
> Naively, I'm thinking we could replace gd_clipboard_request with
> gtk_clipboard_request_contents and pass qemu_clipboard_set_data as the
> callback. But I haven't experimented with it. Let me know if any of this
> makes sense and I could give it a shot.

That goes into the right direction.  Replace the blocking calls with
callback versions.  It probably wouldn't be *that* simple though.  I
think you need additional state tracking so you can deal with corner
cases like clipboard changes happening between
gtk_clipboard_request_contents() call and the callback being called.

take care,
  Gerd