Through code search on file DocumentLoader.cpp, suspected CL is
https://chromium.googlesource.com/chromium/src/+/f936f423177349c1840be6e9b83114a844e74fa8%5E%21/third_party/WebKit/Source/core/loader/DocumentLoader.cpp
andypaicu@, could you please take a look?
Thank you.

Managed to reproduce with and without my CL in so I'm afraid it's not my CL that's causing the issue. Any call to DomWindow() seems to trigger the crash at that point.

Assigning back for further investigation.

Long shot: could this be related to changes to script loader?

Range from clusterfuzz: https://chromium.googlesource.com/chromium/src/+log/8f71139f8c5982d83fcdcc840a5275698b71438c..e78f7c1cc5587c0a09ca68b9519a45b1c3238ece?pretty=fuller

> Long shot: could this be related to changes to script loader?
No. My change to ScriptLoader at r464494 has been already reverted at r464768 (and not yet relanded), but clusterfuzz reports a crash at r465901.

tkent@, do you have any inputs here? seems lime you worked on similar issue (crbug/693807) before?

Thank you!

manoranjanr@,
This issue isn't similar to Issue 693807, and has a correct component.  Please wait until Blink>Loader triage.

cool, thanks for confirming!

That regression range looks completely bogus. I'd be surprised if this isn't a long-standing crash.

This involves listening to onunload on a same-origin child frame, taking advantage of the fact that we only suppress navigations in the frame running onunload. The event handler then synchronously detaches the world by navigating the main frame to about:blank, leaving the javascript url navigation in an inconsistent state.

Dropping priority slightly since this should be pretty rare in practice.

ClusterFuzz has detected this issue as fixed in range 474427:474462.

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

Fuzzer: inferno_layout_test_unmodified
Job Type: windows_asan_chrome
Platform Id: windows

Crash Type: Null-dereference READ
Crash Address: 0x0000001c
Crash State:
  blink::LocalFrame::DomWindow
  blink::LocalFrame::GetDocument
  blink::DocumentLoader::InstallNewDocument
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=windows_asan_chrome&range=464127:464504
Fixed: https://clusterfuzz.com/revisions?job=windows_asan_chrome&range=474427:474462

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


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 4851211359748096 is verified as fixed, so closing issue.

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