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

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

Unable to provide possible suspect using Predator, CL and Code Search.
Could someone please look into the issue.
Thank You.

Could someone from "Blink>Layout" team take a look?

This is on the storage team, despite the name LayoutTestMessageFilter has nothing to do with layout.

https://chromium.googlesource.com/chromium/src/+/4a89010ed41a2838acd43bc88db7f0d0a3361315 (in the regression range) changes URLRequestContext destruction behavior in content_shell, and the null pointer dereference seems to be a URLRequestContext... morlovich@: does that seem like it could have caused this?

Maybe... any suggestions on how to reproduce? Just running content_shell --run-layout-test on the testcase (on Linux + ASAN) doesn't seem enough.

ClusterFuzz has detected this issue as fixed in range 510099:510116.

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

Fuzzer: mbarbella_js_mutation_layout
Job Type: windows_syzyasan_content_shell
Platform Id: windows

Crash Type: Null-dereference
Crash Address: 0x0000002f
Crash State:
  content::LayoutTestMessageFilter::OnDeleteAllCookies
  content::LayoutTestMessageFilter::OnMessageReceived
  content::BrowserMessageFilter::Internal::OnMessageReceived
  
Memory Tool: SYZYASAN

Regressed: https://clusterfuzz.com/revisions?job=windows_syzyasan_content_shell&range=497236:497300
Fixed: https://clusterfuzz.com/revisions?job=windows_syzyasan_content_shell&range=510099:510116

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

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

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

I am skeptical, since I suspect it wasn't really reproducible consistently in the first place, and nothing in the change range looks like it affected the timing of where the browsers may get the Delete-all-cookies RPC.

Given the minimized test case, I'm betting the script is hitting OOM in v8 and it's a latent race during shutdown.

Call chain for sending the IPC is TestRunner::Reset() ->  BlinkTestRunner::DeleteAllCookies() 

I think we can just defend against nullptr in  LayoutTestMessageFilter::OnDeleteAllCookies() (per https://cs.chromium.org/chromium/src/net/url_request/url_request_context_getter.h?type=cs&sq=package:chromium&l=29 "Once NotifyContextShuttingDown() is invoked, must always return nullptr.") and call it a day.

I'll put a CL up.

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

commit a2f50073f3da34a41b762b82ad2561bd15c7619c
Author: Joshua Bell <jsbell@chromium.org>
Date: Fri Oct 27 16:18:26 2017

content_shell: Speculative fix for crash during shutdown

Clusterfuzz noticed a flaky crash during layout tests. From code
inspection, it looks like a latent race at shutdown, but we can't
reproduce it. Speculative fix to not dereference a nullptr, which
could happen if the URLRequestContext is shut down before a "Delete
All Cookies" IPC message comes into the layout test message filter.

The change only affects content_shell when running layout tests; there
is no behavior change for the browser itself.

Bug:  774893 
Change-Id: Id4913cecb322e2ed11c8508f2b0e062c7a3cd1ba
Reviewed-on: https://chromium-review.googlesource.com/739231
Reviewed-by: Mike West <mkwst@chromium.org>
Commit-Queue: Joshua Bell <jsbell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#512195}
[modify] https://crrev.com/a2f50073f3da34a41b762b82ad2561bd15c7619c/content/shell/browser/layout_test/layout_test_message_filter.cc

Speculative fix landed. We'll see if clusterfuzz spots this again.