DebuggerServer is never destroyed in the content process

RESOLVED FIXED in Firefox 66

Status

enhancement
P2
normal
RESOLVED FIXED
5 months ago
4 months ago

People

(Reporter: ochameau, Assigned: ochameau)

Tracking

(Blocks 1 bug)

unspecified
Firefox 66
Dependency tree / graph

Firefox Tracking Flags

(firefox66 fixed)

Details

Attachments

(2 attachments)

Assignee

Description

5 months ago

We are instantiating a DebuggerServer from the main frame script here:
https://searchfox.org/mozilla-central/rev/dac799c9f4e9f5f05c1071cba94f2522aa31f7eb/devtools/server/startup/frame.js#24-31
That we never ever try to destroy/cleanup.
It means that if we close the toolbox, the server is still around and may hold various objects alive, especially if actors are not cleaned up correctly.

And actually, the same also apply to the loader we create a few lines before, but that would be yet another level of cleanup.

In bug 1515290, I'm hitting this issue by having a test that report leaks on try, because we don't cleanup the server and leak objects indirectly from it.

Assignee

Comment 2

5 months ago

We never really tried to cleanup the DebuggerServer and so a few tests require some tweaks
to acknowledge that once the last connection drop (typically, we close the toolbox or target),
the server is destroyed and dynamically registered actors are also destroyed.

I think it is great to consider that everything is cleaned up as we may followup to destroy
the whole loader.

Depends on D16961

Priority: -- → P2

Comment 4

5 months ago
Pushed by apoirot@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/b4cd1ef4baf0
Add DebuggerServer.hasConnection to track if it still has active connections. r=jdescottes
https://hg.mozilla.org/integration/autoland/rev/c68ab257f8c8
Destroy DebuggerServer in the content process when the last connection drops. r=jdescottes

Comment 5

5 months ago
bugherder
Status: NEW → RESOLVED
Closed: 5 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 66
Depends on: 1528276
You need to log in before you can comment on or make changes to this bug.