Closed Bug 1090198 Opened 5 years ago Closed 3 years ago

Intermittent e10s 014.html | WebSockets: serialize establish a connection - assert_greater_than: expected a number greater than 998 but got 979

Categories

(Core :: DOM: Workers, defect, P5)

x86
Windows XP
defect

Tracking

()

RESOLVED FIXED
mozilla55
Tracking Status
e10s + ---
firefox34 --- unaffected
firefox35 --- unaffected
firefox36 --- wontfix
firefox37 --- wontfix
firefox38 --- affected
firefox39 --- affected
firefox40 --- affected
firefox-esr31 --- unaffected
firefox-esr52 --- fixed
firefox54 --- fixed
firefox55 --- fixed

People

(Reporter: cbook, Assigned: jgraham)

References

(Blocks 1 open bug, )

Details

(Keywords: intermittent-failure, Whiteboard: [stockwell disabled])

Windows XP 32-bit mozilla-inbound opt test web-platform-tests-4

https://treeherder.mozilla.org/ui/logviewer.html#?job_id=3352698&repo=mozilla-inbound

05:37:27 INFO - TEST-UNEXPECTED-FAIL | /websockets/constructor/014.html | WebSockets: serialize establish a connection - assert_greater_than: expected a number greater than 998 but got 979
Component: General → Networking: WebSockets
Blocks: 504553
Component: Networking: WebSockets → DOM: Workers
given that this is new today in the websockets code is this caused by 1090170?
Blocks: 1090170
Flags: needinfo?(amarchesini)
These tests were only enabled in production on Windows today, so it might be an older issue that doesn't affect linux. Notice that the tolerance of the test seems rather small. I wonder if the problem is just timer accuracy on Windows and whether having a larger tolerance and/or switching to high resolution time would help.
(In reply to James Graham [:jgraham] from comment #22)
> These tests were only enabled in production on Windows today, so it might be
> an older issue that doesn't affect linux. Notice that the tolerance of the
> test seems rather small. I wonder if the problem is just timer accuracy on
> Windows and whether having a larger tolerance and/or switching to high
> resolution time would help.

what bug enabled them?

but yes - I would just make the tolerances in the test more obvious. Websockets in gecko just has the responsibility for making sure they don't overlap and so doesn't even use a timer for this case... 

e.g. make the sleep 1.25s instead of 1s
No longer blocks: 504553, 1090170
james - can we patch those tests asap (36 oranges in 2 days) or disable again if they need to be coordinated with upstream..
Flags: needinfo?(amarchesini) → needinfo?(james)
Disabled on XP in https://hg.mozilla.org/integration/mozilla-inbound/rev/262e4847ad6c
Flags: needinfo?(james)
https://hg.mozilla.org/mozilla-central/rev/262e4847ad6c
Assignee: nobody → james
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
seems its still happening :(
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Andrea, do you have time to look into this pretty frequent WebSockets test failure?
Flags: needinfo?(amarchesini)
Target Milestone: mozilla36 → ---
I would propose to increase the tolerance of this test based on comment 28. Maybe 1.5/2 secs?
Flags: needinfo?(amarchesini) → needinfo?(james)