CHECK failure: CreateThread failed in platform_thread.cc |
|||||||
Issue descriptionDetailed report: https://clusterfuzz.com/testcase?key=4654982469779456 Fuzzer: inferno_twister Job Type: windows_asan_content_shell Platform Id: windows Crash Type: CHECK failure Crash Address: Crash State: CreateThread failed in platform_thread.cc Sanitizer: address (ASAN) Regressed: https://clusterfuzz.com/revisions?job=windows_asan_content_shell&range=545729:545730 Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=4654982469779456 Issue filed automatically. See https://github.com/google/clusterfuzz-tools for more information.
,
Mar 29 2018
I just changed a test expectation.
,
Apr 4 2018
> Unable to load the test case. it just keeps loading and displays timeout error > By looking in to stack trace this issue looks similar to bug 782099 , hence assigning to same dev for more updates on this issue. > hta@ Could you please take a look in to this issue? Thanks!
,
May 16 2018
Managed to reduce the test case to what I think is the essential version (see abandoned changelist https://chromium-review.googlesource.com/c/chromium/src/+/1061176) Unable to reproduce a failure. Script: <html><head id=tCF0><script> ; typeof __v_5 == "undefined" var __v_30 = function () { pc = new webkitRTCPeerConnection( null); }; for (var __v_40 = 0; __v_40 < 1000; __v_40++) __v_30(); </script></head><body id=tCF1> foo </body> <script> if (window.testRunner) testRunner.waitUntilDone(); if (window.layoutTestController) layoutTestController.waitUntilDone(); function reloadMe() { setTimeout("window.location.reload();", 0); } document.addEventListener("DOMContentLoaded", reloadMe, false); </script> </html> Closing as "unable to reproduce".
,
May 21 2018
Reopened, since it reproduced on Linux after a few thousand reloads. Output at end of run: CONSOLE ERROR: line 5: Uncaught UnknownError: Failed to construct 'RTCPeerConnection': Cannot create so many PeerConnections <--- Last few GCs ---> [1:0x31491fbf8020] 4449468 ms: Mark-sweep 2056.6 (2300.2) -> 2056.0 (2300.2) MB, 5642.6 / 1.7 ms (+ 29.2 ms in 14 steps since start of marking, biggest step 7.0 ms, walltime since start of marking 5946 ms) (average mu = 0.189, current mu = 0.168) deseri[1:0x31491fbf8020] 4450885 ms: Scavenge 2062.7 (2306.2) -> 2061.5 (2306.7) MB, 19.9 / 0.1 ms (average mu = 0.189, current mu = 0.168) allocation failure <--- JS stacktrace ---> #CRASHED - renderer #CRASHED - renderer (The CONSOLE ERROR comes from the test, and is expected)
,
May 21 2018
The crash on Linux comes after 3780 reloads - that is, after creating 1.89 million PeerConnections (500 PeerConnections per reload).
,
May 21 2018
It seems that we have a bigger problem - in that "window.reload" seems to play havoc with the counter I'm using to keep track of the number of PeerConnections. In particular, this sequence: <allocate 500 PeerConnections, get an error> window.reload() <allocate more PeerConnections> will sometimes get zero connections allocated before failing, sometimes it will allocate 1000. Question for @haraken: what is the relationship between garbage collection, window.reload() and InstanceCounters::CounterValue?
,
May 22 2018
InstanceCounter is per process. If window.reload recreates a renderer process (this may happen randomly), it's reset.
,
May 22 2018
@haraken does window.reload by itself cause any object to be deallocated, or garbage collection to be called? I assume (but want to verify the assumption) that when a renderer process is recreated, all objects from the previous renderer process disappear.
,
May 22 2018
If a renderer process is created, all objects in the previous renderer is gone because the process is gone. If a renderer process is not recreated, all objects in the previous renderer will be collected in the next GC.
,
May 23 2018
It seems that 4000 page reloads will get you an out-of-memory condition wihtout touching RTCPeerConnection. Added repro script for that to https://bugs.chromium.org/p/chromium/issues/detail?id=270000 - which is open and seems relevant. Found an error in the counting of allocated PeerConnnections; will fix that and close this bug.
,
May 23 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/87799658d2f6ec17da4145d31f7b4b6dc27a0f34 commit 87799658d2f6ec17da4145d31f7b4b6dc27a0f34 Author: Harald Alvestrand <hta@chromium.org> Date: Wed May 23 12:25:37 2018 Revise counting of allocated RTCPeerConnections The old count wouldn't count RTCPeerConnections allocated when returning an error saying "too many PeerConnections", but those would be garbage collected later. This change fixes that issue. Tested: Before the fix, a different test failed on the (new) DCHECK. After the fix, the same test didn't fail. Bug: 827064 Change-Id: I4765ce7043fd8a4e0c9c54dc1ec403e986ffed77 Reviewed-on: https://chromium-review.googlesource.com/1061176 Reviewed-by: Henrik Boström <hbos@chromium.org> Commit-Queue: Harald Alvestrand <hta@chromium.org> Cr-Commit-Position: refs/heads/master@{#561044} [modify] https://crrev.com/87799658d2f6ec17da4145d31f7b4b6dc27a0f34/third_party/blink/renderer/modules/peerconnection/rtc_peer_connection.cc
,
May 23 2018
Since this issue might have caused the reported error, closing as fixed.
,
Jun 7 2018
[bulk-edit: disregard if N/A] Can the owner please set milestone to this bug if applicable? |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by ClusterFuzz
, Mar 29 2018Owner: battre@chromium.org
Status: Assigned (was: Untriaged)