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

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

Seems font serialization related - over to khushalsagar@ to triage.

Seems like a legit bug. It could be that we're hitting the assert right above here in debug code: https://skia.googlesource.com/skia/+/a63cf8e80aa5eaade9bfb4c30662cec9157a4372/src/core/SkRemoteGlyphCache.cpp#296. I'll try to repro locally.

Couldn't repro this one either. And I tried with the build from the clusterfuzz report itself.

Initially I thought maybe we're hitting a case of SkGlyphCacheState being null here: https://skia.googlesource.com/skia/+/a63cf8e80aa5eaade9bfb4c30662cec9157a4372/src/core/SkRemoteGlyphCache.cpp#296, since it crashes on the first line in writePendingGlyphs. But its probably not that because the code is crashing in resizing the vector here: https://skia.googlesource.com/skia/+/a63cf8e80aa5eaade9bfb4c30662cec9157a4372/src/core/SkRemoteGlyphCache.cpp#105, well after we've de-referenced the SkGlyphCacheState here: https://skia.googlesource.com/skia/+/a63cf8e80aa5eaade9bfb4c30662cec9157a4372/src/core/SkRemoteGlyphCache.cpp#449.

I don't know how it could possibly crash in that resize. That serializer has already been used upstack by this point to write stuff in SkStrikeServer::writeStrikeData.
+herb in case I missed anything. Without a local repro, I'm not sure how to make progress on this one.

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

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

Fuzzer: inferno_twister_c
Job Type: mac_asan_chrome
Platform Id: mac

Crash Type: Null-dereference READ
Crash Address: 0x000000000000
Crash State:
  SkStrikeServer::writeStrikeData
  gpu::raster::ClientFontManager::Serialize
  gpu::raster::RasterImplementation::PaintOpSerializer::Serialize
  
Sanitizer: address (ASAN)

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

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

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

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

Looking at https://chromium.googlesource.com/chromium/src/+log/bd12215beec3be14c8b0b618ac48defbbb171d84..11d8aa546f713231379e9a60020db4a95e73f022?pretty=fuller&n=10000, the only relevant thing here is https://chromium.googlesource.com/chromium/src/+/193eda157bdb1c66d9afdc9c54a36e0ccc249293, which is disabling CCPR for OOPR.

Do we serialize different data depending on whether CCPR is on or not?

Hmmm, the only thing we send back from the GPU -> renderer that could affect fonts in my knowledge is these Settings (https://cs.chromium.org/chromium/src/third_party/skia/src/core/SkRemoteGlyphCache.h?l=55), which shouldn't be affected by whether CCPR is enabled or not.