Predator and CL did not provide any possible suspects.
Using Code Search for the file, "LocalWindowProxy.cpp" assigning to concern owner from GIT Blame.

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

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

So this failure is a stack overflow failure... but there's something weird going on. The unload handler is getting invoked re-entrantly, which shouldn't happen...

I'll investigate more tomorrow.

OK, so this is because about:blank navigations are synchronous.

Since we try to synchronously navigate the main frame in the middle of the child frame's unload event, we re-enter the child's unload handler.

Wait, what? Shouldn't that be blocked? Well, yes... except Document::DispatchUnloadEvents() only skips event dispatch if load_event_progress > kUnloadEventInProgress [1]... and of course, we're in the middle of dispatching an unload event =(

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/dom/Document.cpp?rcl=a0d1c1531de988606c0425de933722358985374b&l=3281

Another thing to investigate tomorrow: why didn't the navigation blocker for unload events kick in here? Maybe it's not covering the sync load paths...

That's because the frame being navigated is not on the unload handler. It's the other frame that's inside the unload handler.

ย

ClusterFuzz has detected this issue as fixed in range 500819:500829.

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

Fuzzer: inferno_twister
Job Type: mac_asan_chrome
Platform Id: mac

Crash Type: CHECK failure
Crash Address: 
Crash State:
  !context.IsEmpty() in LocalWindowProxy.cpp
  blink::LocalWindowProxy::CreateContext
  blink::LocalWindowProxy::Initialize
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=mac_asan_chrome&range=435209:435261
Fixed: https://clusterfuzz.com/revisions?job=mac_asan_chrome&range=500819:500829

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

See https://github.com/google/clusterfuzz-tools 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 6134602271031296 is verified as fixed, so closing issue as verified.

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

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