Closed Bug 992244 Opened 10 years ago Closed 10 years ago

browser_dbg_addonactor.js isn't disconnecting the AddonThreadActor properly

Categories

(DevTools :: Debugger, defect)

x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Firefox 31

People

(Reporter: mossop, Assigned: past)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

Which leaves a debugger alive in chrome which can't be good
Assignee: nobody → dtownsend+bugmail
Summary: browser_dbg_addonactor.js isn't disconnecting the AddonThreadActor property → browser_dbg_addonactor.js isn't disconnecting the AddonThreadActor properly
Attached patch patchSplinter Review
I've verified that this works manually, not sure of a way to test it though.
Attachment #8402077 - Flags: review?(past)
Comment on attachment 8402077 [details] [diff] [review]
patch

Review of attachment 8402077 [details] [diff] [review]:
-----------------------------------------------------------------

Interesting, I wonder if the debugger remaining active is responsible for some of the extra time it takes for running devtools mochitests. I see how this will work, but I think there is a broader problem here that we need to fix, as it should have been removeActorPool's duty to cleanup child actors. Let me attach a patch to show you what I mean.
Attachment #8402077 - Flags: review?(past)
This is what I had in mind. AFAIK every use of removeActorPool was made under the impression that actor.disconnect() would be called for every actor in the pool, but it turns out that you need to specify an extra parameter that I bet almost nobody paid attention to. To cater to the common case removeActorPool should cleanup actor children by default, unless there is a particular reason not to.

The only case I've found during testing is protocol.js, which sort of deals with a lot of these things on its own, but I bet I could remove even that with some rearranging of pool.destroy() and pool.cleanup(). In that case we would simplify removeActorPool and get rid of its second argument.

Dave T., can you verify that this patch fixes the AddonThreadActor's problem?
Dave C., can you think of any reason for not wanting to disconnect actors in all cases?

Try: https://tbpl.mozilla.org/?tree=Try&rev=413f19d4e61c
Attachment #8402648 - Flags: review?(dcamp)
Attachment #8402648 - Flags: feedback?(dtownsend+bugmail)
Assignee: dtownsend+bugmail → past
Status: NEW → ASSIGNED
(In reply to Panos Astithas [:past] from comment #2)
> Comment on attachment 8402077 [details] [diff] [review]
> patch
> 
> Review of attachment 8402077 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Interesting, I wonder if the debugger remaining active is responsible for
> some of the extra time it takes for running devtools mochitests.

I was a little hopeful of that myself, but the length of the browser-chrome runs with this patch didn't differ from the normal length  so I think not.
Comment on attachment 8402648 [details] [diff] [review]
Disconnect actors by default when removing an actor pool

Review of attachment 8402648 [details] [diff] [review]:
-----------------------------------------------------------------

Yeah this fixes it. I did wonder when I read that comment in webbrowser.js
Attachment #8402648 - Flags: feedback?(dtownsend+bugmail) → feedback+
Attachment #8402648 - Flags: review?(dcamp) → review+
https://hg.mozilla.org/mozilla-central/rev/a3b408d4c47a
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Whiteboard: [fixed-in-fx-team]
Target Milestone: --- → Firefox 31
Depends on: 997315
QA Whiteboard: [qa-]
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: