Abrt in SkBitmap::allocN32Pixels |
||||||
Issue descriptionDetailed report: https://clusterfuzz.com/testcase?key=6061418326261760 Fuzzer: inferno_layout_test_unmodified Job Type: linux_asan_chrome_v8_arm Platform Id: linux Crash Type: Abrt Crash Address: 0x00000001 Crash State: SkBitmap::allocN32Pixels cc::PaintedScrollbarLayer::RasterizeScrollbarPart cc::PaintedScrollbarLayer::Update Sanitizer: address (ASAN) Regressed: https://clusterfuzz.com/revisions?job=linux_asan_chrome_v8_arm&range=588970:588971 Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=6061418326261760 Issue filed automatically. See https://github.com/google/clusterfuzz-tools for more information.
,
Sep 12
Automatically adding ccs based on suspected regression changelists: clean up S16CPU by mtklein@google.com - https://skia.googlesource.com/skia/+/5595f6ef0e87ff14e7995c055fc7728a54980e86 more skcolorspace cleanup by mtklein@google.com - https://skia.googlesource.com/skia/+/7af2bc88024fe9646841da9489845230e3b38345 Reland "Switch SkPaint's color to SkColor4f" by brianosman@google.com - https://skia.googlesource.com/skia/+/b0f4d0a6589fbb7b9d18d980f4520992e0fbe1ca If this is incorrect, please let us know why and apply the Test-Predator-Wrong-CLs label.
,
Sep 13
"clean up S16CPU" is a no-op for production code. The interesting changes were test only and a refactor. "more skcolorspace cleanup" repacks the fields of SkColorSpace, and shouldn't be able to cause a crash during bitmap allocation. "Reland "Switch SkPaint's color to SkColor4f"" again shouldn't be able to cause a crash during bitmap allocation. Is a message like "AddressSanitizer: ABRT on unknown address 0x00000001" telling us we called abort() or the equivalent? That's definitely something that can intentionally happen here when allocating a bitmap too large to be malloc()'d. Is there a way to bisect / re-triage this?
,
Sep 14
Running the testcase above in a stable build crashes reliably. It looks like it's trying to allocate a huge scrollbar and OOM'ing. It looks like enne@ tried to put a mitigation in place in https://chromium-review.googlesource.com/c/chromium/src/+/639236, but that's still crashing on Mac Canary as of 71.0.3552.2 (Official Build) canary (64-bit). enne@, could you sort this or reassign? Thanks!
,
Sep 17
I'll look at this, but I don't think it's a P1.
,
Sep 21
I think this is WontFix. If anybody sees this in practice, we can do something about it, but this page just loops forever continually adding things that have scrollbars. Right now the max scrollbar size is 8192x8192. Even if I cap it to be like 4096x256 or something, this test just loops until it fails an alloc...just later than it would have before. We could mitigate this eventually by just not crashing here and just not having a scrollbar, but nobody has ever complained in practice. I think failing an alloc here is fine. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by ClusterFuzz
, Sep 12Labels: Test-Predator-Auto-Components