It passed in the next run so seems it's a flaky test:

https://test-results.appspot.com/dashboards/flakiness_dashboard.html#testType=webkit_unit_tests&tests=DedicatedWorkerTest.UseCounter

[ RUN      ] DedicatedWorkerTest.UseCounter
2017-03-08 12:06:05.807 webkit_unit_tests[7665:1c07] In 'CFPasteboardCopyDataReturn __CFPasteboardCopyData(CFPasteboardRef, CFIndex, CFIndex, CFStringRef, Boolean, Boolean)', file /SourceCache/CF/CF-855.17/AppServices.subproj/CFPasteboard.c, line 2953, during unlock, spin lock 0x16dda0018 has value 0x0, which is not locked.  The memory has been smashed or the lock is being unlocked when not locked.
../../third_party/WebKit/Source/core/workers/DedicatedWorkerTest.cpp:215: Failure
Value of: workerMessagingProxy()->waitForNotification()
  Actual: 4-byte object <01-00 00-00>
Expected: Notification::ThreadTerminated
Which is: 4-byte object <02-00 00-00>
ASAN:DEADLYSIGNAL
=================================================================
==7665==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x000117863a46 bp 0x00014d812970 sp 0x00014d812760 T7)
==7665==The signal is caused by a READ memory access.
==7665==Hint: address points to the zero page.

/cc lunalu@ who is currently looking at some other flakiness in UseCounter tests.

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

commit 7dadef7920fa13a23f2957f61993f079d173dc48
Author: kolos <kolos@chromium.org>
Date: Wed May 17 15:13:01 2017

Disable flaky DedicatedWorkerTest.UseCounter

TBR=nhiroki@chromium.org
BUG= 699712 

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

[modify] https://crrev.com/7dadef7920fa13a23f2957f61993f079d173dc48/third_party/WebKit/Source/core/workers/DedicatedWorkerTest.cpp

nhiroki@
Ping.
Is this a bug of the test? Or a bug in the production code?

I'll take a look (P1->P2 because this would be a failure in the test)

I cannot reproduce this on my local machine (Linux ASAN build). I'll enable the test again and monitor results.

Patch: https://chromium-review.googlesource.com/c/590341/

I'll run try-servers before landing the patch.

The linux_chromium_tsan_rel_ng bot caught stable failures:

[ RUN      ] DedicatedWorkerTest.UseCounter
../../third_party/WebKit/Source/core/workers/DedicatedWorkerTest.cpp:257: Failure
      Expected: Notification::kThreadTerminated
      Which is: 4-byte object <02-00 00-00>
To be equal to: WorkerMessagingProxy()->WaitForNotification()
      Which is: 4-byte object <01-00 00-00>

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

commit f62670a22b52acb7c577c0975f518df9aa6ee966
Author: Hiroki Nakagawa <nhiroki@chromium.org>
Date: Fri Jul 28 10:14:37 2017

Worker: Fix flaky crashes in DedicatedWorkerTest.UseCounter

Before this CL, WaitForNotification() in TearDown() may return
kPendingActivityReported and it results in a test failure and a crash.

To fix it, this CL makes TearDown() explicitly wait until worker thread
termination.

Bug:  699712 
Change-Id: Ic2dd34bb6723e2a522bea1dafcb721e04b03c8ec
Reviewed-on: https://chromium-review.googlesource.com/590341
Reviewed-by: Matt Falkenhagen <falken@chromium.org>
Commit-Queue: Matt Falkenhagen <falken@chromium.org>
Cr-Commit-Position: refs/heads/master@{#490347}
[modify] https://crrev.com/f62670a22b52acb7c577c0975f518df9aa6ee966/third_party/WebKit/Source/core/workers/DedicatedWorkerTest.cpp
[modify] https://crrev.com/f62670a22b52acb7c577c0975f518df9aa6ee966/third_party/WebKit/Source/core/workers/ThreadedMessagingProxyBase.h