This issue looks similar to bug 760938, hence assigning to the same dev for more updates.

hbos@ Could you please take a look in to this issue?

Thanks!

The GC destroying the audio track causes it to end, which fires an event, this revives the track (an event carries a reference to the object of which the event was fired on).
I'm not sure if we should suppress the firing of the event or if we should make sure the track cannot be GC'd in the first place.

Probably if the track can be GC'd without being ended there is a bug. Need to check if it goes ended -> ended or if it actually changes state.
Also not sure if this is ended or muted event, but same reasoning.

	[2064:775:0611/120228.854663:FATAL:vector.h(1651)] Check failed: !Allocator::IsObjectResurrectionForbidden().
0   Chromium Framework                  0x000000011b94159e base::debug::StackTrace::StackTrace(unsigned long) + 46
1   Chromium Framework                  0x000000011b722419 logging::LogMessage::~LogMessage() + 761
2   Chromium Framework                  0x0000000127f07352 WTF::Vector<blink::Member<blink::Event>, 0ul, blink::HeapAllocator>::ReserveCapacity(unsigned long) + 674
3   Chromium Framework                  0x0000000127f06f6d void WTF::Vector<blink::Member<blink::Event>, 0ul, blink::HeapAllocator>::AppendSlowCase<blink::Event*&>(blink::Event*&&&) + 141
4   Chromium Framework                  0x000000012b48e926 blink::MediaStream::ScheduleDispatchEvent(blink::Event*) + 678
5   Chromium Framework                  0x000000012b49f558 blink::MediaStreamTrack::PropagateTrackEnded() + 760
6   Chromium Framework                  0x00000001270c17c9 blink::MediaStreamSource::SetReadyState(blink::MediaStreamSource::ReadyState) + 585
7   Chromium Framework                  0x000000012c2debcd content::MediaStreamSource::FinalizeStopSource() + 477
8   Chromium Framework                  0x000000012c2a098e content::MediaStreamAudioTrack::StopAndNotify(base::OnceCallback<void ()>) + 366
9   Chromium Framework                  0x000000012c29f056 content::MediaStreamAudioTrack::~MediaStreamAudioTrack() + 246
10  Chromium Framework                  0x000000012c29f33d content::MediaStreamAudioTrack::~MediaStreamAudioTrack() + 29
11  Chromium Framework                  0x0000000126c3db3d blink::(anonymous namespace)::TrackDataContainer::~TrackDataContainer() + 157
12  Chromium Framework                  0x00000001270bbaa3 blink::MediaStreamComponent::InvokePreFinalizer(void*) + 275
13  Chromium Framework                  0x0000000119fa7184 blink::ThreadState::InvokePreFinalizers() + 1220
14  Chromium Framework                  0x0000000119fa69a3 blink::ThreadState::AtomicPauseEpilogue(blink::BlinkGC::MarkingType, blink::BlinkGC::SweepingType) + 371
15  Chromium Framework                  0x0000000119faa442 blink::ThreadState::RunAtomicPause(blink::BlinkGC::StackState, blink::BlinkGC::MarkingType, blink::BlinkGC::SweepingType, blink::BlinkGC::GCReason) + 1282
16  Chromium Framework                  0x0000000119f9aab5 blink::ThreadState::CollectGarbage(blink::BlinkGC::StackState, blink::BlinkGC::MarkingType, blink::BlinkGC::SweepingType, blink::BlinkGC::GCReason) + 1013

ended -> ended shouldn't fire an event (if the spec says that it should, the spec is wrong).

It seems wrong for GC to cause an event to fire, given general concerns about observability of GC. But I could be convinced that this is OK.

It's not OK because if the event fires a reference would be exposed to the application (events contain a target reference or whatnot) to an object no longer alive.

Either the GC should not cause a state change or the GC may end the track but the event be suppressed. Based on prior discussion about having to explicitly call stop() on a track, I would think GC is not allowed to happen unless the track is already in a permanent ended and muted state, with no event firing guaranteed.

You could prevent the GC from happening in the first place by adding a precondition for GC, but in this case it is the very act of GCing that triggers the track to end, by the looks of the stack trace.

ClusterFuzz testcase 6141214391533568 appears to be flaky, updating reproducibility label.

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

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