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)

25 Branch
x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED
2.1 S5 (26sep)
blocking-b2g 2.1+
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)

[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.
Whiteboard: [systemsfe] → [systemsfe][MemShrink]
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.
Attachment #8493889 - Flags: review?(bent.mozilla) → review+
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+
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.

Attachment

General

Created:
Updated:
Size: