vino-server takes up 100% CPU load when option "configure UPnP routers" is set

Bug #1448432 reported by Rüdiger Kupper
32
This bug affects 6 people
Affects Status Importance Assigned to Milestone
One Hundred Papercuts
Fix Released
Critical
Unassigned
vino
Unknown
High
vino (Ubuntu)
Fix Released
High
Unassigned
Nominated for Vivid by Alberto Salvia Novella

Bug Description

After upgrade to vivid, vino-server takes up 100% CPU load.
(There is an older bug report that sounds similar, but has been fixed in the past: bug #31037 I do not know if it is related.)

ProblemType: Bug
DistroRelease: Ubuntu 15.04
Package: vino 3.8.1-0ubuntu5
ProcVersionSignature: Ubuntu 3.19.0-15.15-generic 3.19.3
Uname: Linux 3.19.0-15-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.17.2-0ubuntu1
Architecture: amd64
CurrentDesktop: Unity
Date: Sat Apr 25 13:20:02 2015
EcryptfsInUse: Yes
InstallationDate: Installed on 2012-12-20 (855 days ago)
InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Release amd64 (20121017.5)
SourcePackage: vino
UpgradeStatus: Upgraded to vivid on 2015-04-24 (1 days ago)

Revision history for this message
Rüdiger Kupper (ruediger.kupper) wrote :
Revision history for this message
Rüdiger Kupper (ruediger.kupper) wrote :

Update: The bug is reproducibly related to open "Automatically configure UPnP routers". Only if this option is set in vino-preferences, the high CPU load occurs. Unchecking the option makes vino-server run normally.

summary: - vino-server takes up 100% CPU load
+ vino-server takes up 100% CPU load when option "configure UPnP routers"
+ is set
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in vino (Ubuntu):
status: New → Confirmed
Revision history for this message
Mike (mediabot666) wrote :

Same problem here on 15.04. I removed the UPNP and vino stopped taking up 100% of the cpu

Changed in hundredpapercuts:
status: New → Confirmed
Changed in vino (Ubuntu):
importance: Undecided → Critical
Changed in hundredpapercuts:
importance: Undecided → Critical
Revision history for this message
Alberto Salvia Novella (es20490446e) wrote :

Please:

1. Report to <https://bugzilla.gnome.org/>.
2. Paste the new report link here.
3. Set this bug status back to "confirmed".

Thank you.

Changed in vino (Ubuntu):
status: Confirmed → Incomplete
Changed in hundredpapercuts:
status: Confirmed → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for vino (Ubuntu) because there has been no activity for 60 days.]

Changed in vino (Ubuntu):
status: Incomplete → Expired
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for One Hundred Papercuts because there has been no activity for 60 days.]

Changed in hundredpapercuts:
status: Incomplete → Expired
Revision history for this message
Logicwax (logicwax) wrote :

Can confirm, this bug is still in Ubuntu 15.10 (Wiley) and occurs only when UPnP is enabled.

Revision history for this message
Rüdiger Kupper (ruediger.kupper) wrote :

Thank you, Logicwax. I have now filed a bug report at the GNOME bug tracker:
https://bugzilla.gnome.org/show_bug.cgi?id=759632

Changed in hundredpapercuts:
status: Expired → Confirmed
Changed in vino (Ubuntu):
status: Expired → Confirmed
Changed in vino:
importance: Unknown → High
status: Unknown → Confirmed
Revision history for this message
William Tyler Sontag (wtsontag) wrote :

Running Ubuntu 15.10 and im getting this behavior even when that option is unchecked... i'm going to try cycling the configuration to see if that fixes it. It seems to only occur after 48-72 hours of uptime.

Revision history for this message
Rüdiger Kupper (ruediger.kupper) wrote :

William, thank you. I cannot confirm your findings. With me, the effect is directly coupled to the uPnP-option setor unset. I run a server with uptimes well over four months, and the problem never appears while the option is unset. However, it appears reproducibly when the option is set.

Revision history for this message
Rüdiger Kupper (ruediger.kupper) wrote :

Oops, that was meant to read: Well over four weeks. But I guess it makes nothing of a difference regarding this bug.

Revision history for this message
GingwinJoe (atlantide) wrote :
Revision history for this message
GingwinJoe (atlantide) wrote :

Moreover, since I cannot set the UPnP option on and I cannot manage the WiFi APs and routers around here, I am not able to use the VNC server (Remote Access) at all.
So this bug is very high - top priority - a show stopper in my book.
My only solution for now is to install a different server all toghether.

Revision history for this message
w-sky (w-sky) wrote :

Same with me here, except that I have to log out and log in (or restart) after I have changed the UPnP setting to "off". Until doing so vino is running wild.

Nevertheless, when the machine is running fine and I switch UPnP at Desktop Sharing "on", vino immediately is again at 100% load on one core.

Problem appeared after upgrade from 14.04 LTS to 16.04 LTS, 32 bit Atom system, no GPU.

tags: added: xenial
Revision history for this message
Sebastien Bacher (seb128) wrote :
Changed in vino (Ubuntu):
importance: Critical → High
status: Confirmed → Fix Released
Changed in vino:
status: Confirmed → Unknown
Revision history for this message
Paul White (paulw2u) wrote :

Closing Papercuts task as fixed in Ubuntu some time ago

Changed in hundredpapercuts:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.