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 blink team to look in to this issue.

Thanks!

Not much info in the stack but it looks like we're recursing into FragmentData's destructor.

This looks to be the same as https://bugs.chromium.org/p/chromium/issues/detail?id=831444 but that one stopped by itself.

It would seem this (crash) would depend on fairly low-level things (i.e what ends up determining the actual stack frame size) - so probably more likely to happen on the builds the bots use than on regular release builds. IIRC/UC the number of fragments will be bounded, which ought to reduce the chance in even more. Nevertheless I uploaded a potential fix:

https://chromium-review.googlesource.com/c/chromium/src/+/1106378

although I never managed to repro (the build from the report wouldn't start...)

ClusterFuzz has detected this issue as fixed in range 582653:582655.

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

Fuzzer: bj_broddelwerk
Job Type: linux_msan_content_shell_drt
Platform Id: linux

Crash Type: Stack-overflow
Crash Address: 0x7ffcdcf91ff8
Crash State:
  std::__1::unique_ptr<blink::FragmentData, std::__1::default_delete<blink::Fragme
  
Sanitizer: memory (MSAN)

Regressed: https://clusterfuzz.com/revisions?job=linux_msan_content_shell_drt&range=560818:560820
Fixed: https://clusterfuzz.com/revisions?job=linux_msan_content_shell_drt&range=582653:582655

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

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

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