Gerd Hoffmann writes:
> On Wed, Sep 21, 2022 at 11:55:01AM +0200, Claudio Fontana wrote:
>> Hi,
>>
>> I think this bug report warrants some attention,
>>
>> can Gerd take a look here?
>>
>> The GTK Clipboard commit seems involved:
>>
>> https://gitlab.com/qemu-project/qemu/-/issues/1150
>
> Had a very quick look. Seems gtk_clipboard_wait_is_text_available()
> blocks forever for some reason. Not sure why. Possibly a gtk bug.
>
> The options I see are:
> (a) go debug why it hangs.
> (b) rewrite clipboard support to avoid using the
> gtk_clipboard_wait*() functions.
> (c) add a config option to turn off gtk clipboard support.
>
> Don't have the time to dig deeper right now, sorry.
Hi Gerd,
I spent some time looking at this, perhaps it could be of help:
I'm using this reproducer:
1) Run a graphical guest with:
-display gtk -net user,hostfwd=tcp:127.0.0.1:50022-:22 -net nic
2) From the host, connect via ssh:
ssh -X -p 50022 @127.0.0.1
3) Run xclip via ssh:
echo "foo" | xclip -selection c -i
The QEMU process, the ssh client and anything that tries to access the
clipboard on the host will hang for 30s.
It seems that QEMU is waiting for the clipboard owner to respond to a
selection request:
#0 _gdk_x11_display_convert_selection (display=0x55e490da5010,
requestor=0x55e491917c30, selection=0x1, target=0x92, time=457372390) at
gdkselection-x11.c:189
#1 0x7f482bcc1dbb in gtk_selection_convert (widget=0x55e490de84b0,
selection=0x1, target=0x92, time_=457372390) at gtkselection.c:1210
#2 0x7f482bda3848 in gtk_clipboard_wait_for_contents
(clipboard=clipboard@entry=0x55e49100f480, target=0x92) at gtkclipboard.c:1429
#3 0x7f482bda3dff in gtk_clipboard_wait_is_text_available
(clipboard=0x55e49100f480) at gtkclipboard.c:1720
#4 0x55e48f003bde in gd_owner_change (clipboard=0x55e49100f480,
event=0x55e49105f970, data=0x55e490fc4200) at ../ui/gtk-clipboard.c:173
#5 0x7f482d52c973 in g_closure_invoke () at /usr/lib64/libgobject-2.0.so.0
#6 0x7f482d540a7e in () at /usr/lib64/libgobject-2.0.so.0
#7 0x7f482d54a684 in g_signal_emit_valist () at
/usr/lib64/libgobject-2.0.so.0
#8 0x7f482d54b11f in g_signal_emit () at /usr/lib64/libgobject-2.0.so.0
#9 0x7f482bda423c in _gtk_clipboard_handle_event (event=)
at gtkclipboard.c:2031
#10 0x7f482bc3b8fd in gtk_main_do_event (event=0x55e49105f970) at
gtkmain.c:1709
#11 0x7f482b72b195 in _gdk_event_emit (event=event@entry=0x55e49105f970) at
gdkevents.c:73
#12 0x7f482b75d482 in gdk_event_source_dispatch (source=,
callback=, user_data=) at gdkeventsource.c:367
#13 0x7f482d23a7fb in g_main_context_dispatch () at
/usr/lib64/libglib-2.0.so.0
#14 0x55e48f4917e1 in glib_pollfds_poll () at ../util/main-loop.c:297
#15 0x55e48f49185b in os_host_main_loop_wait (timeout=15269231) at
../util/main-loop.c:320
#16 0x55e48f491960 in main_loop_wait (nonblocking=0) at
../util/main-loop.c:606
#17 0x55e48ef75f09 in qemu_main_loop () at ../softmmu/runstate.c:739
#18 0x55e48ecf2d57 in qemu_default_main () at ../softmmu/main.c:37
#19 0x55e48ecf2d8d in main (argc=19, argv=0x7ffc10c184c8) at
../softmmu/main.c:48
The last thing the X11 server sends is:
113.10: Client 1 --> 24 bytes
REQUEST: ConvertSelection
requestor: WIN 03c00b9b <--- qemu window
selection:
target: ATM 0201
property: ATM 0185
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.
Thanks!
>
> take care,
> Gerd
