Unable to find possible suspect from find it and CL.
Assigning to concern owner using Code Search for the file, "child_thread_impl.cc".

Suspecting the following CL --
https://chromium.googlesource.com/chromium/src/+/b9ff6c9da80f39e37c8f44cd0f9d8749f0fa377f

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

The crash is not related to my CL. Not sure what may be responsible.

Testcase 5475886146256896 is a top crash on ClusterFuzz for mac platform. Please prioritize fixing this crash.

Marking this crash as a Beta release blocker.

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

Adding stability sheriff for further help as it is marked as beta blocker & no update from longtime.

Thanks..!

Stability sheriff's deputy here.

This bug doesn't look particularly actionable. This sort of crash signature has been happening for a fairly long time -- see e.g.  bug 665188  -- so unless there has been a demonstrable spike in its frequency on clusterfuzz systems, it might just be an old situation.

What's apparently going on here is that the pthread_create is failing, while we're in the middle of exiting due to a channel error. pthread_create can fail if we've hit the system thread limit (what is that on clusterfuzz systems?); it could also (maybe?) be an OOM. The thread is being created to let the process run for another minute before shutting things down, to give sanitizers a chance to detect bugs and such.

Because the shutdown is due to a channel error, if there's been a spike in channel errors, we might see a commensurate spike here.

As for causes, the only clue I see is that the test case includes a window.close() (it's pretty boring otherwise), which might trigger a less-common process exit ordering, which could plausibly lead to a channel error.

on the other hand, clusterfuzz claims this is reproduceable, and the test case is small. I just kicked off a re-run of the blame range.

It's also worth pointing out that this bug won't be reproduceable with a vanilla build of Chrome. The function in question only exists in ASAN builds.

It does seem like there's a spike in crashes observed by clusterfuzz. The spike seems to have started around Jan 29 @ 2 PM UTC: the rate goes from very infrequent to steadily dozens per hour.

This crash occurs very frequently on mac platform and is likely preventing the fuzzer attekett_dom_fuzzer from making much progress. Fixing this will allow more bugs to be found.

Marking this bug as a blocker for next Beta release.

If this is incorrect, please add ClusterFuzz-Wrong label and remove the ReleaseBlock-Beta label.

Friendly ping!
Nick@,
Could you please take a look and assign to the right owner as it is marked as Fuzz blocker & beta blocker issue.
Thanks in advance..!

Stability sheriff here -- in c#11 there was a re-run seeking blame range, is there an update on that?

Per C#11 this crash can only happen in ASAN builds (not user builds) so I don't think this should be a beta blocker.  I would suggest this code needs to be more robust to system resource exhaustion and fail gracefully instead of crashing.

The original author (earthdok@) of this code seems to no longer be contributing?

I don't know who would be a good owner... assigning to haraken@ as the owner of content/child for re-triage.

Also lowering priority and removing from sheriff queue.

Unable to provide possible suspect using Predator, CL and Code Search.
Could someone please look into the issue.

Thank You...

This bug has an owner, thus, it's been triaged. Changing status to "assigned".

ClusterFuzz has detected this issue as fixed in range 589552:589567.

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

Fuzzer: attekett_dom_fuzzer
Job Type: mac_asan_chrome
Platform Id: mac

Crash Type: CHECK failure
Crash Address: 
Crash State:
  CreateWaitAndExitThread(base::TimeDelta::FromSeconds(60)) in child_thread_impl.c
  content::SuicideOnChannelErrorFilter::OnChannelError
  IPC::ChannelProxy::Context::OnChannelError
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=mac_asan_chrome&range=338204:338244
Fixed: https://clusterfuzz.com/revisions?job=mac_asan_chrome&range=589552:589567

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

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

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