Closed Bug 1131725 Opened 10 years ago Closed 10 years ago

Intermittent run-by-dir test_9999_cleanup.xul | application crashed [@ nsSocketTransport::InitiateSocket()] from "FATAL ERROR: Non-local network connections are disabled and a connection attempt to aus4.mozilla.org (63.245.217.219) was made."

Categories

(Toolkit :: Application Update, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla38
Tracking Status
firefox36 --- unaffected
firefox37 --- unaffected
firefox38 --- fixed
firefox-esr31 --- unaffected

People

(Reporter: RyanVM, Assigned: robert.strong.bugs)

References

Details

(Keywords: intermittent-failure)

Attachments

(1 file, 1 obsolete file)

04:03:29 INFO - 3406 INFO TEST-START | toolkit/mozapps/update/tests/chrome/test_9999_cleanup.xul 04:03:29 INFO - ++DOMWINDOW == 211 (0x99d8d6d0) [pid = 11418] [serial = 692] [outer = 0x9cd9a4f0] 04:03:29 INFO - 04:03:29:298 | TEST-INFO | chrome://mochitests/content/chrome/toolkit/mozapps/update/tests/chrome/test_9999_cleanup.xul | [runTest : 34] entering 04:03:29 INFO - 04:03:29:309 | TEST-INFO | chrome://mochitests/content/chrome/toolkit/mozapps/update/tests/chrome/utils.js | [removeDirRecursive : 1075] attempting to remove directory. Path: /tmp/tmpv1fbi8.mozrunner/appupdateprep 04:03:29 INFO - 04:03:29:311 | TEST-INFO | chrome://mochitests/content/chrome/toolkit/mozapps/update/tests/chrome/utils.js | [resetAddons : 2207] entering 04:03:30 INFO - 3407 INFO TEST-OK | toolkit/mozapps/update/tests/chrome/test_9999_cleanup.xul | took 1144ms 04:03:30 INFO - ++DOMWINDOW == 212 (0x99d8e080) [pid = 11418] [serial = 693] [outer = 0x9cd9a4f0] 04:03:30 INFO - ++DOMWINDOW == 213 (0x99d8e270) [pid = 11418] [serial = 694] [outer = 0x9cd9a4f0] 04:03:30 INFO - --DOCSHELL 0x9e96a000 == 15 [pid = 11418] [id = 3] 04:03:31 INFO - ###!!! [Parent][OnMaybeDequeueOne] Error: Channel closing: too late to send/recv, messages will be lost 04:03:31 INFO - FATAL ERROR: Non-local network connections are disabled and a connection attempt to aus4.mozilla.org (63.245.217.219) was made. 04:03:31 INFO - You should only access hostnames available via the test networking proxy (if running mochitests) or from a test-specific httpd.js server (if running xpcshell tests). Browser services should be disabled or redirected to a local server. 04:03:31 INFO - Hit MOZ_CRASH(Attempting to connect to non-local address!) at /builds/slave/b2g-in-lx-d-000000000000000000/build/src/netwerk/base/nsSocketTransport2.cpp:1226
Since TH appears to be having problems commenting in the bug: https://treeherder.mozilla.org/logviewer.html#?job_id=1323825&repo=b2g-inbound
as per irc, this specific test file exists to cleanup the other tests in this directory, so in run-by-dir mode this test is not needed at all. While this sounds hacky it really acts as an optimization for the previous tests in the directory so we don't have to install/uninstall the same addons over and over again.
Attached patch patch (obsolete) — Splinter Review
I think I see what is going on here and this patch should fix it. Basically, resetPrefs was called without setupPrefs being called beforehand. This removed the app.update.enabled user pref and since the app's default is true update checks would happen when the timer manager notified app update.
Assignee: nobody → robert.strong.bugs
Status: NEW → ASSIGNED
Attachment #8562465 - Flags: review?(spohl.mozilla.bugs)
Comment on attachment 8562465 [details] [diff] [review] patch Review of attachment 8562465 [details] [diff] [review]: ----------------------------------------------------------------- ::: toolkit/mozapps/update/tests/chrome/test_9999_cleanup.xul @@ +43,5 @@ > closeUpdateWindow(); > + // Always leave the app.update.enabled and app.update.staging.enabled > + // preferences set to false when cleaning up. > + if (!Services.prefs.prefHasUserValue(PREF_APP_UPDATE_ENABLED) || > + Services.prefs.getBoolPref(PREF_APP_UPDATE_ENABLED)) { Could we just unconditionally set the PREF_APP_UPDATE_ENABLED and PREF_UPDATE_STAGING_ENABLED prefs to false, without the |if| blocks? @@ -40,2 @@ > > - resetPrefs(); Did you mean to remove resetPrefs, or did you mean to set PREF_APP_UPDATE_LOG, PREF_APP_UPDATE_ENABLED and PREF_UPDATE_STAGING_ENABLED after calling resetPrefs? @@ +50,5 @@ > > + if (!Services.prefs.prefHasUserValue(PREF_APP_UPDATE_STAGING_ENABLED) || > + Services.prefs.getBoolPref(PREF_APP_UPDATE_STAGING_ENABLED)) { > + Services.prefs.setBoolPref(PREF_APP_UPDATE_STAGING_ENABLED, false); > + } Do we need to reset the PREF_APP_UPDATE_ENABLED and PREF_UPDATE_STAGING_ENABLED prefs to their previous values at the end of this test?
Attachment #8562465 - Flags: review?(spohl.mozilla.bugs)
Yes. Meant to remove. No.
Attachment #8562465 - Flags: review?(spohl.mozilla.bugs)
Comment on attachment 8562465 [details] [diff] [review] patch Review of attachment 8562465 [details] [diff] [review]: ----------------------------------------------------------------- Cool. r+ with the removal of the two |if| blocks then. Thanks!
Attachment #8562465 - Flags: review?(spohl.mozilla.bugs) → review+
Attachment #8562465 - Attachment is obsolete: true
Attachment #8562490 - Flags: review+
Target Milestone: --- → mozilla38
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: