nsTouchBar keeps nsITouchBarInputCallbacks alive for too long

RESOLVED FIXED in Firefox 68

Status

()

defect
RESOLVED FIXED
3 months ago
3 months ago

People

(Reporter: mccr8, Assigned: mccr8)

Tracking

(Regression)

unspecified
mozilla68
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox68 fixed)

Details

Attachments

(1 attachment)

This appears to be the leak being seen in 1525411. nsTouchBar has a dictionary containing TouchBarInput, which in turn has a field with type nsITouchBarInputCallback. This is implemented in JS. The touch bar isn't torn down until after XPConnect shutdown, or something like that, so we end up leaking nsXPCWrappedJS and a few other things on developer machines that have touch bars.

This is basically a variant of bug 1523944, and adding a loop to releaseJSObjects that sets the callbacks to null seems to fix the leak.

Blocks: touchbar

Could be due to bug 1529366 ?

(In reply to Tim Nguyen :ntim from comment #1)

Could be due to bug 1529366 ?

I did look at that code, but I think the issue dates to the initial touchbar support in bug 1313429.

No longer blocks: touchbar
Regressed by: touchbar

I investigated this leak by adding code like this to the XPCWJS ctor and similar code to the dtor:
printf("XPCWJS CREATE %d %p %s\n", getpid(), this, aInfo->Name());
Then I triggered the leak, grepped for this logging in the leaking process, and wrote a little log analyzer to figure out that the leaked items were nsITouchBarInputCallback. Then I audited the uses of this class, and found the use in the touchbar class, which was similar to bug 1523944.

Pushed by amccreight@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/83e7324dc00b
Release nsITouchBarInputCallback earlier so it doesn't leak. r=spohl
Status: NEW → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68
You need to log in before you can comment on or make changes to this bug.