From findit tool:

Author: hiroshige
Project: chromium
Changelist: https://chromium.googlesource.com/chromium/src/+/d25ee900e7efe3ad6c677868ff42fbbfd92b8fae
Time: Sun Jun 26 09:23:56 2016
The CL last changed line 65 of file MainThreadTaskRunner.cpp, which is stack frame 2.

Author: hiroshige
Project: chromium
Changelist: https://chromium.googlesource.com/chromium/src/+/d25ee900e7efe3ad6c677868ff42fbbfd92b8fae
Time: Sun Jun 26 09:23:56 2016
The CL last changed line 5262 of file Document.cpp, which is stack frame 3.

hiroshige@, could you please take a look and please help us to find correct owner if it is not related your changes.

WeakReferenceOwner::GetRef() is not thread-safe because it writes to |flag_|?

+tzik@

I found this is a recent regression caused by https://codereview.chromium.org/2300813003, because base::WeakPtrFactory and WTF::WeakPtrFactory have different threading restrictions:
(cc-ing author/reviewers of the CL)

('*' indicates differences between base and WTF)

WTF::WeakPtrFactory:
The following operations must be executed on the same thread:
- WeakPtrFactory's invalidation (WeakPtrFactory::revokeAll())
- WeakPtr's dereference (WeakReference::get())
* WeakPtrFactory's construction
The following operations can be executed on any thread:
- WeakPtr's destruction
- WeakPtr's copy
* WeakPtrFactory's destruction
* WeakPtr's construction (WeakPtrFactory::createWeakPtr())

bindTo() is used for thread-related hacks.

base::WeakPtrFactory:
The following operations must be executed on the same sequence:
- WeakPtrFactory's invalidation (except when no WeakPtr exists)
- WeakPtr's dereference
* WeakPtrFactory's destruction (except when no WeakPtr exists)
* WeakPtr's construction (WeakPtrFactory::GetWeakPtr(); at least GetWeakPtr() must not be called simultaneously from two threads)
The following operations can be executed on any thread:
- WeakPtr's destruction
- WeakPtr's copy
* WeakPtrFactory's construction

WeakPtrFactory is detached from sequence automatically (e.g. in WeakReferenceOwner::GetRef()).

====

MainThreadTaskRunner::postTask() is called from any thread, and thus creates a WeakPtr on any thread.
Previously, it was OK because WTF's original WeakPtrFactory::createWeakPtr() was thread-safe.
After the CL, it turned unsafe because base::WeakPtrFactory::GetWeakPtr() is not thread-safe.

I think we should make the threading assumptions consistent.
And also should we revert the CL for now?

Issue 644266 has been merged into this issue.

Issue 644266 looks like actual use-after-free case caused by this data race.
Increasing priority to Pri-1.

Lets revert and figure this out after. :)

The suspected CL (Comment #3) is r416133, 55.0.2847.0.

There is a crash report in the wild: a5fba3e500000000.
Query:
custom_data.ChromeCrashProto.magic_signature_1.name='base::internal::WeakReferenceOwner::GetRef' OMIT RECORD IF SUM(CrashedStackTrace.StackFrame.FunctionName='media::DXVAVideoDecodeAccelerator::ProcessOutputSample(IMFSample *)') != 0

(Crashes in ProcessOutputSample() is another existing bug probably caused by WeakPtr creation, Issue 644577.
 The crash reports found by the query above still contains crashes caused by existing issues in Chromium)

Start reverting the suspected CL.

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

commit 977ec315e1cf4a68b1616be8419a150a92494549
Author: hiroshige <hiroshige@chromium.org>
Date: Wed Sep 07 03:49:48 2016

Revert of Implement WTF::WeakPtr in terms of base::WeakPtr (patchset #5 id:80001 of https://codereview.chromium.org/2300813003/ )

Reason for revert:
Caused data races/crashes.

BUG= 643777 

Original issue's description:
> Implement WTF::WeakPtr in terms of base::WeakPtr
>
> BUG=none
>
> Committed: https://crrev.com/288b352ea69e3cff2540ac701bb181485d423192
> Cr-Commit-Position: refs/heads/master@{#416133}

TBR=esprehn@chromium.org,csharrison@chromium.org,yoav@yoav.ws,dcheng@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=none

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

[modify] https://crrev.com/977ec315e1cf4a68b1616be8419a150a92494549/third_party/WebKit/Source/core/html/parser/BackgroundHTMLParser.cpp
[modify] https://crrev.com/977ec315e1cf4a68b1616be8419a150a92494549/third_party/WebKit/Source/core/html/parser/BackgroundHTMLParser.h
[modify] https://crrev.com/977ec315e1cf4a68b1616be8419a150a92494549/third_party/WebKit/Source/core/html/parser/HTMLDocumentParser.cpp
[modify] https://crrev.com/977ec315e1cf4a68b1616be8419a150a92494549/third_party/WebKit/Source/core/loader/ImageLoader.cpp
[modify] https://crrev.com/977ec315e1cf4a68b1616be8419a150a92494549/third_party/WebKit/Source/platform/CrossThreadCopier.h
[modify] https://crrev.com/977ec315e1cf4a68b1616be8419a150a92494549/third_party/WebKit/Source/platform/fonts/FontFallbackList.cpp
[modify] https://crrev.com/977ec315e1cf4a68b1616be8419a150a92494549/third_party/WebKit/Source/wtf/DEPS
[modify] https://crrev.com/977ec315e1cf4a68b1616be8419a150a92494549/third_party/WebKit/Source/wtf/Forward.h
[modify] https://crrev.com/977ec315e1cf4a68b1616be8419a150a92494549/third_party/WebKit/Source/wtf/Functional.h
[modify] https://crrev.com/977ec315e1cf4a68b1616be8419a150a92494549/third_party/WebKit/Source/wtf/WeakPtr.h

There are two problem on this:
1. base::WeakPtrFactory<>'s WeakPtr creation itself is not thread safe even without invalidation due to its auto thread detach.
2. Both base::WeakPtrFactory<> and WTF::WeakPtrFactory<> are not thread safe on invalidation and WeakPtr<> creation.

As the result of an offline discussion with hiroshige@, it looks hard to make WeakPtr<> creation thread safe without locks. So, IMO, we should remove the auto thread detach from b::WPF, and then disallow multi-threaded WeakPtr creation.

Created a doc: https://docs.google.com/a/chromium.org/document/d/15Lo233qdvd33QHuVqjkLSISKLvESFVgXOCpB994ffhs/edit?usp=sharing

ClusterFuzz testcase is verified as fixed, closing issue.

If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.

ClusterFuzz has detected this issue as fixed in range 416826:416842.

Detailed report: https://cluster-fuzz.appspot.com/testcase?key=5450312297218048

Fuzzer: inferno_layout_test_unmodified
Job Type: linux_tsan_chrome_mp
Platform Id: linux

Crash Type: Data race READ 8
Crash Address: 0x7d2400001a60
Crash State:
  base::internal::WeakReferenceOwner::GetRef
  blink::MainThreadTaskRunner::postTaskInternal
  blink::MainThreadTaskRunner::postTask
  
Regressed: https://cluster-fuzz.appspot.com/revisions?job=linux_tsan_chrome_mp&range=415934:416233
Fixed: https://cluster-fuzz.appspot.com/revisions?job=linux_tsan_chrome_mp&range=416826:416842

Minimized Testcase (0.68 Kb): https://cluster-fuzz.appspot.com/download/AMIfv975Kn8p2w30i6O5eHaGxfQrrh5F47VfaF_faLmB-msFy5njIZkXx9eAh4Oz5nlc14HIBW9KznpkWk0iwofrGw3Nd_cKau61g4S-Y7mJozuVCcVFUQC0ctW-rxner84XsYcBwB1nISa1vm1u7fg1HQzUX5jghQ?testcase_id=5450312297218048

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.

Removing EditIssue view restrictions from ClusterFuzz filed bugs. If you believe that this issue should still be restricted, please reapply the label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot