1 files changed, 74 insertions, 0 deletions
diff --git a/results/classifier/015/vnc/11357571 b/results/classifier/015/vnc/11357571
new file mode 100644
index 00000000..c821f311
--- /dev/null
+++ b/results/classifier/015/vnc/11357571
@@ -0,0 +1,74 @@
+vnc: 0.950
+graphic: 0.915
+performance: 0.806
+device: 0.763
+network: 0.705
+semantic: 0.694
+PID: 0.681
+ppc: 0.632
+peripherals: 0.629
+socket: 0.600
+operating system: 0.594
+debug: 0.572
+boot: 0.571
+architecture: 0.568
+risc-v: 0.550
+x86: 0.534
+i386: 0.520
+permissions: 0.517
+KVM: 0.516
+mistranslation: 0.516
+hypervisor: 0.508
+VMM: 0.505
+kernel: 0.480
+TCG: 0.462
+register: 0.454
+files: 0.453
+user-level: 0.433
+arm: 0.405
+assembly: 0.389
+alpha: 0.379
+virtual: 0.376
+
+[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 ?
+