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/+/0d4eb8a5f8d99d365459af21442cbc7b8648cf66 (Mojo: Force crash when sending oversized messages).

If this is incorrect, please remove the owner and apply the Test-Predator-Wrong-CLs label.

This is an intentional CHECK failure to catch oversized IPC usage in production.

Looks like it's possible to induce oversized message construction for this SubmitCompositorFrame call: https://cs.chromium.org/chromium/src/components/viz/client/client_layer_tree_frame_sink.cc?rcl=fadc26de4635da9d31ef25cb01b63187650a2895&l=155

It's possible that we just need to tune clusterfuzz test cases if this isn't a reasonable outcome in production code, but I can't really tell one way or the other.

Over to fsamuel@ for viz triage. Could you or someone on the viz team please take a look?

To clarify, "oversized" in this context means > ~128 MiB.

Assigning to Wei who is looking at CompositorFrame transport.

I don't think there is technically anything to stop compositor frame at certain size. This is definitely unusual for size of compositor frame.

We might have an increase in compositor frame size after we add hittesting data? But I don't think that will cause this big an increase.

Checked w/ rjkroege@ who had a run of top 10k sites, and the biggest IPC was 85kB.

We probably want to limit the fuzzer since this is not a case we care about in real world. 

On the other hand maybe we should just kill the renderer when it tries to send compositor frame this big?

Considering messages invalid that are too large sgtm also.

ClusterFuzz has detected this issue as fixed in range 510178:510722.

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

Fuzzer: miaubiz_svg_fuzzer
Job Type: windows_asan_chrome_no_sandbox
Platform Id: windows

Crash Type: CHECK failure
Crash Address: 
Crash State:
  message->data_num_bytes() < GetConfiguration().max_message_num_bytes in node_cha
  mojo::edk::NodeChannel::WriteChannelMessage
  mojo::edk::NodeChannel::SendChannelMessage
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=windows_asan_chrome_no_sandbox&range=501840:501860
Fixed: https://clusterfuzz.com/revisions?job=windows_asan_chrome_no_sandbox&range=510178:510722

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

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

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

 Issue 779370  has been merged into this issue.

ClusterFuzz testcase 5502288792911872 is still reproducing on tip-of-tree build (trunk).

Please re-test your fix against this testcase and if the fix was incorrect or incomplete, please re-open the bug. Otherwise, ignore this notification and add ClusterFuzz-Wrong label.

Migrating from Internals>Viz to Internals>Services>Viz.

 Issue 783573  has been merged into this issue.

Should this be WontFix or is there potentially a real bug here that we could hit in production? It's hard for me to tell whether or not we're just hitting fuzzing conditions that can't be realized in production.