use XPCOMUtils in content pref services to prevent leaks

RESOLVED FIXED

Status

()

Toolkit
Preferences
RESOLVED FIXED
11 years ago
11 years ago

People

(Reporter: myk, Assigned: myk)

Tracking

Trunk
Points:
---
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

11 years ago
After the content pref service got checked in, Rlk on fxdbug-linux-tbox went from 2.99KB to 3.07KB and then to 3.16KB.  It now fluctuates between the latter two numbers, whereas before it was fluctuating between the former two.

Per discussion on #developers, one issue is inline XPCOM plumbing.  We should switch to XPCOMUtils, although that'll only help once bug 381651 lands.
(Assignee)

Comment 1

11 years ago
Created attachment 269013 [details] [diff] [review]
patch v1: uses XPCOMUtils

Here's a patch that uses XPCOMUtils (the version in bug 381651).  Note that the following statement does not successfully import the module:

Components.utils.import("rel:XPCOMUtils.jsm");

It causes the app to complain:

Error: uncaught exception: [Exception... "Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIXPCComponents_Utils.import]"  nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame :: file:///home/myk/Projects/minefield/build/firefox-debug/dist/bin/components/nsContentPrefService.js :: <TOP_LEVEL> :: line 41"  data: no]

But this works:

Components.utils.import("resource://gre/modules/XPCOMUtils.jsm");
Assignee: nobody → myk
Status: NEW → ASSIGNED
Attachment #269013 - Flags: review?(sayrer)
(Assignee)

Updated

11 years ago
Blocks: 385237
(Assignee)

Updated

11 years ago
No longer blocks: 385237

Updated

11 years ago
Attachment #269013 - Flags: review?(sayrer) → review+
(Assignee)

Comment 2

11 years ago
Checking in toolkit/components/contentprefs/src/nsContentPrefService.js;
/cvsroot/mozilla/toolkit/components/contentprefs/src/nsContentPrefService.js,v  <--  nsContentPrefService.js
new revision: 1.5; previous revision: 1.4
done
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED

Comment 3

11 years ago
I backed this out, because it raised the leak stats. Locally, I can verify that it causes three leaked XPCWrappedNative objects and one XPCWrappedNativeProto object.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 4

11 years ago
Urm, right.  I thought it hadn't, but I wasn't running the bloat cycle, merely starting up and then shutting down the browser.  After running the bloat cycle, I see the same increase in the number and type of leaked objects.
(Assignee)

Comment 5

11 years ago
Checked in again now that bug 180380 has fixed the leaks.
Status: REOPENED → RESOLVED
Last Resolved: 11 years ago11 years ago
Resolution: --- → FIXED
Flags: in-testsuite-
You need to log in before you can comment on or make changes to this bug.