Closed Bug 763894 Opened 12 years ago Closed 9 years ago

Intermittent test_bug343416.xul | The idle time should have increased by roughly the amount of time it took for the timeout to fire. You didn't touch the mouse or keyboard during the test did you?

Categories

(Core :: Widget, defect)

Product:
Core
Component:
Widget
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
firefox15 --- affected
firefox16 --- affected
firefox17 --- affected

People

(Reporter: emorley, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: intermittent-failure, Whiteboard: [leave open])

+++ This bug was initially created as a clone of Bug #517482 +++ Lot of bug 517482 has been a different failure. Breaking out for clarity. edmorley https://tbpl.mozilla.org/php/getParsedLog.php?id=12585413&tree=Firefox Rev3 WINNT 5.1 mozilla-central pgo test mochitest-other on 2012-06-12 04:45:16 slave: talos-r3-xp-048 32761 ERROR TEST-UNEXPECTED-FAIL | chrome://mochitests/content/chrome/widget/tests/test_bug343416.xul | The idle time should have increased by roughly the amount of time it took for the timeout to fire. You didn't touch the mouse or keyboard during the test did you?
Blocks: 343416
Depends on: 779066
(In reply to TinderboxPushlog Robot from comment #355) > timeDiff should have been under 1000, but was 1003. Fuzzy math wasn't very fuzzy, was he?
I find it fascinating that WinXP PGO (not non-PGO, which has hit this something like 3 times to PGO's 350) both has trouble with this, and as https://tbpl.mozilla.org/?tree=Try&rev=e7bd84f2366e shows is generally horribly unreliable, but not fascinating enough to keep starring this. Increased the fuzz to 1500ms (though 1200 would probably have done) in https://tbpl.mozilla.org/?tree=Try&rev=e7bd84f2366e.
Whiteboard: [orange] → [orange][leave open]
(In reply to Phil Ringnalda (:philor) from comment #363) > Increased the fuzz to 1500ms (though 1200 would probably have done) in > https://tbpl.mozilla.org/?tree=Try&rev=e7bd84f2366e. https://hg.mozilla.org/integration/mozilla-inbound/rev/d04dd4660c54 Thank you philor :-)
Copy-paste is hard.
No, I didn't touch the mouse, test_mozFrameType.xul did - those are not instances of this, they are just fallout from a defective test failing to clean itself up.
Whiteboard: [orange][leave open] → [leave open]
Another XP clock skew bug?
Gijs, it seems you wrote this test. Care to review it again?
Flags: needinfo?(gijskruitbosch+bugs)
(In reply to Avi Halachmi (:avih) from comment #446) > Gijs, it seems you wrote this test. Care to review it again? Not particularly. As I recall, this is just a question of "how reliable are our timers" and "is nobody messing with keyboard or mouse input while the test runs". It's possible there's also a factor of "did the wall clock time do a strange thing while we ran the test" but that seems strange and very unlikely, considering it's about a 5s interval. From looking at the tbpl robot comments, it also seems this fails roughly once a month, which doesn't sound like something we should prio, considering how many tests we have that fail much more often.
Flags: needinfo?(gijskruitbosch+bugs)
The last 5 failures were a month apart or more. Let's leave it as is unless the frequency go up?
I was thinking we'd give it the jib treatment and just skip the test on XP.
That's an option. Let's consider it if the frequency increases.
How painful is it to leave this test on with ~1/month failure rate? From my perspective, I think it's better to have a test which fails once a month than not having the test running at all, but I don't know the cost of leaving it running. Ryan, your call, if it creates too much pain, we should remove it IMO.
Flags: needinfo?(ryanvm)
(In reply to Avi Halachmi (:avih) from comment #453) > How painful is it to leave this test on with ~1/month failure rate? > > From my perspective, I think it's better to have a test which fails once a > month than not having the test running at all, but I don't know the cost of > leaving it running. > > Ryan, your call, if it creates too much pain, we should remove it IMO. I think disabling it on XP only isn't going to make much of a difference, as I believe the same code runs for all of Windows, so if we have coverage on win7 and win8, we can live with that, I think...
This is perma-failing on inbound at the moment, so looks like real bustage. We're waiting on a previously-coalesced Windows build retrigger to confirm the cause.
Flags: needinfo?(ryanvm)
This was traced to bug 981251, which has now been backed out.
See Also: → 1080100
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.