801515 - Negative heap-unclassified in about:memory, probably due to gfx/font-* mismeasurements

Status: UNCONFIRMED

(Toolkit :: about:memory, defect)

Description

[Hugh Nougher [:Hughman]]

Attachment: about:memory?verbose

I loaded up about:memory just to have my regular look found it giving warnings about negative values on heap-unclassified. This is Aurora 17 from 8th Oct.

Simple copy of bits I think relevant. Attaching full copy.

568,681,468 B (100.0%) -- explicit
├──251,782,400 B (44.27%) -- gfx
│  ├──166,541,648 B (29.29%) ── font-charmaps [91]
│  ├───54,569,424 B (09.60%) ── font-tables [91]
│  ├───28,464,800 B (05.01%) ── font-list [91]
│  ├────1,986,464 B (00.35%) ── font-shaped-words
│  └──────220,064 B (00.04%) ── font-cache
├──233,001,464 B (40.97%) -- window-objects

└──-112,997,829 B (-19.87%) ── heap-unclassified [?!]

301,215,852 B (100.0%) -- js-main-runtime
├──254,932,310 B (84.63%) -- compartments

Comment 1

[Nicholas Nethercote [inactive]]

Does this happen on any sites in particular?  You have quite a few tabs open in that about:memory snapshot...

Comment 2

[Hugh Nougher [:Hughman]]

I have had a bit of a look around with other instances of Aurora but loading the pages but could not get a replication (mostly just looking for multiple reporters in gfx-fonts).

My best guess about its origin is it happening sometime this morning.
The only thing unique about this morning was my universities LAN went haywire.

Comment 3

[Nicholas Nethercote [inactive]]

If we don't have steps to reproduce we might as well close the bug :/

Comment 4

[Nicholas Nethercote [inactive]]

Oh, I didn't notice the "[91]", which means we have 91 instances of each of those reports, and the shown output is the sum of them.  jkew, that sounds rather odd -- do you think you could look at the code of the reporters and see if something might account for that?

Comment 5

[Jonathan Kew [:jfkthame]]

That does seem fishy.

Those three reports are all generated by gfxPlatformFontList::MemoryReporter, of which a single instance is created and registered by the gfxPlatformFontList constructor.

And there's only supposed to be one instance of gfxPlatformFontList in the process, created when gfxPlatform::Init() calls the static method gfxPlatformFontList::Init(). That should only happen once.

So in short, I don't know how this could happen. Is it possible the memory-reporter manager somehow got confused and ended up calling CollectReports() multiple times on the same reporter?