401677 - Investigate trace_malloc leaks on Mac

Status: RESOLVED INCOMPLETE

(Core :: General, defect, P2)

Description

[Colin Barrett [:cbarrett]]

We're leaking 1.06MB on Mac according to Lk, and that number is only increasing. Right now we really have no idea what makes up that 1.06MB. It's my suspicion that it's a combination of:

Legitimate, cross platform memory leaks
Legitimate, Mac-only (but Gecko-specific) memory leaks
"Shutdown leaks" from Gecko callers not cleaning things up during shutdown
Shutdown leaks from Cocoa and elsewhere.

My suspicion is that the fourth category is a large part of this, but we'll have to see. As a first step I'm going to debug the 50KB increase in Lk when I checked in bug 303110 (I suspect it is largely a bunch of spurious cache/shutdown leaks from CoreGraphics we can do nothing about), and we'll go from there.

Comment 1

[Robert Sayre]

What is the status of this bug?

Comment 2

[Colin Barrett [:cbarrett]]

I haven't had time to look at it more since yesterday. Hopefully tomorrow.

Comment 3

[Mike Schroepfer]

Anything today Colin?  Worried about mac leaks for b1 and my own non-scientific usage on mac/win seems to indicate mac is in general worse than win.

Comment 4

[Colin Barrett [:cbarrett]]

There's some progress here.

I took a look at the numbers again, and I'm still attempting to figure out how to interpret them -- dbaron is out at w3c stuff, is there anyone else who has fu with our memory leak tools? Mine is pretty basic.

I'll see if I can get something more reproducible (load gmail, open a message?) and start running some numbers. I was prioritizing this below other things though, it sounds like I shouldn't be?

Is this a drop-everything blocking-the-release bug?

Comment 5

[Colin Barrett [:cbarrett]]

I only ask because I had something already planned for this evening and wanted to know if I should cancel.

Comment 6

[Mike Schroepfer]

I'm not sure what else you are prioritizing so I can't help you there (damon maybe) but just trying to make sure we make progress on Mem usage on the mac since that's a big area of criticism for us.  Sayre, pav, dolske, others can help... 

Comment 7

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I talked with colin about this one, and everything is pointing towards that this is shutdown leaks which are only bad because they make debugging harder.

So we should definitely investigate this, but I don't think we need to hold beta for it.

Comment 8

[Peter Van der Beken [:peterv]]

I just filed bug 402901 on an increase in trace_malloc leaks related to unified toolbar.

Comment 9

[Damon Sicore (:damons)]

+'ing this, but feel free to dup it to bug 402901.

Comment 10

[Peter Van der Beken [:peterv]]

I don't think this is the same as bug 402901. Even with that one fixed we still leak quite a bit and we have no idea if they're real leaks or not.

Comment 11

[Colin Barrett [:cbarrett]]

Peterv, you are correct.

This bug is about wanting to investigate our why we leak so much on mac (shut down leaks, it looks like?) and how we can get that closer to zero bytes.

Comment 12

[Peter Van der Beken [:peterv]]

Filed bug 409424, which is another leak in our code (it's in Lk but not Rlk and it did show up in Instruments' Object Alloc tool).

Any progress on analyzing where the rest of these leaks are coming from?

Comment 13

[Robin Bate Boerop]

I have no fu with the Mozilla memory leak tools.  However, I use Mac OS X to develop, and I'm willing to help with this bug.

Also, I have used the 'leaks' tool that ships with Mac OS X to obtain the call stacks of code which allocates (using malloc) memory, and then "loses" the pointer to the allocated code.  90% of the instances involve "JS_malloc", "NewPropTreeKidsChunk", and "nsVoidArray::SizeTo(int)", but that is not to blame those functions.  Maybe these leaks are contributing to the 1.06MB reported by Lk.

Comment 14

[Robert Sayre]

leaks misreports Firefox leaks, because it doesn't understand tagged pointers. Most of the 90% cases are those.

Comment 15

[Robin Bate Boerop]

Robert: That makes sense, 'leaks' wouldn't know about tagged pointers.  If the tagged pointer code is well-encapsulated in a C++ class, it is possible to include the "real" pointer in a debug build.  That would help 'leaks' and also those using a debugger.  (Please point me to the tagged pointer code, if you have a minute.)

Colin: I have a Mac, if you need help.

Comment 16

[Brendan Eich [:brendan]]

SpiderMonkey is C, not C++, in cvs.mozilla.org at any rate, and more important, jsvals are used all over and can't stand to double in size in DEBUG builds (which top devs run as dogfood builds).

/be