In response to [gemu-gtk-clipboard freezing and crashing guests](https://gitlab.com/qemu-project/qemu/-/issues/1150).
I think I might have a solution for the gtk clipboard sometimes crashing guests.
@kolAflash
I couldn't have done it without you, figuring out
`gtk_clipboard_wait_is_text_available(clipboard)` was the issue is half
the work.
The real issue is that
it's blocking and I'd wager that's a big no-no since qemu & KVM have
to run the VM + OS, preferably as real-time as possible. Something
times out and you get a core dump.
So as a replacement, `gtk_clipboard_request_text`, which is async and non-blocking is a better choice, hopefully.
It requires an additional function to handle receiving text.
From 530db8b6c7adc99f540d7d8cc6122320868326e6 Mon Sep 17 00:00:00 2001
Date: Sun, 24 Sep 2023 09:46:27 +0200
Subject: [PATCH 1/1] qemu-ui-gtk clipboard possible fix for crashes
---
ui/gtk-clipboard.c | 20 ++++++++++++++------
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/ui/gtk-clipboard.c b/ui/gtk-clipboard.c
index 8d8a636fd1..64d4f7ac9d 100644
--- a/ui/gtk-clipboard.c
+++ b/ui/gtk-clipboard.c
@@ -153,6 +153,18 @@ static void gd_clipboard_request(QemuClipboardInfo *info,
}
}
+/* non-blocking clipboard receiver implementation */
+static void gd_clipboard_text_received_callback(GtkClipboard *clipboard, const gchar *text, gpointer data)
+{
+ QemuClipboardInfo *info = (QemuClipboardInfo *)data;
+ if (text) {
+ info->types[QEMU_CLIPBOARD_TYPE_TEXT].available = true;
+ }
+
+ qemu_clipboard_update(info);
+ qemu_clipboard_info_unref(info);
+}
+
static void gd_owner_change(GtkClipboard *clipboard,
GdkEvent *event,
gpointer data)
@@ -170,12 +182,8 @@ static void gd_owner_change(GtkClipboard *clipboard,
switch (event->owner_change.reason) {
case GDK_OWNER_CHANGE_NEW_OWNER:
info = qemu_clipboard_info_new(&gd->cbpeer, s);
- if (gtk_clipboard_wait_is_text_available(clipboard)) {
- info->types[QEMU_CLIPBOARD_TYPE_TEXT].available = true;
- }
-
- qemu_clipboard_update(info);
- qemu_clipboard_info_unref(info);
+ /* gtk_clipboard_wait_is_text_available (blocking) was used here previously and crashed guests */
+ gtk_clipboard_request_text(clipboard, gd_clipboard_text_received_callback, info);
break;
default:
qemu_clipboard_peer_release(&gd->cbpeer, s);
--
2.42.0
don't forget to configure with --enable-gtk-clipboard before building
I'd say my gvt-g win10 VM has become a lot more responsive (was using gtk-clipboard besides being broken).
Paste from the VM is a bit delayed sometimes but I can live with that.
So far my VM hasn't crashed yet.
I'd like to ask you for help in evaluating my patch.
The issue linked to in the first line has instructions on the crash case.
It's my first time on the mailing list, I hope I've done this right.
Mr. Lureau CCed here had this to add:
Blocking the signal handler isn't great either, as we may miss
clipboard updates.
I think we could "reuse" the serial field on info and check in the
callback if we don't have the latest, just ignore the result and free.