Closed Bug 806253 Opened 7 years ago Closed 7 years ago

Reftest needs to set prefs to disable blocklist updates, to avoid having them reported as leaks when they are still running at shutdown

Categories

(Testing :: Reftest, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED
mozilla19

People

(Reporter: philor, Assigned: philor)

Details

Attachments

(1 file)

https://tbpl.mozilla.org/php/getParsedLog.php?id=16539319&tree=Firefox is a crashtest run which leaked the world, where the world ends with https://addons.mozilla.org/blocklist/3/%7Bec8030f7-c20a-464f-9b0e-13a3a9e97384%7D/19.0a1/Firefox/20121028140038/Linux_x86_64-gcc3/en-US/default/Linux%202.6.31.5-127.fc12.x86_64%20(GTK%202.18.9)/default/default/1/1/new/ (and ocsp, which someday I need to learn enough about to learn whether we can disable it, since we're probably hitting the network for it from every test suite).

"extensions.blocklist.enabled", false should put a stop to fetching it.
Attached patch FixSplinter Review
Attachment #676008 - Flags: review?(dbaron)
Comment on attachment 676008 [details] [diff] [review]
Fix

r=dbaron, but is there a bug filed on this leak?  (Could you cite the bug number in the comment?)

Or does "leak" have a different meaning from what I think it does?
Attachment #676008 - Flags: review?(dbaron) → review+
Good point, this is probably more like what I mean.
Summary: Reftest needs to set prefs to disable blocklist updates, to avoid leaking them → Reftest needs to set prefs to disable blocklist updates, to avoid having them reported as leaks when they are still running at shutdown
But, I don't know. I don't have any special (or even non-special) knowledge of network, or of PSM, or of the blocklist updater, or of the leak logging code, to say whether this leak means that when verisign isn't responding, we leak 600Kb for the lifetime of the browser run, or until the next update attempt, or whether it means that we just happened to start a blocklist update a hundredth of a second before shutdown and everything is absolutely fine, or the blocklist updater isn't behaving properly during shutdown.

The things I do know are that it's not up to the reftest harness to test blocklist updates, and that it's my job to stop test harnesses from hitting the network.

There's apparently some seekrit something that's going to test hitting the network, with some name about rocks, maybe that'll find out.

https://hg.mozilla.org/integration/mozilla-inbound/rev/eca4483a58cf
https://hg.mozilla.org/mozilla-central/rev/eca4483a58cf
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: in-testsuite-
Resolution: --- → FIXED
Target Milestone: --- → mozilla19
You need to log in before you can comment on or make changes to this bug.