1189194 - High heap-unclassified (mozilla::gfx::DrawTargetCG::DrawSurface, mp4_demuxer::SampleIterator::GetNext?)

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect)

Description

[Jesse Ruderman]

Attachment: about:memory & DMD reports

This morning, I noticed my Mac Nightly showing 60% heap-unclassified. I switched to a local DMD build, occasionally checking about:memory, and then suddenly found its heap-unclassified at 60% as well.

I suspect YouTube videos, based on when I noticed it being high, and on the stack traces I saw from DMD. If so, it's probably a full-on leak, because it persisted after closing all the tabs with videos.

I'm not sure why I got two DMD dumps when I clicked the "Save DMD" button, but I ran each of them through dmd.py.

Comment 1

[Andrew McCreight [:mccr8]]

Attachment: Unreported memory

For convenience, here are the largest unreported allocations.

The top entry is about 700MB in some kind of CoreGraphics allocation under mozilla::gfx::DrawTargetCG::DrawSurface(). The second entry is about 180MB under mp4_demuxer::SampleIterator::GetNext().

Comment 2

[Nicholas Nethercote [inactive]]

> The second entry is about 180MB under mp4_demuxer::SampleIterator::GetNext().

There are lots of records that include mozilla::MP4TrackDemuxer::GetSamples(int), and their combined size is over 400 MB.

Comment 3

[Nicholas Nethercote [inactive]]

> The top entry is about 700MB in some kind of CoreGraphics allocation under
> mozilla::gfx::DrawTargetCG::DrawSurface().

Because it is in CoreGraphics it's difficult to report, unfortunately. The preferred way to measure heap allocations is by traversing the data structures and calling malloc_size_of on all the heap blocks, but we typically can't do that for memory allocated by system libraries. There are places in the graphics code where we compute approximate memory usage and report that. Such reports won't be seen by DMD and I don't know if they're relevant in this case or not. Probably not, since Jesse is seeing high heap-unclassified values.

The MP4TrackDemuxer memory, on the other hand, is clearly all ours and it should be easy to write a reporter for it.

Comment 4

[Arpad Borsos [:Swatinem]]

I have this problem also on windows. And because its 32bit, it quite frequently crashes due to OOM.
From the usage pattern, there is a lot of youtube and soundcloud involved so that might sure be the problem.

Comment 5

[Nicholas Nethercote [inactive]]

Swatinem, can you please file a separate bug? Jesse reported this on Mac and you are on Windows and the graphics-related code is completely different on the two platforms, so it's quite possible that there are different underlying causes, in which case having a single bug is confusing. If they turn out to have the same underlying cause we can mark one bug as a duplicate of the other. Thank you.

Comment 6

[Jesse Ruderman]

[Tracking Requested]: Probably a severe memory leak when watching YouTube videos

Comment 7

[Jesse Ruderman]

Likely related: bug 1177086, bug 1190530

Comment 8

[Jean-Yves Avenard [:jya]]

The MP4Demuxer side of things should be fixed with bug 1190019

Comment 9

[Eric Rahm [:erahm]]

Jesse, can you rerun with the fix mentioned in comment 8?

Comment 10

[Jean-Yves Avenard [:jya]]

I run DMD on my local copy, and the MediaRawData reported objects now are within 100MB allocated (though found that it takes sometimes 21% extra than requested).

So it's all exactly as expected.

Comment 11

[Nicholas Nethercote [inactive]]

We have bug 1190592 for the MP4 reporter and the other one will be hard because its all in system libs. So I think there's not much more to be done here.