Bug 105870 - ASSERTION FAILED: m_finishedNodes.isEmpty() in AudioContext destructor
Summary: ASSERTION FAILED: m_finishedNodes.isEmpty() in AudioContext destructor
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Audio (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Chris Dumez
Keywords: InRadar
: 207915 208061 213375 216151 (view as bug list)
Depends on:
Blocks: 212611
  Show dependency treegraph
Reported: 2012-12-30 09:43 PST by Chris Dumez
Modified: 2020-09-09 15:54 PDT (History)
21 users (show)

See Also:

Patch (2.52 KB, patch)
2020-09-09 10:47 PDT, Chris Dumez
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Dumez 2012-12-30 09:43:22 PST
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:

It does not look specific to EFL port.
Comment 1 Sergio Villar Senin 2014-04-04 02:29:44 PDT
More affected tests:

* webaudio/audiobuffersource-loop-points.html
* webaudio/audionode-connect-order.html
Comment 2 Alexey Proskuryakov 2014-09-08 14:16:04 PDT
This is still happening.
Comment 3 Alexey Proskuryakov 2016-02-27 13:29:06 PST
Comment 4 Ryan Haddad 2016-07-22 15:09:07 PDT
Marked webaudio/audionode-connect-order.html as flaky on mac-wk1 debug in https://trac.webkit.org/r203619
Comment 5 Alexey Proskuryakov 2020-02-18 15:33:58 PST
*** Bug 207915 has been marked as a duplicate of this bug. ***
Comment 6 Alexey Proskuryakov 2020-02-22 17:48:37 PST
*** Bug 208061 has been marked as a duplicate of this bug. ***
Comment 7 Ryan Haddad 2020-04-28 16:25:35 PDT
We're still seeing this intermittently on bots + EWS with at least the following tests:
Comment 8 Alexey Proskuryakov 2020-06-19 17:19:38 PDT
*** Bug 213375 has been marked as a duplicate of this bug. ***
Comment 9 Hector Lopez 2020-07-30 15:04:10 PDT

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.


Crash log:
Comment 10 Alexey Proskuryakov 2020-09-04 10:00:43 PDT
*** Bug 216151 has been marked as a duplicate of this bug. ***
Comment 11 Chris Dumez 2020-09-09 09:02:59 PDT
I am trying to reproduce. If anybody has a somewhat reliable way of reproducing, please let me know.
Comment 12 Chris Dumez 2020-09-09 10:08:29 PDT
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().
Comment 13 Chris Dumez 2020-09-09 10:47:40 PDT
Created attachment 408343 [details]
Comment 14 EWS 2020-09-09 11:41:06 PDT
Committed r266793: <https://trac.webkit.org/changeset/266793>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 408343 [details].
Comment 15 Chris Dumez 2020-09-09 15:54:47 PDT
Only took me 8 years to fix this bug :o)