I just noticed that V8AudioContext::constructorCallback in V8AudioContextCustom.cpp leaks the pointer to AudioContext.
Shouldn't it also call V8DOMWrapper::setJSWrapperForActiveDOMObject to deref AudioContext in JS wrapper weak callback? Looks like currently all AudioContexts live forever.
I'll take a look.
There is another problem with this code. After fixing the leak, you'll get debug crash in AudioContext::uninitialize.
Here is why. ScriptExecutionContext::stopActiveDOMObjects is called twice on navigation, first time from Document::detach and then from FrameLoader. As a result AudioContext::stop is also called twice.
First AudioContext::uninitialize deletes the AudioContext object. Then AudioContext::uninitialize is called again, but AudioContext is already destructed.
Would this explain why we hit the exception "audio resources unavailable for AudioContext construction" so often? The 4 AudioContext limit gets exhausted even though at most one is currently active. I assumed there is no guarantee the unused ones will be garbage collected in any event.
As this is in V8*.cpp is this only in Chrome? Safari hits the same issue.
The AudioContext releases its resources in AudioContext::uninitialize(), not in the destructor, so delayed garbage collection is not likely to be the issue.
Michael, I'll have a look at your case...
I believe this was fixed in: