Tens of thousands of copies of specialpowers



3 years ago
2 years ago


(Reporter: khuey, Unassigned)


(Blocks: 1 bug, {ateam-marionette-server})

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [MemShrink:P1])

+++ This bug was initially created as a clone of Bug #1048833 +++

This is happening again in bug 1095714.  Somehow we have ~60000 instances of SpecialPowers in the keyboard app.
Flags: needinfo?(mdas)
Whiteboard: [MemShrink] → [MemShrink:P1]
I'm a bit confused, now that the bug has progressed and closes the settingslistener, does this still happen or was the special powers instance alive because the listener was alive?
Flags: needinfo?(mdas)
keep flag open so I can track this bug
Flags: needinfo?(mdas)
The SpecialPowers stuff is in the keyboard process, while the SettingsListener stuff is in the parent process, so I doubt they're related.
Keywords: ateam-marionette-server
It's hard to trace where this is coming from. We don't leak SP objects if we do a simple [start marionette, open app, run sp script in window, delete marionette session, kill app] cycle, but something in this process creates a bunch of additional SP objects. I don't know what makes the Keyboard app special.

In any case, we have no way to remove SpecialPowers from a window (nor remove its observers), so we can't really clean up from this. We should at least have a way to do this. If I can get a way to say 'hey, remove specialpowers and observers and all that jazz from this window object' that would help us here. Can this be added jmaher/ted?

In addition, I don't think the leak is coming from marionette, since we only add Specialpowers if it exists in that window now, and when running this test with the keyboard, I see that we only retrieve it, not create a new instance. It looks like the leak is coming from within SpecialPowers...
Flags: needinfo?(ted)
Flags: needinfo?(mdas)
Flags: needinfo?(jmaher)
in specialpowers we create a new instance of specialpowers for every dom window created:

When we do all of this we end up doing our magic bindDOMUtils goop:

which does a lot of crazy stuff:

Is there a way to delete the crazy stuff and the specialpowers() object?  If we could easily do that, I would be excited about seeing it in specialpowers.

Is there a chance we are accidentally creating a bunch of specialpowers() objects?  maybe we are creating a bunch of dom windows?  or is this a side effect of many tests running on the system at once?
Flags: needinfo?(jmaher)
(In reply to Joel Maher (:jmaher) from comment #6)
> Is there a chance we are accidentally creating a bunch of specialpowers()
> objects?  maybe we are creating a bunch of dom windows?  or is this a side
> effect of many tests running on the system at once?

from the marionette perspective, we only create the specialpowers object if it's not attached to the current frame https://mxr.mozilla.org/mozilla-central/source/testing/marionette/marionette-listener.js?rev=27ec914bf55f#408. (aWindow is curFrame which is equal to the current content window), and I can verify that during the problematic test, we only retrieve the object, not create it...
So two things I can think of just skimming the code.
1) We do try to do some cleanup in the inner-window-destroyed observer notification:

Maybe that's not firing in this case and so things are sticking around longer than they ought to?

2) By default the specialpowers script instantiates a SpecialPowersManager which listens for DOMWindowCreated events and attaches SpecialPowers to each window that gets created:

You could try commenting out the line that instantiates that listener and seeing if that helps:

It seems like that behavior (SpecialPowers everywhere) isn't really what you want in Marionette. If that fixes it we could tweak SP to handle your usecase better.
Flags: needinfo?(ted)
Nothing was fixed here, but people haven't complained about this recently, so maybe it went away.
Last Resolved: 2 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.