Track number of DOMWindow/DocShell leaks and report improvements/regressions

RESOLVED WORKSFORME

Status

Testing
Sisyphus
--
enhancement
RESOLVED WORKSFORME
5 years ago
5 years ago

People

(Reporter: ttaubert, Unassigned)

Tracking

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [MemShrink:P1], URL)

(Reporter)

Description

5 years ago
Bug 683953 implemented leak statistics that are gathered for m-oth test suite runs and contained in each m-oth debug log. We should parse and record those numbers to report regressions and be able to build graphs from this data.
Ftr, SeaMonkey support would be wanted, if possible.
No longer blocks: 683953
Severity: normal → enhancement
Depends on: 683953
Summary: Track number of DOMWindow/DocShell leaks and report regressions → Track number of DOMWindow/DocShell leaks and report improvements/regressions
Also related to this and bug 683953: bug 728294
Assignee: nobody → ttaubert
Whiteboard: [MemShrink] → [MemShrink:P1]
(Reporter)

Comment 3

5 years ago
I'd really like to implement that but have no idea about how to integrate these statistics into our Talos infrastructure.
http://hg.mozilla.org/mozilla-central/rev/3dcb40ebd487
130 -> 123

Comment 5

5 years ago
(In reply to Tim Taubert [:ttaubert] from comment #3)
> I'd really like to implement that but have no idea about how to integrate
> these statistics into our Talos infrastructure.
This would be cool. Currently we post JSON to the graphserver  in order to track items. The current graphserver SQL schema is very tied to the talos data specifically. We are in the process of building a generic graphing database to hold numbers that can perform graphing functions easily and provide a plugable interface so you can easily add new statistics and UIs to it.

If you want to target the current production graph server (graphs.m.o) then you need to get the json together you want to submit, we need to get a SQL statement together to perform the necessary table alterations, and we need to get webdev involved to ensure they can put a UI atop the new table. I don't really imagine any of these steps to be difficult, they will just take some time.

With the other, you have to wait for us to get it deployed to staging/production (but you could write to our development system right now). We are aiming to have it in staging/production in Q2 of this year.  

Whichever way you want to pursue it, we can help with it.  And the first step is that we need the JSON you want to submit to track the memory leak problem over time. This way we can see how hard it will be to integrate into existing graphserver and how well it will fit into our generic schema we're developing for the new one.
Assignee: ttaubert → nobody
Component: Talos → Sisyphus
QA Contact: talos → sisyphus
http://hg.mozilla.org/mozilla-central/rev/89d3250b701d
123 -> 120
Depends on: 734554
I think we have a sufficient solution here, with the cc analyzer and whatnot.

Reopen if you disagree.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WORKSFORME

Comment 8

5 years ago
AFAIK we don't have cc analyzer on normal mochitests
You need to log in before you can comment on or make changes to this bug.