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/+/9e8e835a39287fceb827495ce7edd144df89030c (prerender: increase timeout for Asan).

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.

Hmm, I wonder if there have been some changes to something the share cache does.
See also bug 840916

share -> shader

ClusterFuzz has detected this issue as fixed in range 561364:561365.

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

Fuzzer: inferno_webbot
Job Type: linux_asan_chrome_mp
Platform Id: linux

Crash Type: Bus
Crash Address: 0x7f6abbdda65c
Crash State:
  disk_cache::BackendImpl::CreateEntryImpl
  disk_cache::BackendImpl::SyncCreateEntry
  disk_cache::BackendIO::ExecuteBackendOperation
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=linux_asan_chrome_mp&range=531200:531201
Fixed: https://clusterfuzz.com/revisions?job=linux_asan_chrome_mp&range=561364:561365

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

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

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

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

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

Assuming Predator is right at pinpointing the culprit change, then:

Increasing kTimeToLiveMinutes in c/b/prerender leads to more EntryImpl::Flush() returning false. To me this sounds like whatever happened to pnacl/shader cache recently is not relevant to this crash.

Chrome probably should not crash with "Failed to save user data", but if we remove the LOG(ERROR), the consequences for blockfile state may be even worse. Seems likely that the cache will get corrupt on the next browser start, or we'd hit a heap corruption as in issue 840916.

It is unlikely that we'd fix this internal blockfile cache problem, hence suggesting to switch shader/pnacl cache to simplecache. On the other hand, we do not intend to increase the time-to-live again, so this can wait.

morlovich: WDYT?