1. Install https://www.squarefree.com/extensions/domFuzzLite3.xpi 2. Set user_pref("media.webaudio.enabled", true); 3. Run under ASan 4. Load the testcase 5. Quit Firefox It's possible this is the same as bug 872394, but it's hard to know since that bug doesn't have a testcase.

Jesse, how can I reproduce this? I tried running the test case with the extension installed in an ASAN build but nothing was reported by ASAN.

I can reproduce on my Mac Mini but not on my MacBook Pro???

Maybe it's 10.7-only???

What does the ASAN report look like?

Yeah, I've fixed a number of bugs by just looking at the stacks from the ASAN report! :-)

Another question, is your ASAN build debug or optimized? I tried with a debug ASAN build.

I can only reproduce with my *non-debug* ASan build.

Works also with a debug / O1 build on MacOS 10.8 The stack for re-use is the same as in bug 872394 The test case attached here works for me reliable.

Christoph, since you can reproduce in an ASan debug build, can you attach an ASan log that includes all three stacks? (alloc, free, reuse)

alloc: obj-ff64-asan-opt/dom/bindings/AudioContextBinding.cpp:423 static bool createScriptProcessor(JSContext* cx, JSHandleObject obj, mozilla::dom::AudioContext* self, unsigned argc, JS::Value* vp) { [...] * result = self->CreateScriptProcessor(arg0, arg1, arg2, rv); [...] } free: content/media/webaudio/AudioNode.cpp:40 NS_IMETHODIMP_(nsrefcnt) AudioNode::Release() { if (mRefCnt.get() == 1) { // We are about to be deleted, disconnect the object from the graph before // the derived type is destroyed. DisconnectFromGraph(); } * nsrefcnt r = nsDOMEventTargetHelper::Release(); NS_LOG_RELEASE(this, r, "AudioNode"); return r; } re-use: /content/media/webaudio/AudioContext.cpp:439 void AudioContext::Shutdown() { [...] // Stop all script processor nodes, to make sure that they release // their self-references. nsTArray<ScriptProcessorNode*> spNodes; GetHashtableElements(mScriptProcessorNodes, spNodes); for (uint32_t i = 0; i < spNodes.Length(); ++i) { * spNodes[i]->Stop(); } [...] } and then content/media/webaudio/AudioNode.h:80 [...] void Drop(T* t) { if (mRefCnt > 0) { * --mRefCnt; if (mRefCnt == 0) { t->Release(); } } [...] Tested with m-i changeset: 132237:37b8fa6c1c92

Ok, this appears to be fixed in m-i changeset: 132521:0a830609f619 I can not reproduce it anymore.

Pardon, it is still reproducible with a few page reloads; have hit it also during the fuzzing process again.

Sigh, I bet this is the exact copy of bug 865550 only for ScriptProcessorNode. :(

Christoph confirmed on IRC that this fixes the bug, so I landed the patch: https://hg.mozilla.org/integration/mozilla-inbound/rev/0cec5ad76246

I did?

(In reply to Christoph Diehl [:cdiehl] from comment #17) > I did? No, decoder did, sorry!

I believe the underlying problem is not fixed here. Tested with m-i changeset: 132549:7cb2f5c6ef8e

(In reply to Christoph Diehl [:cdiehl] from comment #19) > Created attachment 752741 [details] > callstack-after-patch-v1 > > I believe the underlying problem is not fixed here. > > Tested with m-i changeset: 132549:7cb2f5c6ef8e I can't reproduce this using an optimized ASAN build. Could you please give me some information on how I can repro?

It happened for me only one time after a long fuzzing run. Even though I called CC and GC explicitly in each testcase, none of the generated testcases was able to reproduce this particular crash.

Hmm, OK. Looking at the stack, I cannot imagine how this could be happening. But if it is happening, it's definitely a different bug. Please file a new bug if you can find a way to reproduce it. Thanks!

How far back does this need to be backported?

(In reply to Andrew McCreight [:mccr8] from comment #24) > How far back does this need to be backported? 23 and 24.

Well, 23. :-)

Mass moving Web Audio bugs to the Web Audio component. Filter on duckityduck.

No longer tracking for FF23

Pushed by eakhgari@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/a27f986b6507 Add a crashtest based on the test case for the bug