summaryrefslogtreecommitdiffstats
path: root/classification_output/01/instruction/7733130
diff options
context:
space:
mode:
authorChristian Krinitsin <mail@krinitsin.com>2025-06-01 14:53:08 +0200
committerChristian Krinitsin <mail@krinitsin.com>2025-06-01 14:53:08 +0200
commit0d401089e9e72a8d9fb9b41d920126aa9fb23b05 (patch)
treee9ccc55b62498cf41023895880be55252227dc5b /classification_output/01/instruction/7733130
parent6d37f43e58f3ab6595d8769f3c5204ee164eafef (diff)
downloademulator-bug-study-0d401089e9e72a8d9fb9b41d920126aa9fb23b05.tar.gz
emulator-bug-study-0d401089e9e72a8d9fb9b41d920126aa9fb23b05.zip
first classification of mail-threads
Diffstat (limited to 'classification_output/01/instruction/7733130')
-rw-r--r--classification_output/01/instruction/773313047
1 files changed, 47 insertions, 0 deletions
diff --git a/classification_output/01/instruction/7733130 b/classification_output/01/instruction/7733130
new file mode 100644
index 00000000..1c3bc483
--- /dev/null
+++ b/classification_output/01/instruction/7733130
@@ -0,0 +1,47 @@
+instruction: 0.758
+semantic: 0.694
+other: 0.687
+mistranslation: 0.516
+
+[Qemu-devel] [BUG] VNC: client won't send FramebufferUpdateRequest if job in flight is aborted
+
+Hi Gerd, Daniel.
+
+We noticed that if VncSharePolicy was configured with
+VNC_SHARE_POLICY_FORCE_SHARED mode and
+multiple vnc clients opened vnc connections, some clients could go blank screen
+at high probability.
+This problem can be reproduced when we regularly reboot suse12sp3 in graphic
+mode both
+with RealVNC and noVNC client.
+
+Then we dig into it and find out that some clients go blank screen because they
+don't
+send FramebufferUpdateRequest any more. One step further, we notice that each
+time
+the job in flight is aborted one client go blank screen.
+
+The bug is triggered in the following procedure.
+Guest reboot => graphic mode switch => graphic_hw_update => vga_update_display
+=> vga_draw_graphic (full_update = 1) => dpy_gfx_replace_surface =>
+vnc_dpy_switch =>
+vnc_abort_display_jobs (client may have job in flight) => job removed from the
+queue
+If one client has vnc job in flight, *vnc_abort_display_jobs* will wait until
+its job is abandoned.
+This behavior is done in vnc_worker_thread_loop when 'if (job->vs->ioc == NULL
+|| job->vs->abort == true)'
+branch is taken.
+
+As we can see, *vnc_abort_display_jobs* is intended to do some optimization to
+avoid unnecessary client update.
+But if client sends FramebufferUpdateRequest for some graphic area and its
+FramebufferUpdate response job
+is abandoned, the client may wait for the response and never send new
+FramebufferUpdateRequest, which may
+case the client go blank screen forever.
+
+So I am wondering whether we should drop the *vnc_abort_display_jobs*
+optimization or do some trick here
+to push the client to send new FramebufferUpdateRequest. Do you have any idea ?
+