Closed
Bug 1048833
Opened 10 years ago
Closed 10 years ago
[MTBF] Memory grows unexpectedly in system app
Categories
(Remote Protocol :: Marionette, defect, P1)
Tracking
(blocking-b2g:2.0+, firefox32 wontfix, firefox33 wontfix, firefox34 fixed, b2g-v1.4 fixed, b2g-v2.0 fixed, b2g-v2.1 fixed)
People
(Reporter: pyang, Assigned: mdas)
References
Details
Attachments
(1 file)
986 bytes,
patch
|
automatedtester
:
review+
|
Details | Diff | Splinter Review |
Reproduce by Device: Flame Memory: 319MB Gaia 9e5907995c9327f14cb5d182cee5ff16b1743ed4 Gecko https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/3f7db58a354c BuildID 20140803160201 Version 32.0 ro.build.version.incremental=109 ro.build.date=Mon Jun 16 16:51:29 CST 2014 From memory report, system app seems held over 1k event handlers and trigger LMK repeatedly.
Reporter | ||
Comment 1•10 years ago
|
||
URL for memory report: https://drive.google.com/file/d/0BzGnh6LcgHLQSnE3dmZ5UldiSTQ/edit?usp=sharing
Comment 2•10 years ago
|
||
Not sure if this is relevant, Ting-Yuan and I found that there are tons of "Function" entries in gc-edges.290.1407222245.log: > cervantes@cyu-dt:/tmp/about-memory-1$ grep "G Function onInnerWindowDestroyed" gc-edges.290.1407222245.log |wc -l 39397 > cervantes@cyu-dt:/tmp/about-memory-1$ grep "G Function SpecialPowers" gc-edges.290.1407222245.log |wc -l 39411 > cervantes@cyu-dt:/tmp/about-memory-1$grep "G Function get" gc-edges.290.1407222245.log |wc - l 39425
It looks relevant. There are 39361 inner-window-destroyed observers.
And the 'script' on all of the functions is chrome://specialpowers/content/specialpowers.js:28.
And if you search for '_pongHandlers' in the GC log you'll see there's ~39000 SpecialPowers objects. This seems like a test harness issue.
Reporter | ||
Comment 6•10 years ago
|
||
ni? manili for special power usage in marionette
Flags: needinfo?(mdas)
Does marionette reuse the sandbox it creates to execute scripts in?
Assignee | ||
Comment 8•10 years ago
|
||
(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #7) > Does marionette reuse the sandbox it creates to execute scripts in? By default, we don't reuse sandboxes. They get reused if you call execute script with 'newSandbox' parameter set to false. When creating new sandboxes, we don't explicitly delete the old one, we just reassign the variable (https://mxr.mozilla.org/mozilla-central/source/testing/marionette/marionette-listener.js#482). This should be fixed, and I'll add a patch for this.
Flags: needinfo?(mdas)
Assignee | ||
Comment 9•10 years ago
|
||
(In reply to Paul Yang [: pyang] from comment #6) > ni? manili for special power usage in marionette What exactly is the question?
Assignee | ||
Comment 10•10 years ago
|
||
(In reply to Malini Das [:mdas] from comment #8) > (In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #7) > > Does marionette reuse the sandbox it creates to execute scripts in? > > By default, we don't reuse sandboxes. They get reused if you call execute > script with 'newSandbox' parameter set to false. > > When creating new sandboxes, we don't explicitly delete the old one, we just > reassign the variable > (https://mxr.mozilla.org/mozilla-central/source/testing/marionette/ > marionette-listener.js#482). This should be fixed, and I'll add a patch for > this. Actually, heh, I got confused and I'm not sure if there is a better way to do this. Do you know of a way to mark the content of a variable for garbage collection? I thought that by reassigning the variable, the object would mark itself for GC if it has no other variables referencing it.
The sandboxes are getting GCd, but the SpecialPowers stuff is not. SpecialPowers has an implicit assumption that there's only going to be one per window.
Assignee | ||
Comment 12•10 years ago
|
||
bumping to P1 for memory leaks leading to improper testing
Priority: -- → P1
Assignee | ||
Updated•10 years ago
|
Assignee: nobody → mdas
Component: MTBF → Marionette
Product: Firefox OS → Testing
Assignee | ||
Comment 13•10 years ago
|
||
Marionette adds the specialpowers object to the window each time (https://mxr.mozilla.org/mozilla-central/source/testing/marionette/marionette-listener.js#405). I'll modify this so marionette will look for specialpowers first, and injects it if it is not found.
Updated•10 years ago
|
Blocks: MTBF-Marionette
Assignee | ||
Comment 14•10 years ago
|
||
Before this patch, if you used SpecialPowers, then the SpecialPowers constructor would be called each time if you're not reusing a sandbox. I tested this patch locally on a browser and the SpecialPowers constructor doesn't get called each time you use it. Mn desktop try is green: https://tbpl.mozilla.org/?tree=Try&rev=db9123df5e53
Attachment #8468514 -
Flags: review?(dburns)
Updated•10 years ago
|
Attachment #8468514 -
Flags: review?(dburns) → review+
Assignee | ||
Updated•10 years ago
|
Keywords: checkin-needed
Reporter | ||
Updated•10 years ago
|
status-b2g-v2.0:
--- → affected
status-b2g-v2.1:
--- → affected
Comment 15•10 years ago
|
||
https://hg.mozilla.org/integration/b2g-inbound/rev/83bc4242fd1c
Keywords: checkin-needed
Whiteboard: [checkin-needed-b2g32]
Not sure if we need blocking status to be able to land Marionette fixes but this does block our testing so here you go.
blocking-b2g: --- → 2.0+
Comment 17•10 years ago
|
||
https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/a5594f074a65 https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/6c74f9535125 I was going to land it a=test-only anyway :)
status-b2g-v1.4:
--- → fixed
status-firefox32:
--- → wontfix
status-firefox33:
--- → wontfix
status-firefox34:
--- → fixed
Whiteboard: [checkin-needed-b2g32]
Assignee | ||
Comment 18•10 years ago
|
||
Can we mark as Fixed or are any other landings needed?
It hasn't landed on m-c yet which is why it's not resolved.
https://hg.mozilla.org/mozilla-central/rev/83bc4242fd1c
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla34
Reporter | ||
Comment 21•10 years ago
|
||
Thanks for the patch. It works really good.
Blocks: 1095817
Updated•1 year ago
|
Product: Testing → Remote Protocol
You need to log in
before you can comment on or make changes to this bug.
Description
•