Closed Bug 1035678 Opened 10 years ago Closed 9 years ago

Intermittent browser_dbg_split-console-paused-reload.js | Test timed out

Categories

(DevTools :: Debugger, defect)

defect
Not set
normal

Tracking

(firefox31 unaffected, firefox32 fixed, firefox33 fixed, firefox-esr24 unaffected)

RESOLVED WORKSFORME
Firefox 33
Tracking Status
firefox31 --- unaffected
firefox32 --- fixed
firefox33 --- fixed
firefox-esr24 --- unaffected

People

(Reporter: cbook, Unassigned)

References

(Blocks 1 open bug, )

Details

(Keywords: intermittent-failure)

Rev4 MacOSX Snow Leopard 10.6 mozilla-inbound opt test mochitest-devtools-chrome on 2014-07-07 20:38:20 PDT for push e32b472f55c9

slave: t-snow-r4-0063

https://tbpl.mozilla.org/php/getParsedLog.php?id=43307128&tree=Mozilla-Inbound

TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/devtools/debugger/test/browser_dbg_split-console-paused-reload.js | Test timed out
Assignee: nobody → past
Status: NEW → ASSIGNED
OS: Mac OS X → All
Hardware: x86 → All
The patch in bug 1016310 should fix this.
Depends on: 1016310
Bug 1016310 landed, so closing this as well.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 33
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I don't have time to look at this in the near future.
Assignee: past → nobody
Blocks: dbg-test
This got hella-frequent in the last couple days. Any ideas, Eddy?
Flags: needinfo?(ejpbruel)
I did some retriggers on 
https://treeherder.mozilla.org/#/jobs?repo=fx-team&filter-searchStr=Ubuntu VM 12.04 fx-team  debug test mochitest-devtools-chrome-1
to see when this started.  I'm suspicious of https://hg.mozilla.org/integration/fx-team/rev/a752e16a5251 .
Although it doesn't appear as frequent on retriggers as it did right after starting again, I'm reasonably confident this is a regression from:
https://hg.mozilla.org/integration/fx-team/rev/a752e16a5251
based on:
https://treeherder.mozilla.org/#/jobs?repo=fx-team&revision=a752e16a5251
and the previous revision:
https://treeherder.mozilla.org/#/jobs?repo=fx-team&revision=bf843cab375a
After taking a quick look at both my patch and that test, I'd say it's unlikely that my patch affects this tests directly. The patch refactors breakpoint sliding for *sourcemapped* sources, and this is a non-sourcemapped code, for which we don't use the refactored code path at all.

That said, it's conceivable that my patch changes some timings, or added an asynchronous step that wasn't there before, but in that case the test would have to be inherently racy. I've been unable to find a race in the test so far, but I'll try to hunt a bit deeper.
I think I know what's going on here. We're trying to set a breakpoint on a top level script. That's a gc sensitive operation. If the top level script has not yet been gcd, all is well. If the top level script *has* been gcd, we can't tell the difference between the script being gcd, or the user trying to set a breakpoint on a line with no code, so we try to perform breakpoint sliding.

The patch that dbaron referred to changes actualLocation from originalLine to originalLine + 1. That's fine, but there's a bug a bit further below. We assume that if actualLocation === lineToEntryPoints.length that breakpoint sliding failed, and return the original location. However, I figured out during testing that if the top level script has been gcd, and theres an inner script above the point where you're trying to set the breakpoint (which is the case here), then actualLocation can actually start out being larger than lineToEntryPoints.length, so the check *should* be actualLocation >= lineToEntryPoints.length.

Without that fix, the line breakpoint sliding algorithm incorrectly thinks that it has succeeded, and updates the breakpoint location to the actual location, which was originalLine + 16, hence 17. When the page is refreshed, we try to reset the breakpoint on the new location, which is line 17, but should be line 16.

The good news is I already have a fix for this in bug 1147972. Once the patch from comment 26 lands, this problem should go away.
Flags: needinfo?(ejpbruel)
Looks like whatever you did worked for trunk. Please do the same for Aurora as soon as you possibly can :)
Flags: needinfo?(ejpbruel)
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #457)
> Looks like whatever you did worked for trunk. Please do the same for Aurora
> as soon as you possibly can :)

I've requested uplift to Aurora for the patch that fixes the issue. Sorry it took so long; I was on vacation for the last two weeks.
Flags: needinfo?(ejpbruel)
Inactive; closing (see bug 1180138).
Status: REOPENED → RESOLVED
Closed: 10 years ago9 years ago
Resolution: --- → WORKSFORME
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.