1312910 - Huge slop and large unreported data with DMD at sci.esa.int/where_is_rosetta/

Status: RESOLVED WONTFIX

(Core :: Graphics: CanvasWebGL, defect)

Description

[lolo2bdx]

Attachment: dmd.txt

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:49.0) Gecko/20100101 Firefox/49.0
Build ID: 20161019084923

Steps to reproduce:

1) On Ubuntu 16.04 (64-bit PC), with dmd enabled, build and launch firefox 
2) In a first tab, open the following link : http://sci.esa.int/where_is_rosetta/
3) Click on "play" when available
4) In a second tab, open about:memory and launch a measurement
=> The measurement gives a lot of slop in class(Object)/objects in the js compartment of http://sci.esa.int/where_is_rosetta/
5) Save DMD output and analyse this report


Actual results:

There is a lot of unreported data in the DMD report (here : 32.08% of unreported data)


Expected results:

Some data should be unreported in the DMD report, but not that much.

Comment 1

[Andrew McCreight [:mccr8]]

It looks like most of this heap-unclassified stems from mozilla::DoTexImage().

Comment 2

[Nicholas Nethercote [inactive]]

(In reply to Andrew McCreight [:mccr8] from comment #1)
> It looks like most of this heap-unclassified stems from
> mozilla::DoTexImage().

That function, and various other texture-related functions. They all end up going through nouveau_drm_screen_create().

Unfortunately gfx memory like this is impossible to measure in a way that will satisfy DMD, because the malloc calls occur within the gfx driver which we have no control over. (I wrote about the difficulty of this at https://blog.mozilla.org/nnethercote/2014/07/07/measuring-memory-used-by-third-party-code/.)

So I don't think there is anything we can do here, alas.