This is a serious security regression. If you are not able to fix this quickly, please revert the change that introduced it.

If this doesn't affect a release branch, or has not been properly classified for severity, please update the Security_Impact or Security_Severity labels, and remove the ReleaseBlock label. To disable this altogether, apply ReleaseBlock-NA.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

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/+/18afd13d94183587e05cb04031f2ee7d56ba98d9 (gpu fuzzers: AddRef on null pointers).

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

I suspect this is like  crbug.com/778918 , but more subtle because __GLsync is a fake type provided by the GL header (https://cs.chromium.org/chromium/src/third_party/khronos/GLES3/gl3.h?type=cs&sq=package:chromium&l=68) for c-level type safety. There's no real type behind it really to export.
I want to double-check assumptions here, but I think we'll definitely have to suppress this (and likely a few others).

I guess we'll see more of this. Do you want to suppress all "function" errors from third_party/angle/src/?

This one would be in ui/gl/gl_bindings_autogen_gl.cc (chromium code calling into ANGLE, instead of the opposite). I think we may be able to scope the suppression to that file.
But I would like to double-check first, because I'm a bit surprised this is the first (only?) one we run into. If this is a generalized issue, I'd expect some egl functions, being called earlier, to fail too.

Nothing else pops up when running over existing corpus. Should I update the suppressions, i.e. add "function:ui/gl/gl_bindings_autogen_gl.cc"?

Maybe let's do that for now, I'll investigate separately.

The following revision refers to this bug:
  https://chrome-internal.googlesource.com/chrome/tools/clusterfuzz/+/f3efe00111444237cf6a5a4274d0ef1e88a93b61

commit f3efe00111444237cf6a5a4274d0ef1e88a93b61
Author: Max Moroz <mmoroz@google.com>
Date: Fri Nov 03 18:28:03 2017

Are these just popping up now because of the newly landed suppressions?

Yes, previously we've been hitting  crbug.com/778918  before reaching this particular error.

OK cool, hopefully suppressing these will lead to some new reports of more potential hazards.

So, the good news is that if I add __attribute__((visibility("default"))) in all definitions of GLsync, this issue goes away, so this is confirmed not to be a security issue. The bad news is that it's in Khronos headers.... We could modify them locally (we have a bunch of different copies in third/party), and/or we could try to upstream. That said the suppression for this one is fairly scoped, so maybe we can just live with it.

ClusterFuzz testcase 4896947243843584 is flaky and no longer crashes, so closing issue.

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

ClusterFuzz testcase 4896947243843584 is flaky and no longer crashes, so closing issue.

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

This is expected, more detailed explanation: https://bugs.chromium.org/p/chromium/issues/detail?id=778918#c46

Reopening this in case you have further plans.