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

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

Null reads are not P1.

Unable to find actual suspect through code search and also observing no CL's under regression range, hence adding appropriate label and requesting someone from dev team to look in to this issue.

Thanks!

Regression range actually includes 2 gpu related changes:
https://chromium.googlesource.com/chromium/src/+log/006301baa4d770675e7c814d96c8a8b01facbb7a..aefa586e7c8a20173fac5a4b8dfa301f8460e852?pretty=fuller&n=10000

one to cc, one to ui::Gpu. +kylechar in case you have any input (but I'm taking a look at this right now).

Interesting that this came up at the same time as  issue 859400 . They're not obviously related, but they're in the same function.

 Issue 859458 , reported by clusterfuzz around the same time, looks very closely related.

oops, applied label to the wrong issue

Wasn't able to repro on an ASAN build at ToT (1d287ca4c7ca), un-starting until I can look at this further

unable to reproduce even with clusterfuzz reproduce 5560706058158080, on the revision it checked out for me (9e7eeb2beef9)

ClusterFuzz testcase 5560706058158080 appears to be flaky, updating reproducibility label.

 Issue 866804  has been merged into this issue.

 Issue 807612  has been merged into this issue.

Apparently not Linux-specific according to  issue 807612 .

 Issue 859458  has been merged into this issue.

ClusterFuzz testcase 5875816496627712 is verified as fixed, so closing issue as verified.

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

I was able to find this crash in the wild as well:
https://crash.corp.google.com/browse?q=expanded_custom_data.ChromeCrashProto.magic_signature_1.name%3D%27blink%3A%3AWebGLRenderingContextBase%3A%3AValidateTexImageSubRectangle%3Cblink%3A%3AImage%3E%27

We're seeing about 30 crashes per day (it seems to have somehow gone down from 60 to 40 to 30 over time).

I'm currently operating under the assumption that `image` is null, but I don't know for sure yet - it could also be some other issue when dispatching the virtual call to Size(). I have a CL to handle null image ( https://crrev.com/c/1150373 ), which I believe to be legitimately possible:

I've been able to find only one function where I would suspect `image` could become null: CanvasRenderingContextHost::CreateTransparentImage
  https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/html/canvas/canvas_rendering_context_host.cc?l=20&rcl=549c9afb39d321f100c6c563aa5d1003842cbed9
either:
  if (!IsValidImageSize(size))
    return nullptr;
which could happen if the canvas somehow became too big or too small. (At this point, however, it should be known not to be too small - HTMLCanvasElement::Snapshot checks this).
or:
  if (!surface)
    return nullptr;
which - seems more likely - looks like it would happen if CreateTransparentImage failed due to OOM.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8b6e95bed08428af3b34194352d49fa8cf3ffaa9

commit 8b6e95bed08428af3b34194352d49fa8cf3ffaa9
Author: Kai Ninomiya <kainino@chromium.org>
Date: Thu Jul 26 23:51:08 2018

Handle null image in ValidateTexImageSubRectangle

This function assumes `image` will be a valid pointer, but previously we only DCHECKed this.
Meanwhile, we've seen intermittent fuzzer reports (all duped into this main bug),
and I was able to find some crash/ reports in the wild, that indicate that
image may actually come out false.

See  http://crbug.com/859623#c21  for investigation into why this would happen.

Bug:  859623 
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel
Change-Id: I7218c279400f2e062e271527b3c3b501bdf3856f
Reviewed-on: https://chromium-review.googlesource.com/1150373
Commit-Queue: Kai Ninomiya <kainino@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#578486}
[modify] https://crrev.com/8b6e95bed08428af3b34194352d49fa8cf3ffaa9/third_party/blink/renderer/modules/webgl/webgl_rendering_context_base.h

Pretty sure this is fixed. If it flakes again on any of the fuzzers, we will probably get a report about it.

Marking a NextAction just to take a look later and see if the crash/ frequency has gone down.

The NextAction date has arrived: 2018-11-01