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!

hbos@, do you have any inputs here? Seems like it's related to: https://bugs.chromium.org/p/chromium/issues/detail?id=760938 ?

Thank you!

ObjectResurrectionForbidden is caused if a GC'd object is being "resurrected" after it is meant to be destroyed. This can, for example, happen if the destruction of an object causes an event to fire carrying a destroyed object's reference back to JavaScript. This prevents JavaScript from having access to pointers to destroyed objects.

This does not look related to https://crbug.com/760938. It's the same symptom, but that other bug is related to WebRTC code, with WebRTC-specific bugs causing a resurrection.

This is a similar type of bug in a completely different area of the code. I don't know anything about StyleSheetCollection. It should probably be reassigned to someone working with CSS stuff.

CCing owners for retriage.

This involves ScrollTimeline and WorkletAnimation.

Suspect https://chromium-review.googlesource.com/1237235

Looking at the stack trace I believe this is caused because during ScrollTimeline::DetachAnimation we are accessing Document.scrollingElement which is triggering a layout. 


Talking to smcgruer@, I think the correct fix is
to avoid accessing Document.scrollingElement during detachment instead we should keep a reference to that node during attachment and use the same node during detachment. This in fact will prevent some unexpected behavior when scrollingElement changed during a ScrollTimeline lifetime which in the current logic can cause our attach/detach scroll_source_ node to be different.

I will work on a patch to fix this.

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

commit 8a80e58373275bd278ff1eb16665ad58bba49e20
Author: Majid Valipour <majidvp@chromium.org>
Date: Wed Nov 21 20:01:48 2018

[scroll-timeline] only resolve scroll source at construction

Previously scroll source was resolved anytime it was accessed. However
this is problematic in two ways:
- The Document.scrollingElement can change so we could resolve to a different
  node if that happens. However Attach/Detach process expect the resolved node
  to be the same and violating this invariant can cause unexpected behavior.
- Resolution process can trigger layout which may not be allowed during
  detachment (see  issue 890143 )


This patch changes this behavior so that the scroll source is only resolved at
ScrollTimeline construction and the resolved node is used for the lifetime of
scroll timeline.

Bug:  890143 
Change-Id: I8a745385e22e2c0718a5f9cade763f5eb2174c83
Reviewed-on: https://chromium-review.googlesource.com/c/1342677
Reviewed-by: Stephen McGruer <smcgruer@chromium.org>
Commit-Queue: Majid Valipour <majidvp@chromium.org>
Cr-Commit-Position: refs/heads/master@{#610187}
[modify] https://crrev.com/8a80e58373275bd278ff1eb16665ad58bba49e20/third_party/blink/renderer/core/animation/scroll_timeline.cc
[modify] https://crrev.com/8a80e58373275bd278ff1eb16665ad58bba49e20/third_party/blink/renderer/core/animation/scroll_timeline.h
[modify] https://crrev.com/8a80e58373275bd278ff1eb16665ad58bba49e20/third_party/blink/renderer/core/animation/scroll_timeline_test.cc

ClusterFuzz has detected this issue as fixed in range 610130:610187.

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

Fuzzer: inferno_twister
Job Type: mac_asan_content_shell
Platform Id: mac

Crash Type: CHECK failure
Crash Address: 
Crash State:
  !Allocator::IsObjectResurrectionForbidden() in vector.h
  void WTF::Vector<blink::TraceWrapperMember<blink::StyleSheet>, 0u, blink::HeapAl
  blink::StyleSheetCollection::AppendSheetForList
  
Sanitizer: address (ASAN)

Regressed: https://clusterfuzz.com/revisions?job=mac_asan_content_shell&range=593278:593305
Fixed: https://clusterfuzz.com/revisions?job=mac_asan_content_shell&range=610130:610187

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

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

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