1 files changed, 57 insertions, 0 deletions
diff --git a/results/classifier/008/vnc/11357571 b/results/classifier/008/vnc/11357571
new file mode 100644
index 000000000..a01adc18f
--- /dev/null
+++ b/results/classifier/008/vnc/11357571
@@ -0,0 +1,57 @@
+vnc: 0.950
+graphic: 0.915
+performance: 0.806
+device: 0.763
+network: 0.705
+semantic: 0.694
+other: 0.687
+PID: 0.681
+socket: 0.600
+debug: 0.572
+boot: 0.571
+permissions: 0.517
+KVM: 0.516
+files: 0.453
+
+[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 ?
+