Closed Bug 1432246 Opened 4 years ago Closed 4 years ago
test-verify job intermittently leaks safebrowsing things
I've been testing some patches (they touch some webrender-only gfx codepaths) and I'm getting intermittent test-verify job failures due to leaks.  is an example. Based on the leaked objects and URL, mccr8 theorized that the safebrowsing code was probably running at the time that the tests finished, and when the browser shut down the safebrowsing code wasn't done cleaning up, resulting in the leaks. That seems like a reasonable explanation to me, because that would explain why these leaks don't show up in the regular reftests and why I'm unable to reproduce the leaks locally. Note that the URL being leaked is http://127.0.0.1/safebrowsing-dummy/update - that is the "dummy" URL from , where the comment says "Point the url-classifier to the local testing server for fast failures". Note in particular it doesn't claim to disable the safebrowsing code, it just tries to make it fail faster in the test environment. It's quite possible that in this case it's not fast enough.  https://treeherder.mozilla.org/logviewer.html#?job_id=157755585&repo=try&lineNumber=3187  https://searchfox.org/mozilla-central/rev/b7e3ec2468d42fa59d86c03ec7afeb209813f1d4/testing/profiles/prefs_general.js#109
One thing I notice is that this only seems to happen when verifying reftests (including plain reftests, crashtests, jsreftests) -- never (rarely?) when verifying mochitests or other test categories. The leak seems to happen during a variety of verification steps: It is not strongly correlated with any particular verification step. It also seems to be more frequent for certain tests: perhaps skipped tests?
There was some discussion about safe-browsing prefs in bug 1405165. Generally, I think the reftest prefs are OK as they are, but this makes 3 refinements: - set browser.safebrowsing.downloads.enabled = false, supposedly a "nice to have" / safeguard - set plugins.show_infobar = false, even though it should be that by default - use distinct values for each browser.safebrowsing.provider.... pref, so that if leaks continue we'll at least know which pref is related I have not been able to reproduce this leak on try, despite several attempts to verify tests that previously caused frequent leaks. For instance, contrast https://treeherder.mozilla.org/#/jobs?repo=autoland&revision=1118b9ce86332ab739764b22ba7bb4eb5029435f&filter-searchStr=verify and https://treeherder.mozilla.org/#/jobs?repo=try&revision=5452d58f125144fad3bf739a306a329a823e3588 I have no explanation. I'd like to get this checked-in, leave this bug open and see if failures continue.
Assignee: nobody → gbrown
Attachment #8951245 - Flags: review?(jmaher)
Comment on attachment 8951245 [details] [diff] [review] update some safe-browsing prefs used during reftests Review of attachment 8951245 [details] [diff] [review]: ----------------------------------------------------------------- good idea on the unique urls
Attachment #8951245 - Flags: review?(jmaher) → review+
Thanks. Also, meant to note that this doesn't break reftests on try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=84c97b27c6e43e8b8a01ea6cc6c66b26a7fd36de
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/9c6d7da0f083 Update some safe-browsing prefs for reftests; r=jmaher
I don't know if my prefs changes made a difference or not. Regardless, I haven't seen a related failure in the last 2 weeks.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.