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/+/1bb05e1810bb6117d6e091ceefe3b4ea17572971 (OOPIFs shouldn't invoke snap-to-min on PinchEnd.).

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.

So looking at this, it seems as if the aligned memory allocation is failing.

Presumably sizeof(void*) == 4 here, so it seems like we have a correct alignment value propagating through cc::ListContainerHelper::Allocate.

So I'm guessing the issue here is that the size of the allocation seems very large:

[1:9:0525/214304.159312:ERROR:aligned_memory.cc(38)] If you crashed here, your aligned allocation is incorrect: size=436207616, alignment=4

Is this expected?

+enne@ to get some cc perspective on this. (should we add someone from viz too, since this ultimately appears related to allocating a (list of?) viz::SolidColorDrawQuad?

+ enne@ for real this time ...

memalign is an aligned alloc.  That check can fail when it fails to allocate memory.  I agree with your guess that it's just too big.

It might be worth looking at why we have so many quads.  Is there a ridiculous scale? Maybe the solid color layer impl should take that into account when generating quads instead of just tiling at a particular size.

The scale is definitely ridiculous: the ClusterFuzz test case sets

zoom = 10000000044444535353444433333333333333333333333333333333333333333333333333333330000000

But I guess the question is partly why this traces back to my CL ... in theory not doing snap-to-min shouldn't be affected when the page scale is presumably 1.0 anyways.

But if this test is failing now, I wonder how it passed before?

ClusterFuzz has detected this issue as fixed in range 598855:598871.

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

Fuzzer: ochang_domfuzzer
Job Type: linux_asan_chrome_v8_arm
Platform Id: linux

Crash Type: CHECK failure
Crash Address: 
Crash State:
  false in aligned_memory.cc
  base::AlignedAlloc
  cc::ListContainerHelper::CharAllocator::AllocateNewList
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=linux_asan_chrome_v8_arm&range=523878:523927
Fixed: https://clusterfuzz.com/revisions?job=linux_asan_chrome_v8_arm&range=598855:598871

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

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

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