969089 - Shutdown issue since bug 961996

Status: RESOLVED FIXED

(Core :: Web Audio, defect)

Description

[Paul Adenot (:padenot)]

Attachment: stacktrace-shutdown

I got shutdown errors when I run the content/media/webaudio test suite locally, so I bisected, and bug 961996 is the culprit.

Then, we leak everything that is related to Web Audio and we could possibly leak. Since that's a shutdown leak, that's okay, but still.

Stack trace with not a lot of symbols attached, hopefully it's enough.

Comment 1

[Karl Tomlinson (:karlt)]

I have been seeing some leaks sometimes, but hadn't noticed the assertion failure.

I wonder about changing the mForceShutDown check to !mRealtime RunInStableState() instead and adjusting the assertion appropriately.  I need to think about it.

It seems this is cleaned up eventually because running a larger testsuite doesn't show the leaks.  I'm not sure that changing the mForceShutDown check is fixing the root cause; it might be just making things clean up a little faster.

Still this is an annoying bug because it makes it hard to test patches for leaks.

Comment 2

[Paul Adenot (:padenot)]

I can repro 100% of the time, when running the full web audio test suite. It crashes after test_mediaDecode.html

Comment 3

[Karl Tomlinson (:karlt)]

(In reply to Paul Adenot (:padenot) from comment #2)
> I can repro 100% of the time, when running the full web audio test suite. It
> crashes after test_mediaDecode.html

Are you talking about he same issue here.  I thought this was just a shutdown assertion and leak, but you mention a crash before shutdown?

Comment 4

[Karl Tomlinson (:karlt)]

Attachment: allow an offline graph to shutdown before it's AudioDestinationNode is unlinked

A non-realtime graph does not start up again after finished processing, so it
can safely enter LIFECYCLE_WAITING_FOR_STREAM_DESTRUCTION.

There's probably a remaining issue to deal with offline graph thread destruction at application shutdown, which is perhaps is covered by bug 933730, but allowing the graph to clean up earlier is a sensible optimization anyway.

Comment 5

[Karl Tomlinson (:karlt)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/d0d427badc22

Comment 6

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/d0d427badc22