ASSERTION FAILED: m_finishedNodes.isEmpty() in AudioContext destructor

• Component: Web Audio
• Status: RESOLVED FIXED

[Chris Dumez]

Several webaudio tests sometimes hit the !m_finishedNodes.size() assertion in AudioContext destructor:
crash log for WebProcess (pid <unknown>):
STDOUT: <empty>
STDERR: ASSERTION FAILED: !m_finishedNodes.size()
STDERR: /home/buildslave-1/webkit-buildslave/efl-linux-64-debug-wk2/build/Source/WebCore/Modules/webaudio/AudioContext.cpp(198) : virtual WebCore::AudioContext::~AudioContext()
STDERR: 1   0x7f27f144c1b6 WebCore::AudioContext::~AudioContext()
STDERR: 2   0x7f27f1474430 WebCore::OfflineAudioContext::~OfflineAudioContext()
STDERR: 3   0x7f27f1474468 WebCore::OfflineAudioContext::~OfflineAudioContext()
STDERR: 4   0x7f27f144fbcc WTF::ThreadSafeRefCounted<WebCore::AudioContext>::deref()
STDERR: 5   0x7f27f24235a8 WebCore::JSAudioContext::releaseImpl()
STDERR: 6   0x7f27f2443370 WebCore::JSOfflineAudioContextOwner::finalize(JSC::Handle<JSC::Unknown>, void*)
STDERR: 7   0x7f27eb741ac9 JSC::WeakBlock::finalize(JSC::WeakImpl*)
STDERR: 8   0x7f27eb7414bf JSC::WeakBlock::sweep()
STDERR: 9   0x7f27eb7406b6 JSC::WeakSet::sweep()
STDERR: 10  0x7f27eb738965 JSC::MarkedBlock::sweep(JSC::MarkedBlock::SweepMode)
STDERR: 11  0x7f27eb73b2d3 JSC::Sweep::operator()(JSC::MarkedBlock*)
STDERR: 12  0x7f27eb73c5f5 void JSC::MarkedAllocator::forEachBlock<JSC::Sweep>(JSC::Sweep&)
STDERR: 13  0x7f27eb73c111 JSC::Sweep::ReturnType JSC::MarkedSpace::forEachBlock<JSC::Sweep>(JSC::Sweep&)
STDERR: 14  0x7f27eb73b93b JSC::Sweep::ReturnType JSC::MarkedSpace::forEachBlock<JSC::Sweep>()
STDERR: 15  0x7f27eb73a641 JSC::MarkedSpace::sweep()
STDERR: 16  0x7f27eb729b72 JSC::Heap::collect(JSC::Heap::SweepToggle)
STDERR: 17  0x7f27eb729889 JSC::Heap::collectAllGarbage()
STDERR: 18  0x7f27f233feac
STDERR: 19  0x7f27f233ffa2 WebCore::GCController::gcTimerFired(WebCore::Timer<WebCore::GCController>*)
STDERR: 20  0x7f27f2340232 WebCore::Timer<WebCore::GCController>::fired()
STDERR: 21  0x7f27f1daf1aa WebCore::ThreadTimers::sharedTimerFiredInternal()
STDERR: 22  0x7f27f1daf0cb WebCore::ThreadTimers::sharedTimerFired()
STDERR: 23  0x7f27f286f625
STDERR: 24  0x7f27ee7dd33e _ecore_timer_expired_call
STDERR: 25  0x7f27ee7dd50b _ecore_timer_expired_timers_call
STDERR: 26  0x7f27ee7da421
STDERR: 27  0x7f27ee7daab7 ecore_main_loop_begin
STDERR: 28  0x7f27f286dee7 WebCore::RunLoop::run()
STDERR: 29  0x7f27f6353a84 WebProcessMainEfl
STDERR: 30  0x400804 main
STDERR: 31  0x7f27f53a876d __libc_start_main

At least the following tests are affected:
  webaudio/audionode-connect-order.html
  webaudio/audiobuffersource.html

It does not look specific to EFL port.

[Sergio Villar Senin]

More affected tests:

* webaudio/audiobuffersource-loop-points.html
* webaudio/audionode-connect-order.html

[Alexey Proskuryakov]

This is still happening.

[Alexey Proskuryakov]

rdar://problem/24740153

[Ryan Haddad]

Marked webaudio/audionode-connect-order.html as flaky on mac-wk1 debug in https://trac.webkit.org/r203619

[Alexey Proskuryakov]

*** Bug 207915 has been marked as a duplicate of this bug. ***

[Alexey Proskuryakov]

*** Bug 208061 has been marked as a duplicate of this bug. ***

[Ryan Haddad]

We're still seeing this intermittently on bots + EWS with at least the following tests:
webaudio/audioparam-connect-audioratesignal.html
webaudio/audioparam-setValueAtTime.html

[Alexey Proskuryakov]

*** Bug 213375 has been marked as a duplicate of this bug. ***

[Hector Lopez]

webaudio/audioparam-connect-audioratesignal.html

This test is flaky crashing according to history on macOS Debug on bots and EWS. This is part of a larger group /webaudio that has been flaky crashing on EWS.

History:
https://results.webkit.org/?suite=layout-tests&test=webaudio%2Faudioparam-connect-audioratesignal.html&limit=50000&platform=mac&style=debug

Crash log:
https://ews-build.s3-us-west-2.amazonaws.com/macOS-Mojave-Debug-WK1-Tests-EWS/r405576-14837/webaudio/audioparam-connect-audioratesignal-crash-log.txt

[Alexey Proskuryakov]

*** Bug 216151 has been marked as a duplicate of this bug. ***

[Chris Dumez]

I am trying to reproduce. If anybody has a somewhat reliable way of reproducing, please let me know.

[Chris Dumez]

This assertion indicates that BaseAudioContext::derefFinishedSourceNodes() was not called before the BaseAudioContext Destructor. Normally, derefFinishedSourceNodes() gets called from BaseAudioContext::handlePostRenderTasks() at the end of each render quantum. However, BaseAudioContext::handlePostRenderTasks() only calls derefFinishedSourceNodes() if tryLock() succeeds. Therefore, in case of lock contention, it is possible we end up destroying the BaseAudioContext without derefFinishedSourceNodes() having been called at the end of the last rendering.

I think the right thing to do is to forcefully call derefFinishedSourceNodes() after the audio thread is gone and before the BaseAudioContext gets destroyed, likely in BaseAudioContext::uninitialize().

[Chris Dumez]

Created attachment 408343 [details]
Patch

[EWS]

Committed r266793: <https://trac.webkit.org/changeset/266793>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 408343 [details].

[Chris Dumez]

Only took me 8 years to fix this bug :o)