Closed Bug 1431842 Opened 6 years ago Closed 6 years ago

Intermittent browser/components/resistfingerprinting/test/browser/browser_performanceAPI.js | leaked 2 window(s) until shutdown [url = http://example.net/browser/browser/components/resistfingerprinting/test/browser/file_dummy.html]

Categories

(Core :: Security, defect, P5)

Product:
Core
Component:
Security
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla60
Tracking Flags:
Tracking Status
firefox59 --- fixed
firefox60 --- fixed

People

(Reporter: intermittent-bug-filer, Assigned: tjr)

References

Details

(Keywords: intermittent-failure)

Attachments

(1 file)

Bug 1431842 Call worker.terminate() in browser_performanceAPI.js to (hopefully) fix an intermittent
59 bytes, text/x-review-board-request
bkelly
: review+
Details 
Filed by: csabou [at] mozilla.com

https://treeherder.mozilla.org/logviewer.html#?job_id=157369418&repo=autoland

https://queue.taskcluster.net/v1/task/C41HFtcjQCaK1oH1iunxZQ/runs/0/artifacts/public/logs/live_backing.log

05:17:13    ERROR -  138 ERROR TEST-UNEXPECTED-FAIL | browser/components/resistfingerprinting/test/browser/browser_performanceAPI.js | leaked 2 window(s) until shutdown [url = http://example.net/browser/browser/components/resistfingerprinting/test/browser/file_dummy.html]
05:17:13     INFO -  TEST-INFO | browser/components/resistfingerprinting/test/browser/browser_performanceAPI.js | windows(s) leaked: [pid = 7224] [serial = 52], [pid = 7224] [serial = 54]
05:17:13    ERROR -  139 ERROR TEST-UNEXPECTED-FAIL | browser/components/resistfingerprinting/test/browser/browser_performanceAPI.js | leaked 2 window(s) until shutdown [url = http://example.net/browser/browser/components/resistfingerprinting/test/browser/file_dummy.html]
05:17:13     INFO -  TEST-INFO | browser/components/resistfingerprinting/test/browser/browser_performanceAPI.js | windows(s) leaked: [pid = 7224] [serial = 58], [pid = 7224] [serial = 60]
05:17:13     INFO -  runtests.py | Application ran for: 0:00:34.548000
This was filed from, and so far has only been seen on, test-verify runs triggered by the landing of bug 1431455. That might mean it's test-verify only, that the test only leaks when run multiple times, or might mean we just haven't happened to hit it outside test-verify yet, and it might mean that it was caused by the patch for bug 1431455, or it might have been caused by bug 1424341 / bug 1431425 or it might have always existed, and we just hadn't run test-verify on this test before.
Blocks: 1431455
Flags: needinfo?(tom)
At a suggestion, I added a sleep in my test, and the failures seem to have gone away? (And 5 retries?)

https://treeherder.mozilla.org/#/jobs?repo=try&revision=01ee965ba6ef2733659dea15f9a1cedc1f1d9035
Actually, the above may have been a false alarm. After some fiddling, I can't get this to repro in Try at all

https://treeherder.mozilla.org/#/jobs?repo=try&revision=49df2c4217fdde73a59a900ae030d962aa91601f&selectedJob=157829782

I'm going to wait a day or two and see if this re-occurs. Clearing ni and will wait for Orange emails.
Flags: needinfo?(tom)
test-verify's too tricksy a beast to be caught out that easily: for your comment 4 push, it consulted https://hg.mozilla.org/try/json-automationrelevance/49df2c4217fdde73a59a900ae030d962aa91601f to find out what files were changed in that push, saw that no test files were modified, and thus ran against no tests and did nothing at all. To get a run against mozilla-central tip, you need to add a comment to browser/components/resistfingerprinting/test/browser/browser_performanceAPI.js and push that to try, so it knows what test to run against.
And when I looked at some of the logs to see which of test-verify's multiple steps was getting the failure like I should have in the first place, all the ones I looked at were either in the "Run each test 10 times in one browser" or the ultimate challenge "Run each test 10 times in one browser, in chaos mode" step, so good luck with recognizing the actual failures when they come in: those steps are intended to catch out tests which leave state behind and then trip over themselves when they have to run in the dirty browser they leave behind, and what you get in the natural world from that is not a failure in the test leaving its toys on the floor, but instead a failure in some later test which doesn't check initial state (or, can't, because you can't really check for a unexpected timer that isn't yours but is going to fire while you are running). Maybe the failure in the wild would actually wind up here, or maybe it would be a leaked-until-shutdown but blamed on whichever resistfingerprinting test is the last one which opens a http://example.net/browser/browser/components/resistfingerprinting/test/browser/file_dummy.html, or maybe (I didn't look), this or another of the resistfingerprinting tests which opens a file_dummy.html makes some changes to its content and then another test will wind up confused by seeing that file_dummy.html and thinking that it is its own or that some message being produced by that one is being produced by its own.

Or, and this is much more likely than any of those, browser_performanceAPI.js only leaks those windows until shutdown when it is the last thing to run before shutdown, and you wouldn't see any natural failures at all until long after this bug has been resolved incomplete, when someone decides to either rename all the test files, or shuffle them around into separate directories, or adds so many new tests that resistfingerprinting gets split across two chunks, or just changes the way we set the order that tests run in, and this test is suddenly the last one to run in a chunk.
Okay, I reproduced this first try here: https://treeherder.mozilla.org/#/jobs?repo=try&revision=b77f90aabdc4e46dd56095eb4c6b85463e7ca6d6&selectedJob=157913713

Only one test was run in TV (this one) and it repro-ed first try.

Then I took one guess at what the issue may be, and ran it here: https://treeherder.mozilla.org/#/jobs?repo=try&revision=c417364f4cb474f16f0f95d277f33aca9c49461c&selectedJob=158030867

Only one test was run in TV (this one) and it never repro-ed.




I don't know if this fixes it but I guess I'd like to land it and see if it helps?
Comment on attachment 8944849 [details]
Bug 1431842 Call worker.terminate() in browser_performanceAPI.js to (hopefully) fix an intermittent

https://reviewboard.mozilla.org/r/215006/#review220628
Attachment #8944849 - Flags: review?(bkelly) → review+
Assignee: nobody → tom
Pushed by ryanvm@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/0b9045d5d664
Call worker.terminate() in browser_performanceAPI.js to (hopefully) fix an intermittent r=bkelly
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/0b9045d5d664
Status: NEW → RESOLVED
Closed: 6 years ago
status-firefox60: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla60
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: