Closed
Bug 1071721
Opened 10 years ago
Closed 10 years ago
SettingsLock objects leak by only calling destroyDOMRequestHandler during inner-window-closed
Categories
(Core :: DOM: Device Interfaces, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox33 | --- | unaffected |
firefox34 | --- | fixed |
firefox35 | --- | fixed |
b2g-v1.4 | --- | unaffected |
b2g-v2.0 | --- | unaffected |
b2g-v2.0M | --- | unaffected |
b2g-v2.1 | --- | fixed |
b2g-v2.2 | --- | fixed |
People
(Reporter: qdot, Assigned: qdot)
References
Details
(Whiteboard: [systemsfe][MemShrink])
Attachments
(1 file)
1.85 KB,
patch
|
bent.mozilla
:
review+
khuey
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
[Blocking Requested - why for this release]:
SettingsLock objects never explicitly call destroyDOMRequestHelper when their existence ends (after receiving an Finalize::OK or Finalize::KO message). This means that the message manager will hold settings locks open until inner-window-destroyed. In the case of B2G, this means that locks existing in background apps (like system) will live forever, causing leaks.
blocking-b2g: 2.1? → 2.1+
Updated•10 years ago
|
Whiteboard: [systemsfe] → [systemsfe][MemShrink]
Assignee | ||
Comment 1•10 years ago
|
||
Assignee: nobody → kyle
Attachment #8493889 -
Flags: review?(bent.mozilla)
Assignee | ||
Comment 2•10 years ago
|
||
Checked this by flashing flame, going through FTU, then running get_about_memory.py and looking for open settings locks (basically, grepping for "SettingsLock <no private>":
Before patch - 187 occurrences
After patch - 8 occurrences
I'm going to do root traces on the 8 occurrences after the patch to make sure those aren't leaks too, but there's a good chance those are just locks held by various objects as members or something.
Updated•10 years ago
|
Attachment #8493889 -
Flags: review?(bent.mozilla) → review+
Assignee | ||
Comment 3•10 years ago
|
||
Comment on attachment 8493889 [details] [diff] [review]
Patch 1 (v1) - Call destroyDOMRequestHelper on SettingsLock after transaction ends
Approval Request Comment
[Feature/regressing bug #]: Bug 900551
[User impact if declined]: Memory leaks
[Describe test coverage new/current, TBPL]: It's believed that this currently takes down stability testing, so if that works...
[Risks and why]: None
[String/UUID change made/needed]: None
Attachment #8493889 -
Flags: approval-mozilla-aurora?
Attachment #8493889 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Assignee | ||
Comment 4•10 years ago
|
||
Comment 5•10 years ago
|
||
Kyle landed this on Aurora.
https://hg.mozilla.org/releases/mozilla-aurora/rev/96e15bbed7ab
Comment 6•10 years ago
|
||
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•