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 adding ccs based on suspected regression changelists:

Make browser UI to use OOPR as well when OOPR is enabled. by penghuang@chromium.org - https://chromium.googlesource.com/chromium/src/+/392cff8628eed1ce42f41362d2328f60768e2ce5

Track layout jank score in PageTimingMetricsSender. by skobes@chromium.org - https://chromium.googlesource.com/chromium/src/+/9f9b8e7ecb85b9be04920f5cfd195744e7e56dd5

If this is incorrect, please let us know why and apply the Test-Predator-Wrong-CLs label.

Looks like using OOPR for browser UI exposed some crash in SendSerializedData.

I cannot make this repro on mac (same gn flags, asan flags, chrome flags).  Moreover, I do not see any way this could happen.

This is a null pointer crash in a std::set (with the T being primitives).  The set is stored on an object on the stack (higher up in the callstack), so it seems bizarre that this could go awry.  It's not a use after free or use of stack memory after it's gone out of scope, or asan would have groused about that too.

ClusterFuzz has detected this issue as fixed in range 611973:611983.

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

Fuzzer: marty_html_twiddler
Job Type: mac_asan_chrome
Platform Id: mac

Crash Type: Null-dereference READ
Crash Address: 0x000000000000
Crash State:
  gpu::raster::RasterImplementation::RasterCHROMIUM
  cc::GpuRasterBufferProvider::PlaybackOnWorkerThreadInternal
  cc::GpuRasterBufferProvider::RasterBufferImpl::Playback
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=mac_asan_chrome&range=603104:603123
Fixed: https://clusterfuzz.com/revisions?job=mac_asan_chrome&range=611973:611983

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

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

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

Likely fixed by https://chromium.googlesource.com/chromium/src/+/193eda157bdb1c66d9afdc9c54a36e0ccc249293

The crash is in the destruction of a set in TransferCacheSerializeHelper. Its very odd that a purely GPU service side change (CCPR) would impact this serialization code. But looking at the fixed revision range, none of them look related.

No, I'm equally confused, but simultaneously the range of changes where it's fixed is quite small and there's not anything else even remotely relevant.

The only other thing is that this is one that only ever repro'd on the bots, and so maybe there's just some memory stomp or weird thing going on that just happens to not be hit any more.