Closed Bug 1565833 Opened 2 years ago Closed 2 years ago

Perma browser_aboutdebugging_devtoolstoolbox_reload.js | leaked 2 window(s) until shutdown when Gecko 70 merges to Beta on 2019-08-26


(DevTools :: about:debugging, defect)

Not set


(firefox-esr60 unaffected, firefox-esr68 unaffected, firefox68 unaffected, firefox69 unaffected, firefox70+ verified)

Firefox 70
Tracking Status
firefox-esr60 --- unaffected
firefox-esr68 --- unaffected
firefox68 --- unaffected
firefox69 --- unaffected
firefox70 + verified


(Reporter: CosminS, Assigned: jdescottes)



(Keywords: regression)


(2 files)

[Tracking Requested - why for this release]:
Central as beta simulation:

Failure log:

Even though the initial cause for these failures in tree (Bug 1354679) was backed out here and was merged to central a few hrs later, these failures still happen on beta sims.
The tests are green on integration trees.
Our hunch is Bug 1560178 and the changes here:
Gijs, Aryx could you please take a look over this and see why this happens? Thanks.

Flags: needinfo?(gijskruitbosch+bugs)

It looks like in you backed out only the "tweak pause overlay" changeset, but bug 1544828 was filed immediately after 6363111ee8ce ("Automatically display the PausedDebuggerOverlay when the debugger is paused.") landed, and that doesn't look like it's been backed out?

Flags: needinfo?(csabou)

And e.g. and are after the backout and still orange. I don't know if the frequency has really gone down, it'll probably be hard-ish to tell until the weekend is over and normal push frequency resumes.

Closed: 2 years ago
Flags: needinfo?(gijskruitbosch+bugs)
Flags: needinfo?(csabou)
Resolution: --- → FIXED

Hi, do you have an intermittent view of the failures? I'd like to see which platforms (or all) it was failing on and under what modes presumably debug...

Jason, this was filled as a beta-sim bug and is normally stared on tree as expected fail so no intermittent failures view.
But here's a failure rate from Bug 1544828 which is I think the same only for integration trees:
It fails mostly on linux64 debug: and sometimes on macosx1014-64 debug:

Flags: needinfo?(aryx.bugmail)
Resolution: FIXED → ---
Flags: needinfo?(jlaster)

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Keywords: regression
Flags: needinfo?(aryx.bugmail)

Hi, I'm a bit confused... I don't see any failures for this test on TRY or Central. I also can't reproduce this error locally in debug mode on osx. The test is extremely slow (requestLongerTimeout(5);) so it is very tough to get meaningful data...

Do you have a good report where I can see the failures?

Flags: needinfo?(jlaster)

I had a try run last week with 50+ runs and no leaks, which seemed to confirm that the overlay was not to blame. comment

Here is a new try run on top of master with the overlay. I'm only testing the aboutdebugging directory because I want to have as many runs as possible:

(In reply to Jason Laster [:jlast] from comment #12)

Hi, I'm a bit confused... I don't see any failures for this test on TRY or Central

As comment #0 points out, this is about what happens when central merges to beta. It doesn't look like your trypushes contain the relevant changes to test that configuration. You can probably import something like to do the same kind of tests.

It's likely something about the debugger or what is being debugged is nightly-only and so this test behaves differently in a beta configuration.

You can get the beta simulation by running the command from but append --no-push to not run everything but hg commit the changes and run ./mach try chooser to pick the needed ones.

The test that is causing the issues was recently disabled for linux debug link. Do you think it is reasonable to disable for debug? The test is already using requestLongerTimeout(5); and is known for timeouts and OOMs, i'm not too surprised that it would leak in a failure.

Flags: needinfo?(jmaher)
Flags: needinfo?(jdescottes)
Flags: needinfo?(aryx.bugmail)

(In reply to Jason Laster [:jlast] from comment #16)

The test that is causing the issues was recently disabled for linux debug link.

Yes it was recently disabled on Linux debug. The perma fail for this test on debug mode started with Bug 1354679 (pause overlay). We should investigate why the debugger now leaks windows on reload.

Do you think it is reasonable to disable for debug?

We tried to do that in, but it made the next test in the suite timeout (no idea why).
Either we skip this test and the next one in debug (potentially others? to confirm with a try push), or we fix the debugger leak that started with Bug 1354679.

Flags: needinfo?(jdescottes)

I also don't know if we really have an issue specific to the beta simulation or not here. There has been movement on both Bug 1354679 and Bug 1544828, so it's hard to say at the moment. I kicked a few try runs, we'll see how it goes:

Flags: needinfo?(jmaher)

I will take the bug for now.

Assignee: nobody → jdescottes

Quick update to say that there is definitely something wrong linked with this test + beta simulation:

This avoids intermittent leaks in aboutdebugging tests relying on about:devtools-toolbox

Depends on D39174
Seems to fix the perma fail on beta

The patches attached here should fix the issue on beta osx debug:

The approach here is to wait for toolbox requests to be finished before reloading the toolbox and shutting down about:devtools-toolbox.
I still don't really know why the debugger patch regressed this (and I checked that the beta simulations were only perma-failing with Bug 1354679). My guess is that the debugger's initialization is not properly waiting for everything to be done before emitting the "ready" event and that should ideally be fixed. But for now that should be enough.

See Also: → 1568756
Pushed by
Wait for debugger-client requests to settle before closing the toolbox r=remote-debugging-reviewers,Ola,daisuke
Wait for requests to settle before reloading about:devtools-toolbox in tests r=remote-debugging-reviewers,Ola,daisuke
Flags: needinfo?(aryx.bugmail)
Closed: 2 years ago2 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 70
You need to log in before you can comment on or make changes to this bug.