I made this testcase for bug 958796 to see if the changes there would reduce (virtual) memory usage. I found that it produces large amounts of heap-unclassified (67% after one run on a fresh profile), and reloading the page a bunch of times quickly crashes the browser on OOM. The memory isn't leaked - waiting a while makes it go back down, as does closing the tab. However it takes a few seconds before this happens, so holding down F5 to reload the page over and over again (or just pressing it a few times a second) is enough to OOM the browser in a few seconds. I don't really have any experience with html or JS, so this testcase might be pretty awful :) Still, I think it exposes some pretty bad behavior. Perhaps this is the same issue as bug 962986?

> Perhaps this is the same issue as bug 962986? Bug 960873 (and hence bug 961441) might also be relevant.

Emanuel, can you try the patches from bug 960873? It does sound very much like I saw in that bug. The current proposed patches should fix the issue for ogg/vorbis.

I applied the patches in a local build, but it didn't seem to make any difference: - Memory usage after loading the testcase was roughly the same - about:memory still showed 67% heap-unclassified - Quickly refreshing the page with the testcase still OOMed the browser

Here's the output of running DMD after the testcase has been loaded.

Here's the important part of the DMD output. It's obviously all Ogg Vorbis stuff. I don't know enough about the media memory reporters to understand why this memory isn't being measured.

Looks like a known issue that the libvorbis internals need a memory reporter. See bug 677653.

I am working towards architectural changes that will make it easier to be more aggressive in disposing of decoders that we think we won't need. This will help here.

(In reply to Chris Pearce (:cpearce) from comment #7) > I am working towards architectural changes that will make it easier to be > more aggressive in disposing of decoders that we think we won't need. This > will help here. Let's make this bug about doing that.

I am working on the dependencies of this now.

Some 4chan boards have enabled posting .webm files instead of images and the page's script can display them inline. Opening many of them results in large amounts of memory used as follows. ├──1,038.35 MB (43.39%) -- media │ ├──1,034.86 MB (43.25%) -- decoded │ │ ├──1,034.83 MB (43.25%) ── video I assume this bug covers this issue and I don't need to file a new one, right?

(In reply to ferongr from comment #10) > Some 4chan boards have enabled posting .webm files instead of images and the > page's script can display them inline. Opening many of them results in large > amounts of memory used as follows. This bug is one of the things that needs to be fixed. Memory use will probably already be a little better in Firefox 31 (current Firefox Nightly) thanks to bug 631058. Provided those videos aren't all trying to play at once.

Further to ferongr's question, using 4chan pages with large amounts of WebM videos can result in Firefox CPU use skyrocketing after some time browsing a single thread (page). Closing the tab and reopening it stops this. This happens when you use a feature of 4chan which makes the video pop up and play as you hover over the corresponding thumbnail on the page, and then disappear when the cursor leaves the thumbnail. Presumably the video is still playing in the background but I'm not sure. Is this the same bug or should I file it in detail separately?

(In reply to Sam from comment #12) > Is this the same bug or > should I file it in detail separately? This is the same bug. Thanks for following up.