Automatically applying components based on crash stacktrace and information from OWNERS files.

If this is incorrect, please apply the Test-Predator-Wrong-Components label.

Automatically assigning owner based on suspected regression changelist https://chromium.googlesource.com/chromium/src/+/48edb46b3aa0e066384d45ca8f21fec313144b72 (Remove NavigationScheduler::ScheduleReload).

If this is incorrect, please let us know why and apply the Test-Predator-Wrong-CLs label. If you aren't the correct owner for this issue, please unassign yourself as soon as possible so it can be re-triaged.

Test doesn't obviously poke the locks API? Also, bisect looks wrong.

Crash would be in the manager->GetExecutionContext()->GetTaskRunner(...) call in LockRequestImpl's constructor (called from LockManager::request), where GetExecutionContext is yielding null?

This would imply LockManager::request() is called with a valid ExecutionContext (via ScriptState), but LockManager's GetExecutionContext() (via ContextLifecycleObserver) is yielding null. Uh... fun.

Reproduced, thanks ClusterFuzz!

I'm able to hit a CHECK(this->GetExecutionContext()) in LockManager::request(). *sigh*

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

commit 03e547cdfd97c659bfe915a38e104ed8dd518bf7
Author: Joshua Bell <jsbell@chromium.org>
Date: Tue Jan 15 02:58:12 2019

Web Locks: Prevent null-dereference crash when context is gone

C/o ClusterFuzz, methods on the LockManager can still be called when
it's ExecutionContext reference (via ContextLifecycleObserver) is
gone. Bail early in such cases.

Bug:  921363 
Change-Id: Ia9229a394ef674946793bea4ec044960f08449fc
Reviewed-on: https://chromium-review.googlesource.com/c/1409967
Commit-Queue: Joshua Bell <jsbell@chromium.org>
Reviewed-by: Victor Costan <pwnall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#622697}
[modify] https://crrev.com/03e547cdfd97c659bfe915a38e104ed8dd518bf7/third_party/blink/renderer/modules/locks/lock_manager.cc

ClusterFuzz has detected this issue as fixed in range 622695:622699.

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

Fuzzer: lcamtuf_cross_fuzz
Job Type: linux_ubsan_vptr_chrome
Platform Id: linux

Crash Type: Null-dereference READ
Crash Address: 0x000000000000
Crash State:
  blink::LockManager::LockRequestImpl::LockRequestImpl
  blink::LockManager::LockRequestImpl* blink::MakeGarbageCollected<blink::LockMana
  blink::LockManager::request
  
Sanitizer: undefined (UBSAN)

Regressed: https://clusterfuzz.com/revisions?job=linux_ubsan_vptr_chrome&range=617276:617277
Fixed: https://clusterfuzz.com/revisions?job=linux_ubsan_vptr_chrome&range=622695:622699

Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=5675552572440576

See https://github.com/google/clusterfuzz-tools for instructions to reproduce this bug locally.

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

ClusterFuzz testcase 5675552572440576 is verified as fixed, so closing issue as verified.

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