This bug was filed from the Socorro interface and is report bp-22b0f43e-cdcf-4aec-b8dc-7a1eb2130625 . ============================================================= This bug was filed from the Socorro interface and is report bp-22b0f43e-cdcf-4aec-b8dc-7a1eb2130625 . ============================================================= This seems to be some sort of buffer overflow in the code responsible for decoding audio. Disabling audio in my test case causes the crash to go away; it's 100% reproducible with audio turned on. I think it's crashing when I hand Web Audio a MP3 to decode. I'm going to try and get an isolated repro case but it's kind of a pain to do at the moment.

I can reproduce this against the commit that contained whatever bug demonstrates it, but once I put the test case on a public web server and it's downloading files over the internet, the bug stops appearing. I can't figure out why it's intermittent. What can I do about this?

OK, think I got it to reproduce against my server. Not sure what the problem was. For me every time I hit the test URL in Nightly, it crashes with the error when the progress bar reaches around 1200KB. It may only fail on a fast connection or when the assets are cached - it seems to not fail when it loads slowly.

We should test this in an ASAN build.

Hmmm... using that URL, I can't seem to get a crash on Win7 with nightly 24. The page loads until it reaches 15959kb, and then stops loading. However, no crash. I've tried this also on Mac using an ASan build, nightly FF24, no issues there either. I also tried several combinations of cached/not cached as well as throttled download with an HTTP proxy to see if that affected it. Nothing so far. Happy to keep trying, but not getting anywhere at the moment.

I think there's probably a race here involving XHR and/or Web Audio, since it's crashing in the web audio stack and the crash goes away if I disable sound in the demo. Not sure what I can do to make it more reliable. Maybe you can send me an ASAN build?

Could very well be the case. Only issue is that we only provide ASan builds for Linux: ftp://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-linux64-dbg-asan/ But either way, ASan build or not, we'd love to reproduce this crash.

Would a full memory dump of a crashed process be more useful?

Stacks are nice, but if it is really a crash, it has to be fixed. Last time I checked, I could repro this one.

(In reply to Paul Adenot (:padenot) from comment #8) > Last time I checked, I could repro this one. "Tag--you're it" then. Best case we're incorporating random memory into the stream and potentially leaking private data so I'm calling this at least sec-high. worst case we are equally messed up about the location or size of the destination buffer.

Kevin, I can't repro this one, I've got the same results as comment 4. Does it still work for you?

I just opened the test page in Nightly 25.0a1 (2013-07-10) and it crashed immediately. 25.0a1 (2013-07-11) crashed too. 25.0a1 (2013-07-14) also crashed.

Ha, I could repro. This is very likely to be a dupe of bug 891986, that I can't fix without some GC/CC plumbing. I'm not sure I can write the patch in a reasonable time myself, but I have not tried yet.

Bug 891986 now has a good patch which has not landed yet. We need to retest once it lands.

I tested several times with a build that has the patch mentioned in comment 13, it does not crash anymore, and it was crashing every time before.

The explanation (decodeAudioBuffer buffers not surviving GC) sounds correct to me based on the nature of the crash and the things the test case's code does, so sounds good. Thanks for tracking it down!