Assigning to concern owner from CL --
https://chromium.googlesource.com/chromium/src/+log/1504af7fee3fcc0532208cfe3042571d89d131ed..615bbb898b2b62c1e1720d4278aba988662cc77b?pretty=fuller

Suspecting Commit#
https://chromium.googlesource.com/chromium/src/+/c9500f1d6491a41b4222f883a60b84ad3fd82734

@suzyh -- Could you please look into the issue, kindly re-assign if this is not related to your changes.
Thank You.

My patch made a DCHECK into a CHECK, so my patch did not introduce the problem, only made it visible.

The test case refers to SharedWorker, but also includes

const kFeature = -4500000000;  // From UseCounter.h                              

I don't know whether this is a problem with SharedWorker, or a weakness of our testing of UseCounters that we need to declare the feature number by hand in the JS tests.

nhiroki: Can you take this?

I agree with comment #2, it looks like the fuzzer is passing a crazy value to the internals API for UseCounter and causing a DCHECK or CHECK failure.

Probably the internals API should not crash when passed a crazy value.

Based on that diagnosis, Pri=3 since this is just internals API.

Agree with #2 and #3. We could simply make the internals API return or raise an exception when an invalid value is passed.

CL: https://codereview.chromium.org/2820193003/

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

commit 4b267ce12fab17dfa38615933571eae96faf63f1
Author: nhiroki <nhiroki@chromium.org>
Date: Tue Apr 18 04:29:52 2017

Worker: Raise an exception when an invalid feature number is passed to WorkerInternals::CountFeature

Before this CL, when an invalid feature number[1] is passed to
WorkerInternals::CountFeature/CountDeprecation, it ends up a check failure. This
is not a problem in real world applications because the internals APIs are used
only for testing, but it makes the fuzzer sad (see the report in the issue).

To make the fuzzer happy, this CL makes the functions raise an exception when
such an invalid value is given.

[1] feature < 0 || UseCounter::kNumberOfFeatures < feature

BUG= 712003 

Review-Url: https://codereview.chromium.org/2820193003
Cr-Commit-Position: refs/heads/master@{#465137}

[modify] https://crrev.com/4b267ce12fab17dfa38615933571eae96faf63f1/third_party/WebKit/Source/core/testing/WorkerInternals.cpp
[modify] https://crrev.com/4b267ce12fab17dfa38615933571eae96faf63f1/third_party/WebKit/Source/core/testing/WorkerInternals.h
[modify] https://crrev.com/4b267ce12fab17dfa38615933571eae96faf63f1/third_party/WebKit/Source/core/testing/WorkerInternals.idl

The patch should fix this. Scheduled a redo task on the fuzzer dashboard.

ClusterFuzz has detected this issue as fixed in range 465128:465138.

Detailed report: https://clusterfuzz.com/testcase?key=5361632319635456

Fuzzer: inferno_layout_test_fuzzer
Job Type: linux_ubsan_vptr_content_shell_drt
Platform Id: linux

Crash Type: CHECK failure
Crash Address: 
Crash State:
  bit < size() in BitVector.h
  blink::UseCounter::RecordMeasurement
  _ZN3IPC8MessageTI39ViewMsg_CountFeatureOnSharedWorker_MetaSt5tupleIJjEEvE8Dispat
  
Sanitizer: undefined (UBSAN)

Regressed: https://clusterfuzz.com/revisions?job=linux_ubsan_vptr_content_shell_drt&range=454815:454830
Fixed: https://clusterfuzz.com/revisions?job=linux_ubsan_vptr_content_shell_drt&range=465128:465138

Reproducer Testcase: https://clusterfuzz.com/download/AMIfv97mlrLRiblqOHbuA909NTJ7oUnYK_V3G0RxGhl892jMBYYFlbZ5asYoumTTAsa4Ot0YpR8rwi_JDB4myyuWuM8T5hEzAQAPz6oFufujwdmk3KeG9tY3g2IgWCImlNdKwV-BDyhwH2ep2imj8Yb8VKybGSuH6l1hF33D4n8mSl_VevUoMEN3U18EuXgHpHvjXzGvTp7DFxkNxFih6hOFBXYTJ1qzPbwQ8uxyr8Xp9qrqdgnqrQ1QDMA16-qSuOf6_bNk7S7bo-cdQ5sxipeeRnP2LEX32NyDC13fqHKjvl4JK4wZQ_AdgZYFLeN0sKEhG2s6R74UCIEDrAmkQAsIF2X3g2pvGEeFF_JeS-AjpIi-9dC8UYI?testcase_id=5361632319635456


See https://dev.chromium.org/Home/chromium-security/bugs/reproducing-clusterfuzz-bugs for more information.

If you suspect that the result above is incorrect, try re-doing that job on the test case report page.