Providing Findit details for internal purpose:
Suspected CLs	
---------------
Git blame below is NOT necessarily who introduced the crash nor the owner for it. Please check the code before assigning to anyone.(No CL in the regression range changed the crashing files.)

Author: tzik
Project: chromium
Changelist: https://chromium.googlesource.com/chromium/src/+/27d1e313968955f1a120b65b31e316263365b1b3
Time: Tue Sep 13 05:28:59 2016
The CL last changed line 64 of file callback.h, which is stack frame 4.

Suspected Project: chromium
Suspected Component: Blink>DOM

tzik@ - Do you have any idea on this issue? Using code search observed there is some recent changes on file "callback.h" so assigning it to you. If it's not related to your change please feel free to reassign to the concerned Dev person.

Thanks!

ClusterFuzz has detected this issue as fixed in range 420372:420502.

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

Fuzzer: therealholden_worker
Job Type: linux_asan_chrome_mp
Platform Id: linux

Crash Type: UNKNOWN READ
Crash Address: 0x000000000000
Crash State:
  blink::MessagePort::dispatchMessages
  void base::internal::Invoker<base::internal::BindState<void
  blink::internal::CallClosureTask<void
  
Regressed: https://cluster-fuzz.appspot.com/revisions?job=linux_asan_chrome_mp&range=419848:419971
Fixed: https://cluster-fuzz.appspot.com/revisions?job=linux_asan_chrome_mp&range=420372:420502

Minimized Testcase (1.62 Kb): https://cluster-fuzz.appspot.com/download/AMIfv953oZDfpUqws-8D8GI0MHntE5_24mvcvkfX_sm1IQAw1rsEtzXuMXZg9TM4tKJKfD6tJ5vtBTSpJCdWOb6qEU_Gm96kUdFjYgowyS9dRhKPzKNv-2kQCANbg8zkp0J8PByPdIaGpLkeRNgXJh1qMwdANNXLAg?testcase_id=4847693228933120

Additional requirements: Requires HTTP

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.

ClusterFuzz testcase is verified as fixed, closing issue.

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

Re-Opening the issue as Clusterfuzz has detected the crash again, Clusterfuzz update in the next comment.Thank you 

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

Fuzzer: therealholden_worker
Job Type: linux_asan_chrome_v8_arm
Platform Id: linux

Crash Type: UNKNOWN READ
Crash Address: 0x00000000
Crash State:
  blink::MessagePort::dispatchMessages
  void base::internal::Invoker<base::internal::BindState<void
  base::internal::Invoker<base::internal::BindState<void
  

Unminimized Testcase: https://cluster-fuzz.appspot.com/download/AMIfv96LaHTygu7ZuEvmbboBRDWWR6-aO4GHBfsRq470Z3ma58Culmfc6pWvmclQrZI3lC1Vd0Pcve-LpJ8f5lCZUF-X2bJh6deYkukqfDbEugrZDVjRvAymk2P16BurTdkUFjoEwVJbK5ZryVvm34_I6G77W3BRoA?testcase_id=6695966973624320


Additional requirements: Requires HTTP

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

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

Fuzzer: inferno_layout_test_unmodified
Job Type: windows_syzyasan_chrome
Platform Id: windows

Crash Type: UNKNOWN
Crash Address: 0x00000003
Crash State:
  blink::MessagePort::dispatchMessages
  base::internal::Invoker<base::internal::BindState<void
  base::internal::Invoker<base::internal::BindState<void
  
Regressed: https://cluster-fuzz.appspot.com/revisions?job=windows_syzyasan_chrome&range=420630:420810

Minimized Testcase (1.62 Kb): https://cluster-fuzz.appspot.com/download/AMIfv95lW43uLy1CcpbbJKt26fk0hbQRMGRi1xiX2tQ5duIecEu7lghXvKbsdibEsptEReruKL4R54AHXC4TovOD6rMCWV9zTUKpIHhp6w7c94o-wPTjhAc5B6BHslWUVzOSYjsvWUWmWpQB_m1nGBW19tsCirMEmw?testcase_id=4922075217395712

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

I think this slipped by our triage process. nhiroki@ can you take a look as the testcase involves shared workers and postMessage?

According to clusterfuzz, this is a regression in M55 (current beta channel).

==1==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7fddfbacd26a bp 0x7fff54b4e570 sp 0x7fff54b4e160 T0)
==1==The signal is caused by a READ memory access.
==1==Hint: address points to the zero page.
SCARINESS: 10 (null-deref)
    #0 0x7fddfbacd269 in blink::MessagePort::dispatchMessages() third_party/WebKit/Source/core/dom/MessagePort.cpp:206:36
    #1 0x7fddfbadc6e7 in void base::internal::FunctorTraits<void (blink::MessagePort::*)(), void>::Invoke<blink::CrossThreadPersistent<blink::MessagePort>>(void (blink::MessagePort::*)(), blink::CrossThreadPersistent<blink::MessagePort>&&) base/bind_internal.h:214:12
    #2 0x7fddfbadc241 in void base::internal::InvokeHelper<true, void>::MakeItSo<void (blink::MessagePort::* const&)(), blink::CrossThreadPersistent<blink::MessagePort>>(void (blink::MessagePort::* const&)(), blink::CrossThreadPersistent<blink::MessagePort>&&) base/bind_internal.h:305:5
    #3 0x7fddfbadbf56 in void base::internal::Invoker<base::internal::BindState<void (blink::MessagePort::*)(), blink::CrossThreadWeakPersistent<blink::MessagePort> >, void ()>::RunImpl<void (blink::MessagePort::* const&)(), std::__1::tuple<blink::CrossThreadWeakPersistent<blink::MessagePort> > const&, 0ul>(void (blink::MessagePort::* const&)(), std::__1::tuple<blink::CrossThreadWeakPersistent<blink::MessagePort> > const&, base::IndexSequence<0ul>) base/bind_internal.h:361:12
    #4 0x7fddfbadbd79 in base::internal::Invoker<base::internal::BindState<void (blink::MessagePort::*)(), blink::CrossThreadWeakPersistent<blink::MessagePort> >, void ()>::Run(base::internal::BindStateBase*) base/bind_internal.h:339:12

I can repro this on Linux with an ASAN build.

falken@, Thank you for taking over this :)

As we chatted offline, this null ExecutionContext access looks strange to me because MessagePort sets a flag |m_closed| on contextDestroyed, and checks it before accessing the context. contextDestroyed() could never be called or someone could unexpectedly nullify the context...?

 issue 655870  would be the same issue.

 Issue 655870  has been merged into this issue.

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

I made a reliable test case and bisected. The likely culprit is:
Clear LifecycleObserver::m_context when LifecycleObserver::contextDestroyed gets called
https://codereview.chromium.org/2367753002/

I made a patch: https://codereview.chromium.org/2533323003/

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

commit 6ec0c90214ba34ce39e4224561235b7142d07eaa
Author: falken <falken@chromium.org>
Date: Wed Nov 30 09:05:19 2016

Messaging: Fix crash when MessagePort is closed while messages are queued

dispatchMessages() did a check at the start of function for m_closed, but it
then looped over queued messages and dispatched each one. Each dispatch causes
the onmessage handler to run, which can trigger closing the execution context.
Since https://crrev.com/9c675cfdcf006e5ca978b0dfa04f187ed36f86cc, getExecutionContext()
would then return null and crash. Since close() is called when the execution
context dies and possibly in other cases, check |m_closed| before each dispatch.

BUG= 649616 

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

[add] https://crrev.com/6ec0c90214ba34ce39e4224561235b7142d07eaa/third_party/WebKit/LayoutTests/fast/workers/close-context-messageport-crash.html
[add] https://crrev.com/6ec0c90214ba34ce39e4224561235b7142d07eaa/third_party/WebKit/LayoutTests/fast/workers/resources/close-context-messageport-crash-iframe.html
[modify] https://crrev.com/6ec0c90214ba34ce39e4224561235b7142d07eaa/third_party/WebKit/Source/core/dom/MessagePort.cpp

This crash should be fixed in 57.0.2938.0. However the testcase does postMessage in an infinite loop which will DOS the tab/browser:  issue 404738 

Request merge to 56, this fixes a crash and looped through canary with no issues.

Your change meets the bar and is auto-approved for M56 (branch: 2924)

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

commit b99d81b8ddc75ccbfdd0a2b1cefeec3a32af0221
Author: Matt Falkenhagen <falken@chromium.org>
Date: Mon Dec 05 05:32:21 2016

M56: Messaging: Fix crash when MessagePort is closed while messages are queued

dispatchMessages() did a check at the start of function for m_closed, but it
then looped over queued messages and dispatched each one. Each dispatch causes
the onmessage handler to run, which can trigger closing the execution context.
Since https://crrev.com/9c675cfdcf006e5ca978b0dfa04f187ed36f86cc, getExecutionContext()
would then return null and crash. Since close() is called when the execution
context dies and possibly in other cases, check |m_closed| before each dispatch.

BUG= 649616 

Review-Url: https://codereview.chromium.org/2533323003
Cr-Commit-Position: refs/heads/master@{#435190}
(cherry picked from commit 6ec0c90214ba34ce39e4224561235b7142d07eaa)

Review URL: https://codereview.chromium.org/2546313003 .

Cr-Commit-Position: refs/branch-heads/2924@{#325}
Cr-Branched-From: 3a87aecc31cd1ffe751dd72c04e5a96a1fc8108a-refs/heads/master@{#433059}

[add] https://crrev.com/b99d81b8ddc75ccbfdd0a2b1cefeec3a32af0221/third_party/WebKit/LayoutTests/fast/workers/close-context-messageport-crash.html
[add] https://crrev.com/b99d81b8ddc75ccbfdd0a2b1cefeec3a32af0221/third_party/WebKit/LayoutTests/fast/workers/resources/close-context-messageport-crash-iframe.html
[modify] https://crrev.com/b99d81b8ddc75ccbfdd0a2b1cefeec3a32af0221/third_party/WebKit/Source/core/dom/MessagePort.cpp

We have made a bunch of changes on ClusterFuzz side, so resetting ClusterFuzz-Wrong label.