Predator and CL could not provide any possible suspects.
Using Code Search for the file, "bpf_gpu_policy_linux.cc" assigning to the concern owner.

Suspecting Commit#
https://chromium.googlesource.com/chromium/src/+/ce020ebf0ea534d9ea726ab50d370d81a7dd7b1d

@hajimehoshi -- Could you please look into the issue, kindly re-assign if this is not related to your changes.
Thank You.

The reproducer testcase seems empty...

Testcase 5160687105212416 is a top crash on ClusterFuzz for linux platform. Please prioritize fixing this crash.

Marking this crash as a Stable release blocker.

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

I have no idea why my CL caused the crash...

rsesek@, can you take a look?

This issue is marked as a release blocker with no milestone associated. Please add an appropriate milestone.

All release blocking issues should have milestones associated to it, so that the issue can tracked and the fixes can be pushed promptly.

Thanks for your time! To disable nags, add the Disable-Nags label.

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

Over to Greg since this is zygote-related.

[19082:19112:0807/061049.847205:ERROR:zygote_communication_linux.cc(146)] Did not receive ping from zygote child
[3:3:0807/061049.847627:ERROR:zygote_linux.cc(627)] Zygote could not fork: process_type renderer numfds 6 child_pid -1

That suspect CL removed system calls from the seccomp policy, right? If a child process is crashing because of a seccomp failure, that could cause this problem.

No, it moved __NR_mincore from a process-type specific policy to the baseline policy, so it only expanded the allowed set for some process types.

I think there's a failure to fork but it's not clear as to why.

Thanks for the clarification Robert. I also re-read the original report and I see that it actually failed to bisect this, so it just assigned it to anyone who touched a file in the backtrace. So that CL may not even be related. 

Cluserfuzz appears to have a reproducible test case, so I'll reproduce this once other high priority tasks are resolved. This is an m-63 beta blocker and that goes to beta on October 26th.

M-63 will be branched in ~2 weeks time and would be good to have this Beta blocker resolved before branch point.

Automatically applying components based on information from OWNERS files. If this seems incorrect, please apply the Test-Predator-Wrong-Components label.

Friendly ping to get an update on this issue as M-63 will be branched in ~2 weeks time and would be good to have this Beta blocker resolved before branch point.

Thanks..!

I tried to reproduce this locally and clusterfuzz cannot reproduce this either.

It even says, "Will be auto-closed on 10/18/2017 if flaky crash no longer seen"

Should this really be a ReleaseBlock-Beta then?

No, I don't think so.

Possible dupe of  bug 776359  based on "process_type renderer numfds 6 child_pid -1".  If clusterfuzz is no longer able to reproduce the issue, the bug is probably fixed.

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

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