After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 704098 - 100% cpu when the server dies
100% cpu when the server dies
Status: RESOLVED FIXED
Product: gtk-vnc
Classification: Other
Component: general
unspecified
Other Linux
: Normal major
: ---
Assigned To: gtk-vnc-maint
gtk-vnc-maint
Depends on:
Blocks:
 
 
Reported: 2013-07-12 14:34 UTC by Jonh Wendell
Modified: 2013-09-18 11:23 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jonh Wendell 2013-07-12 14:34:32 UTC
steps:

1) connect to a vnc server
2) when connected and accessing remote side, kill the server process.
3) vnc client (vinagre or gvncviewer) consumes 100% of cpu for a while
4) after some time, the client recognizes the server is gone and closes the connection.
Comment 1 Daniel P. Berrange 2013-09-16 12:38:00 UTC
commit e7c0fce768d0abe2952e50c3864932a133e32673
Author: Daniel P. Berrange <berrange@redhat.com>
Date:   Mon Sep 16 13:32:38 2013 +0100

    Reset 'blocking' flag after I/O wait
    
    If the 'vnc_connection_read_wire' goes into an I/O wait
    due to blocking I/O, the 'blocking' flag gets set to
    true. Upon returning from the wait, it jumps back to
    the start of the function, but does not reset the 'blocking'
    flag to false. If the I/O attempt succeeds, this doesn't
    matter, but if it fails for an error reason, this gets
    mistakenly treated as blocking I/O again.
    
    This is seen most often when the remote server drops the
    connection. If the client was blocking on I/O at this
    time, it could get into a potentially infinite loop.
    
      https://bugzilla.gnome.org/show_bug.cgi?id=704098
    
    Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Comment 2 Daniel P. Berrange 2013-09-18 11:23:41 UTC
Fixed in the 0.5.3 release