Debug-dumping the state of all PCs when limit is exceeded would help.
It would be good to be able to repro the relevant problems within a single test page. The limit hit by the bot could be related to swarming and/or running many test pages.

Several things to consider:

1. The PC can guard against itself being GC'd. This makes sense for an active connection, but we should think about what to do about PCs that are not, in some sense, "active". There are plenty of tests that never run pc.close() but that are not actively doing anything with the PC.

2. For tests that do set up active connections between PCs, we should close those connections, but this does not fully explain exceeding the limit.
Is there a way to add cleanup (close) logic that is run whether or not the test completes?

3. Does GC consider PC is more resource-heavy than the members visible in JS? Do we need to mark it as bigger for GC to care about it when not calling gc()?

 Issue 797922  has been merged into this issue.

This has now been observed outside of my CL as well ( https://crbug.com/797922 ).

I'll make sure RTCPeerConnection-many.html closes and GCs its PCs.

Also attempting to get more information out from the failure in this CL (since failure only happens randomly on swarming bot): https://chromium-review.googlesource.com/c/chromium/src/+/845619

I expect https://chromium-review.googlesource.com/c/chromium/src/+/845681 will fix any immediate issues related to this, but 1), 2) and 3) are worth considering regardless.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f7d23283ffc6976c677eef75d13022b1dc8aefb9

commit f7d23283ffc6976c677eef75d13022b1dc8aefb9
Author: Henrik Boström <hbos@chromium.org>
Date: Thu Dec 28 18:22:50 2017

Close and GC RTCPeerConnections allocated by tests testing the limit.

When webkit_layout_tests are run on swarming bots, garbage collection is
not guaranteed to occur between test pages. As such, we cannot assume
the inital PC count is 0 and we cannot exit the test without ensuring
they have been collected. This requires closing all of them and invoking
gc().

RTCPeerConnection-many.html is updated to test several things in the
same test as to minimize inter-test dependencies:
- Allocating limit number of PCs does not throw an exception (not
  assuming the initial count is 0).
- Exceeding the limit throws UnknownError.
- Closing PCs and calling gc() collects the PCs allocated by the test
  (not assuming unrelated PCs from other tests are GC'd).

This CL also fixes a bug where the RTCPeerConnection that exceeded the
limit was not said to be closed, causing a DCHECK failure when GC'd.

Bug:  797876 
Change-Id: Ia0ef2b49975cc7f14dabccc1d71b849040fe6c45
Reviewed-on: https://chromium-review.googlesource.com/845681
Commit-Queue: Henrik Boström <hbos@chromium.org>
Reviewed-by: Harald Alvestrand <hta@chromium.org>
Cr-Commit-Position: refs/heads/master@{#526310}
[modify] https://crrev.com/f7d23283ffc6976c677eef75d13022b1dc8aefb9/third_party/WebKit/LayoutTests/fast/peerconnection/RTCPeerConnection-many.html
[modify] https://crrev.com/f7d23283ffc6976c677eef75d13022b1dc8aefb9/third_party/WebKit/Source/modules/peerconnection/RTCPeerConnection.cpp

Tentatively marking as Fixed, not Verified.