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

RESOLVED WORKSFORME

Status

()

--
major
RESOLVED WORKSFORME
3 years ago
3 years ago

People

(Reporter: jruderman, Unassigned, NeedInfo)

Tracking

({memory-leak})

Trunk
memory-leak
Points:
---

Firefox Tracking Flags

(firefox42-)

Details

(Whiteboard: [MemShrink:P2])

Attachments

(2 attachments)

(Reporter)

Description

3 years ago
Created attachment 8640940 [details]
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.
Component: General → Graphics
Whiteboard: [MemShrink]
Created attachment 8641201 [details]
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().
> 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.
> 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.
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.
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.
(Reporter)

Comment 6

3 years ago
[Tracking Requested]: Probably a severe memory leak when watching YouTube videos
tracking-firefox42: --- → ?
(Reporter)

Comment 7

3 years ago
Likely related: bug 1177086, bug 1190530

Updated

3 years ago
Depends on: 1190592
The MP4Demuxer side of things should be fixed with bug 1190019

Comment 9

3 years ago
Jesse, can you rerun with the fix mentioned in comment 8?
Flags: needinfo?(jruderman)
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.
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.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WORKSFORME
Whiteboard: [MemShrink] → [MemShrink:P2]
status-firefox42: affected → ---
tracking-firefox42: ? → -
You need to log in before you can comment on or make changes to this bug.