Open Bug 1221889 Opened 4 years ago Updated 2 years ago
"ASSERTION: Incorrectly ignoring blocking!": Audio
Node creation should fail after Audio Context .close()
###!!! ASSERTION: Incorrectly ignoring blocking!: 'mStartBlocking == GraphImpl()->mStateComputedTime || aTime <= mStartBlocking', file dom/media/MediaStreamGraph.cpp, line 1675
Looks like the stack is from a different thread to the assertion. Perhaps SIGTRAP is sent to the process rather than the thread?
Karl -- Are you ok with taking this since it looks like this is a regression from one of your checkins? And is this bug important enough that we need to fix it and uplift the fix (since Fx44 is affected)? Thanks.
This assertion was triggered by https://hg.mozilla.org/integration/mozilla-inbound/rev/13e85dc6b41b but I think the core problem existed before then: 'a call to close() will cause a transition to "closed".' closed means "Attempts to create new Nodes on the AudioContext will throw InvalidStateError." FWIW, the DestinationNode's stream is suspended but the OscillatorNode's stream is not, but the OscillatorNode should not even exist with this testcase. (In reply to Maire Reavy [:mreavy] (Plz needinfo me) from comment #4) > Is this bug important enough that we need to > fix it and uplift the fix (since Fx44 is affected)? We should still fix this by throwing the InvalidStateError on attempt to create the node, so that we don't ignore any similar assertion failures. However, there is no evidence here of anything that needs to be fixed in a hurry or uplifted, as the assertion is failing in a situation that the spec prohibits.
Priority: -- → P2
Summary: "ASSERTION: Incorrectly ignoring blocking!" → "ASSERTION: Incorrectly ignoring blocking!": AudioNode creation should fail after AudioContext.close()
Mass change P2->P3 to align with new Mozilla triage process.
Priority: P2 → P3
You need to log in before you can comment on or make changes to this bug.