Peter Scott Reporter
	Description • 8 years ago

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20161017130949

Steps to reproduce:

Just type in about:memory, v simple! Tried it in profile and in blank new profile.


Actual results:

Main Process

WARNING: the following values are negative or unreasonably large.

    explicit/js-non-window
    explicit/(12 tiny)
    explicit/(12 tiny)/heap-unclassified 

This indicates a defect in one or more memory reporters. The invalid values are highlighted. 

I'll attach the verbose memory report.


Expected results:

Non-negative- as Firefox said its a bug, then I assume it's a bug. And I'm trying to be community minded and report it like a good user should. It seems a bit, er, difficult, that last part, to be frank, but I love the hell out of your browser, have customized it a bit (all just appearance, nowt weird) and couldn't/wouldn't use anything else. You have me as a customer til you stop.

	Andrew McCreight [:mccr8]
	Comment 1 • 8 years ago

I feel like I've seen a very similar one to this recently, but I don't remember what it is.

The totals for explicit/js-non-window and explicit/window-objects are larger than explicit! There are also a large number of JS zones. My only theory here is that somehow sharing of shapes isn't being properly handled in the memory reporter, but I'd assume somebody else would have run DMD in the mean time and noticed that.

	Andrew McCreight [:mccr8]
	Comment 2 • 8 years ago

Well, bug 1295967 didn't land until 51, and it sounds like the reporter is using 50. (At least based on comment 0.)

	Eric Rahm [:erahm]
	Comment 3 • 8 years ago

This is pretty odd, looks like mozjemalloc isn't reporting it's memory?

>    0.00 MB ── heap-allocated
>    1.00 MB ── heap-chunksize
>    1.00 MB ── heap-mapped

I'm reasonably sure we're doing heap-unclassified = heap-allocated - sum(explicit-tree). Nick does that sound about right?

	Nicholas Nethercote [inactive]
	Comment 4 • 8 years ago

(In reply to Eric Rahm [:erahm] from comment #3)
> This is pretty odd, looks like mozjemalloc isn't reporting it's memory?
> 
> >    0.00 MB ── heap-allocated
> >    1.00 MB ── heap-chunksize
> >    1.00 MB ── heap-mapped

This is the root of the problem. I don't why heap-allocated would be zero, I don't think I've seen that before.
 
> I'm reasonably sure we're doing heap-unclassified = heap-allocated -
> sum(explicit-tree). Nick does that sound about right?

Close. It's this: heap-unclassified = heap-allocated - sum(all explicit measurements with kind == HEAP)

So heap-allocated is bogus, which makes heap-unclassified bogus, which makes explicit bogus, which leads to complaints about js-non-window and window-objects.

	Eric Rahm [:erahm]
	Comment 6 • 8 years ago

I'm going to P3 this for now as it's not an actual memory leak. ni'ing myself to test on OSX with an official release build (not nightly) to see if there's something wonky with jemalloc on 10.12 + release builds.

	Mike Hommey [:glandium] Assignee
	Comment 7 • 8 years ago

Essentially, this is a different incarnation of bug 1284677. Nightly is not affected because it uses replace-malloc, which uses a different (and now fixed) zone registration. Replace-malloc is not enabled on non-nightly builds.

Mozjemalloc needs to be adjusted such that the zone is properly registered on 10.12.  For some reason, I've always avoided touching the mozjemalloc zone registration code, maybe it's time to just make it use the same as replace-malloc and upstream jemalloc.

	Eric Rahm [:erahm]
	Comment 8 • 8 years ago

Okay, bumping the priority and moving to memory allocator. Not using (moz)jemalloc on 10.12 seems bad.

	Mike Hommey [:glandium] Assignee
	Comment 9 • 8 years ago

Can someone test this try build on macOS 10.12 and see if heap-allocated is non-zero?
https://archive.mozilla.org/pub/firefox/try-builds/mh@glandium.org-af5735651877ce104e495140e8a84cacdf2440b8/try-macosx64/

(Also, if someone could test that it still works on older versions...)

	Mike Hommey [:glandium] Assignee
	Comment 10 • 8 years ago

Direct link to the dmg:
https://archive.mozilla.org/pub/firefox/try-builds/mh@glandium.org-af5735651877ce104e495140e8a84cacdf2440b8/try-macosx64/firefox-52.0a1.en-US.mac.dmg

	Mike Hommey [:glandium] Assignee
	Comment 11 • 8 years ago

Please see comment 9.

	Nicholas Nethercote [inactive]
	Comment 13 • 8 years ago
mozreview-review

Comment on attachment 8810730 [details]
Bug 1311039 - Properly detect the default malloc zone on OSX 10.12.

https://reviewboard.mozilla.org/r/93044/#review93000

rs=me

	Eric Rahm [:erahm]
	Comment 14 • 8 years ago

(In reply to Mike Hommey [:glandium] from comment #9)
> Can someone test this try build on macOS 10.12 and see if heap-allocated is
> non-zero?
> https://archive.mozilla.org/pub/firefox/try-builds/mh@glandium.org-
> af5735651877ce104e495140e8a84cacdf2440b8/try-macosx64/

Confirmed, heap-allocated is non-zero.

> (Also, if someone could test that it still works on older versions...)

I can only confirm 10.12, but presumably our try servers can confirm 10.10. I'd suggest adding/updating a unit test that makes sure heap-allocated is always non-zero.

	Mike Hommey [:glandium] Assignee
	Comment 15 • 8 years ago

As per irc, and further validation on try, there already is a unit test that makes sure heap-allocated is non-zero. Except it doesn't run on 10.12, so it hasn't detected *this* bug. (But, if I force jemalloc not to be hooked on all osx versions, it correctly detects that)

	Pulsebot
	Comment 16 • 8 years ago

Pushed by mh@glandium.org:
https://hg.mozilla.org/integration/autoland/rev/2e0ae44e91ae
Properly detect the default malloc zone on OSX 10.12. r=njn

	Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)
	Comment 17 • 8 years ago
bugherder

https://hg.mozilla.org/mozilla-central/rev/2e0ae44e91ae

	Andrei Vaida [:avaida]
	Comment 18 • 7 years ago

Let's make sure this works as intended on Mac OS X 10.9 to macOS 10.12. Instructions in Comment 0.

	Cristian Comorasu, QA [:ccomorasu], Releae Desktop QA - Please contact mboldan@mozilla.com
	Comment 19 • 7 years ago

I could not reproduce the issue with instructions from description. Can you please give me more details?

Thank you!

	Mike Hommey [:glandium] Assignee
	Comment 20 • 7 years ago

(In reply to Cristian Comorasu [:CristiComo] from comment #19)
> I could not reproduce the issue with instructions from description. Can you
> please give me more details?
> 
> Thank you!

What did you try?

	Cristian Comorasu, QA [:ccomorasu], Releae Desktop QA - Please contact mboldan@mozilla.com
	Comment 21 • 7 years ago

I followed the steps from the description using the nightly build from the date this bug was filled and compared the results with the latest beta. What am I missing?
Thank you for the quick reply.

	Mike Hommey [:glandium] Assignee
	Comment 22 • 7 years ago

(In reply to Cristian Comorasu [:CristiComo] from comment #21)
> I followed the steps from the description using the nightly build from the
> date this bug was filled and compared the results with the latest beta. What
> am I missing?
> Thank you for the quick reply.

Did you try on OSX 10.12?

	Cristian Comorasu, QA [:ccomorasu], Releae Desktop QA - Please contact mboldan@mozilla.com
	Comment 23 • 7 years ago

Thank you Mike Hommey for clarifying via irc!

I reproduced this issue using Fx 52.0b1, on Mac OS X 10.12.3. 
I can confirm this issue is fixed, I verified using Fx 53.0b3.

The following platforms were verified:
 - Mac OS X 10.12.3
 - Mac OS X 10.11.6
 - Mac OS X 10.10.5
 - Mac OS X 10.9.5

Cheers!