+++ 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.
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?
keep flag open so I can track this bug
The SpecialPowers stuff is in the keyboard process, while the SettingsListener stuff is in the parent process, so I doubt they're related.
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...
in specialpowers we create a new instance of specialpowers for every dom window created: http://dxr.mozilla.org/mozilla-central/source/testing/specialpowers/content/specialpowers.js#128 When we do all of this we end up doing our magic bindDOMUtils goop: http://dxr.mozilla.org/mozilla-central/source/testing/specialpowers/content/specialpowers.js#16 which does a lot of crazy stuff: http://dxr.mozilla.org/mozilla-central/source/testing/specialpowers/content/specialpowersAPI.js#44 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?
(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: http://dxr.mozilla.org/mozilla-central/source/testing/specialpowers/content/specialpowers.js#28 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: http://dxr.mozilla.org/mozilla-central/source/testing/specialpowers/content/specialpowers.js#128 You could try commenting out the line that instantiates that listener and seeing if that helps: http://dxr.mozilla.org/mozilla-central/source/testing/specialpowers/content/specialpowers.js#138 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.
Nothing was fixed here, but people haven't complained about this recently, so maybe it went away.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.