[Qemu-devel] [BUG] VNC: client won't send FramebufferUpdateRequest if job in flight is aborted

[Ying Fang]

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 ?