New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 10 users

Issue metadata

Status: Fixed
Last visit > 30 days ago
Closed: Apr 2016
NextAction: ----
OS: ----
Pri: 2
Type: Bug

Sign in to add a comment

Issue 5733: Creating then destroying connections causes 100% CPU

Reported by, Apr 4 2016

Issue description

What steps will reproduce the problem?
1. Every 3 seconds, create an RTCPeerConnection with a DataChannel
2. Destroy the RTCPeerConnection/DataChannel after some time (say, 30 seconds)

What is the expected result?

This should be very lightweight and use little to no resources. This seems like a reasonable expectation, since:

- There are just 10 connection objects alive at any given time
- None of the connection objects are actually connected to a remote peer
- The old connection objects are destroyed and so should stop using CPU resources

What do you see instead?

The Google Chrome Helper process's CPU usage gradually increases until it reaches 100%. The connections stick around for a long time on chrome://webrtc-internals, and after a while, chrome://webrtc-internals becomes completely unresponsive.

In the OS X Activity Monitor, the Google Chrome Helper process shows a LOT of Idle Wake Ups. Tens of thousands after just a few minutes.

If you leave the page open at 100% CPU usage for a while, say overnight, the entire computer slows to a crawl and even keyboard input becomes impossible. So, you cannot log back into the machine, for example. It's like the kernel is being DOS'd by the Google Chrome Helper process.

What version of the product are you using? On what operating system?

Chrome 49.0.2623.110 (64-bit)
OS X 10.11.4

Please provide any additional information below.

This code will reproduce the issue:

function createPeer () {
  var pc = new webkitRTCPeerConnection({
    iceServers: [
        url: 'stun:',
        urls: 'stun:'
  }, {})

  var channel = pc.createDataChannel(String(Math.floor(Math.random() * 1000000)), {})
  channel.binaryType = 'arraybuffer'
  channel.onmessage = function (event) {}
  channel.onopen = function () {}
  channel.onclose = function () {
    console.log('channel onclose')

  pc.onnegotiationneeded = function () {
    pc.createOffer(function (offer) {
      pc.setLocalDescription(offer, function (offer) {
        console.log('set local description')
      }, onError)
    }, onError)

  function onError (err) {

  setTimeout(function () {
  }, 30000)

setInterval(createPeer, 3000)
Screen Shot 2016-04-04 at 13.03.09.png
69.1 KB View Download

Comment 1 by, Apr 4 2016

Project Member
Components: Internals
Brave, can you try to repro this?

Comment 2 by, Apr 5 2016

I can confirm this was an issue I was seeing regularly about a year ago. Symptoms were exactly the same, and after a while of trying to debug it, caused me to give up on a WebRTC-based project with many connections.

Reported here:

Comment 3 by, Apr 5 2016

Project Member
Yes I can reproduce this on OSX and Linux with Chrome M49 and no such problem on Win with same M49. Also I can't reproduce this with latest Canary on OSX and Chromium building on Linux. So it seems that this has been fixed recently.

Could you please help to confirm that later Chrome versions have fixed this problem?

Comment 4 by, Apr 5 2016

It does seem fixed for me on:

Version 51.0.2700.0 canary (64-bit)
OS X 10.11.4

Do we know what caused it to be fixed?

Comment 5 by, Apr 6 2016

Project Member
Status: Fixed (was: Unconfirmed)
Not sure. As I remember there's some fixes to iOS which should be a common issue, but I can't find the related issue.

Comment 6 by, Apr 25 2016

Issue is not fixed for me. Running up-to-date Chrome 50.0.2661.86 (64-bit) on Mac OSX.

Reducing the interval of the script to 'createPeer' every second and 'channel.close' every ten seconds, I see my cpu usage slowly climb up to 100% within five minutes.

Garbage collection seems ok though...

Comment 7 by, Apr 25 2016

Project Member
#6 - can you recheck this with a current beta or canary Mac build? Comment #4 indicated that this issue seemed fixed with 51.0.2700.0, which is newer than the version you used. Currently, lists:
Mac beta: 51.0.2704.22
Mac canary: 52.0.2715.0

Comment 8 by, Apr 26 2016

You are right. Confirming fix in canary 52.0.2717.0 (64-bit).

Comment 9 Deleted

Sign in to add a comment