1047179 - High CPU usage and eventual OOM when playing ogg files from an HTML file from my file system

Status: RESOLVED INACTIVE

(Core :: Audio/Video: Playback, defect)

Description

[tieTYT]

Attachment: One of the 3 sounds that I can't play locally

User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0 (Beta/Release)
Build ID: 20140716183446

Steps to reproduce:

I have not been able to come up with a simple test case to reproduce this, but I can consistently reproduce it locally.  Here is the crash report: https://crash-stats.mozilla.com/report/index/016b0e1e-6f80-46f7-980b-fc6172140801

I'm playing 4 ogg files in my HTML 5 game.  Ever since I upgraded to 31.0, 3 of these 4 don't play, but only when I play my from my local file system.  If I play my game off of a server, they all play as expected.  They even play if I view the page from a server running locally.  So as far as I can tell, viewing the HTML with a "file://" url is somehow relevant.  All of these sounds play fine on Chrome under all scenarios described.

It's confusing to me that 1 of the 4 sounds plays fine and the problem only occurs if I play the game using the "file://" url. 

When these sounds fail to play, my CPU usage jumps from a typical 5-10% usage to a 50-70% usage and my memory jumps from a typical 400-600mb usage to a 2-3gb usage.  The memory seems to be garbage collecting quite a few times, Firefox stutters, and after about 5 minutes the browser will crash with the error report I linked above.

I'm using Howler.js http://goldfirestudios.com/blog/104/howler.js-Modern-Web-Audio-Javascript-Library to play my sounds.  I don't think it's directly related to this issue though because it works fine in Chrome and I started using Howler.js and playing sounds on July 8th, and I haven't noticed this issue until a few days ago.  I also haven't recently updated Howler.js until I started experiencing this issue.  When I updated to the latest Howler.js, it did not resolve this issue.

A workaround is to disable all sounds from playing by commenting out the line that calls Howler.js' play() function.  Of course that has the unwanted effect of not playing any sounds or music anymore.  

I tried running my game in safe mode and it didn't make a difference.

Normally I wouldn't create a bug report without being able to reproduce it with a simple test, but someone on the Firefox mailing list recommended I should.  

I'm attaching one of the 3 sounds I can't play just in case there's something special (in a bad way) about it.  


Actual results:

Only 1 of the 4 sounds plays, memory and CPU usage spike and if I play long enough, eventually the whole browser will crash with an OOM error.


Expected results:

I'd expect CPU usage to stay at 5-10% and memory to stay at 400-600mb.  Also, all 4 sounds should play.

Comment 1

[tieTYT]

Is it possible to edit my comment?  I couldn't figure out how.  I wanted to add this:

Something weird about this is that if I open dev tools and profile the application, the profiler gives me no indication of the problem.  It'll show me more than 50% idle even though Firefox was stuttering and using massive amounts of CPU/memory while I profiled.

Comment 2

[Panos Astithas (he/him) [:past] (please ni?)]

This seems related to the Ogg Vorbis media decoder.

Comment 3

[Codacoder]

Might be worth testing in Aurora/Nightly JIC?

Comment 4

[tieTYT]

I'll try the nightly after I research how I can get it and go back to 31.0 after I do.

Another update: I just tried on a Windows 7 computer and was able to reproduce the issue.  But still only for my game.  To me this means the problem isn't just a corrupted Windows dll on my system or something like that.

Comment 5

[tieTYT]

In my mind, that also rules out a corrupted Firefox profile.

Comment 6

[tieTYT]

I tried the nightly, it's a problem there, too.

Comment 7

[tieTYT]

I'm sorry for all this noise, I'd prefer to edit the last thing I said instead of post a new comment each time.  Is that an option?

Here's the strategy I plan to take to reproduce this:  I'm going to start from my game, branch it, and chop out parts of the code until I get to something minimal and easy to share.

Comment 8

[tieTYT]

Attachment: broken.zip

I whittled down my code to the minimum required to reproduce the issue and am attaching a zip.  Along the way I discovered that somehow, the location of the sound files is relevant.  When I tried to move all the JS and ogg files into the same folder, the problem didn't occur.

Comment 9

[tieTYT]

Ugh, forgot instructions.  Unzip this, then open sandbox.html in firefox (it's nested in there).  If you open task manager, you'll see that CPU and memory usage will quickly climb.

Comment 10

[Chris Pearce [:cpearce (Not reading bugmail)]]

It looks like pickup.ogg is being continually re-opened in tight loop, and play() is never actually called on any of the <audio> elements created. I'm guessing that there's some difference between the order of JavaScript events that fire in Chrome and Firefox that causes this behaviour... Can you minimize the testcase further?

Comment 11

[tieTYT]

I can, but I'm confused by your comment.  the Sound.js has a setInterval in it that is calling play() over and over again on pickup.ogg.  So why are you saying "play()" is never actually called on any of the <audio> elements?

Comment 12

[tieTYT]

Attachment: A Sound.js with even less code in it.

Comment 13

[Chris Pearce [:cpearce (Not reading bugmail)]]

(In reply to tieTYT from comment #11)
> I can, but I'm confused by your comment.  the Sound.js has a setInterval in
> it that is calling play() over and over again on pickup.ogg.  So why are you
> saying "play()" is never actually called on any of the <audio> elements?

I enabled logging and I didn't see evidence of play() being called in the logging. I also attached a debugger, and verified that HTMLMediaElement.play() wasn't called.

I'm not saying that you're not *trying* to call play(), I'm saying that something is causing it to not be called.

Comment 14

[tieTYT]

Oh, interesting.  Well, I'm not sure how to reduce the example further than I already have, any suggestions?

Comment 15

[Chris Pearce [:cpearce (Not reading bugmail)]]

Attachment: Test case with even lesser code in it

The testcase uses some sound library called Howler.js, and that is failing here, but only when the URL to the file to be played contains at least one ".." and if the file is local.

Howler.js is trying to do an XHR to the file, it's failing because the file is local and has a ".." in it, so Howler fallsback to using the URL as the @src attribute of an audio element, but when it goes to retrieve an audio element from its list of inactive elements, it re-triggers the load of the resource, resetting the process, and we get stuck in a loop. I dunno why Chrome doesn't yet, its XHR fails too and it starts down the same path we do. Maybe a readyState difference.

If the path doesn't contain a "..", it looks like the XHr to a local file is succeeding, and we're taking a WebAudio path that is working (though audio crackles).

Anyway, here's a slightly more reduced testcase, with an un-minified Howler.js and without all the other stuff from Vendor.js.

Comment 16

[tieTYT]

Attachment: If you use this, sounds WILL play correctly. Only difference is the sound I chose to play.

Nice! But I don't understand how 1 out of the original 4 sounds plays fine.  You can see this by taking my original broken.zip and having the Sound.js play the ../../../main/scripts/sound/sfx/one_shot.ogg file instead of the ../../../main/scripts/sound/sfx/pickup.ogg

I'll attach a new Sound.js that shows this.  

BTW, I'm not able to download your attachment.  It goes to a blank page.

Comment 17

[(Away)]

The OOM|small signature tends to attract a lot of me-toos for unrelated crashes, so I'm clearing the field.

Comment 18

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

Does this issue still occur?

Comment 19

[Nils Ohlmeier [:drno]]

Mass closing because of inactivity.
Please feel free to re-open if still relevant.