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 332011 - Vino-server takes 90% of cpu on wrong login
Vino-server takes 90% of cpu on wrong login
Status: RESOLVED FIXED
Product: vino
Classification: Applications
Component: Server
2.13.x
Other Linux
: Normal major
: ---
Assigned To: Vino Maintainer(s)
Vino Maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2006-02-21 10:53 UTC by Sebastien Bacher
Modified: 2006-10-05 13:07 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch by Gary Coady <gary@lyranthe.org> to remedy the problem (3.17 KB, patch)
2006-03-31 17:39 UTC, Daniel Holbach
accepted-commit_now Details | Review

Description Sebastien Bacher 2006-02-21 10:53:12 UTC
That bug has been opened on https://launchpad.net/distros/ubuntu/+source/vino/+bug/31037

"The load of Vino-server becomes about 90 % of the cpu. It goes as far as 99% of total cpu usage. A simple "killall vino-server" reduces cpu load to 5-10 %. I have know idea why vino-server takes that much of cpu. I didn't make any connection to it. It just happens after a while.
...
> Thanks for your bug. What version of Ubuntu do you use? Could you get a backtrace when that happens again:
> - gdb $(pidof vino-server)
> (gdb) thread apply all bt
> 
> Does it happen often?
...
I now know it happend after one tried to make conact with my pc, but she provided (on purpose) the wrong password. This gave the problem.

i read some manpages and info on the web, and i got output of gdb. It's located here: http://mifa.myftp.org/gdb-vino-output.txt."
Comment 1 Sebastien Bacher 2006-02-21 10:57:14 UTC
The issue is easy to get, try to login with xvncviewer 2 times in a row and using a wrong password (using 2.13.5), backtrace: 

(gdb) bt
  • #0 __kernel_vsyscall
  • #1 __write_nocancel
    from /lib/tls/i686/cmov/libpthread.so.0
  • #2 _X11TransSocketWrite
    at Xtranssock.c line 2160
  • #3 _X11TransWrite
    at Xtrans.c line 897
  • #4 _XFlushInt
    at ../../src/XlibInt.c line 655
  • #5 _XReply
    at ../../src/XlibInt.c line 1694
  • #6 XSync
    at ../../src/Sync.c line 48
  • #7 vino_fb_xdamage_idle_handler
    at vino-fb.c line 595
  • #8 g_idle_dispatch
    at gmain.c line 3796
  • #9 IA__g_main_context_dispatch
    at gmain.c line 1916
  • #10 g_main_context_iterate
    at gmain.c line 2547
  • #11 IA__g_main_loop_run
    at gmain.c line 2751

Comment 2 Daniel Holbach 2006-03-31 17:39:18 UTC
Created attachment 62472 [details] [review]
patch by Gary Coady <gary@lyranthe.org> to remedy the problem

If a client is "on hold", then no processing will be performed in vino_server_update_client_timeout. However, the socket will therefore continue to be ready, and the GTK main loop will continually call this callback function.

Proposed fix: remove the client from the main loop when "on hold".

Ways to put a client on hold (for testing):
1. enable client authentication
2. turn off remote display altogether, and run vino-server manually
Comment 3 Mark McLoughlin 2006-05-04 18:18:55 UTC
Patch looks good, with one nitpick - please fix the indentation i.e.

  if (on_hold)
    {
      if (client->io_watch)
        {

Please go ahead and commit once you've fixed that

Thanks
Comment 4 Kjartan Maraas 2006-10-05 13:07:40 UTC
Commited. Thanks.