Closed
Bug 814430
Opened 12 years ago
Closed 12 years ago
Allowing offline mode to connect to loopback doesn't shutdown network on profile-change-net-teardown
Categories
(Core :: Networking, defect)
Tracking
()
VERIFIED
FIXED
mozilla20
People
(Reporter: AlexLakatos, Assigned: unusualtears)
References
Details
(Keywords: hang, regression)
Attachments
(2 files, 2 obsolete files)
301 bytes,
application/javascript
|
Details | |
2.89 KB,
patch
|
lsblakk
:
approval-mozilla-aurora+
akeybl
:
approval-mozilla-beta+
|
Details | Diff | Splinter Review |
The landing of bug 87717 https://hg.mozilla.org/mozilla-central/rev/c122628565e5 introduced a regression with our Mozmill tests, on Ubuntu 12.04. Whenever our tests use controller.startUserShutdown(), Firefox hangs on the next test. Attached is a minimized testcase to reproduce. Steps to Reproduce: 1.Install Mozmill as described in https://developer.mozilla.org/en-US/docs/Mozmill#Ubuntu 2.Unzip the minimizedTestcase archive into a directory and run "mozmill-restart -t path/to/minimizedTestcase/ -b path/to/latest/nightly" Expected Results: 3.The mozmill test runs and then closes Actual Results: 4.The mozmill test starts, restarts Firefox and then hangs, as in nothing is happening anymore, and Firefox remains opened.
Comment 1•12 years ago
|
||
This is a critical issue for us with our Mozmill tests. It keeps our testruns hanging on Firefox shutdown/restart. I can't tell details because I don't know the networking code that well. So I hope someone from the networking team can jump on it hopefully soon.
Blocks: 87717
Severity: normal → critical
tracking-firefox19:
--- → ?
tracking-firefox20:
--- → ?
Keywords: regression
Hardware: x86 → All
Summary: Allowing offline mode to connect to loopback introduced a regression in mozmill on linux → Allowing offline mode to connect to loopback introduced a regression in mozmill on linux and keeps testruns hanging on shutdown/restart of Firefox
Whiteboard: [mozmill-test-failure]
Version: unspecified → 19 Branch
Comment 2•12 years ago
|
||
Most likely the server.js module of JSBridge is the code which is affected here: https://github.com/mozilla/mozmill/blob/hotfix-1.5/jsbridge/jsbridge/extension/resource/modules/server.js
Reporter | ||
Comment 3•12 years ago
|
||
Attachment #684422 -
Attachment is obsolete: true
Reporter | ||
Comment 4•12 years ago
|
||
(In reply to Alex Lakatos[:AlexLakatos] from comment #3) > Created attachment 684450 [details] > minimized testcase Here are new Steps to Reproduce to match the new minimized testcase: 1.Install Mozmill as described in https://developer.mozilla.org/en-US/docs/Mozmill#Ubuntu 2.Download the minimizedTestcase and run "mozmill -t path/to/minimizedTestCase.js -b path/to/latest/nightly"
Comment 5•12 years ago
|
||
This minimized testcase works fine for me on my own Linux64 VM. No freeze can be observed. Alex, please work on bug 797389 to get a better testcase or an idea why not all Ubuntu64 systems are affected.
Comment 6•12 years ago
|
||
I quickly checked Mozmill and what I found so far is that we successfully restart Firefox but we can't connect anymore from the Python side to the browser via the bridge from localhost.
Summary: Allowing offline mode to connect to loopback introduced a regression in mozmill on linux and keeps testruns hanging on shutdown/restart of Firefox → Allowing offline mode to connect to loopback doesn't let Mozmill reconnect to the application after a restart
Updated•12 years ago
|
Whiteboard: [mozmill-test-failure] → [qa-automation-blocked]
Comment 7•12 years ago
|
||
Patrick - can you help the a-team out with this? Would also be good to understand why FF18 isn't called out as affected, given the target milestone of bug 87717.
Comment 8•12 years ago
|
||
I'm going to pass this on to the author of the regressing patch.
Assignee: mcmanus → unusualtears
Comment 9•12 years ago
|
||
fwiw I doubt this is very interesting for FF proper.
Comment 10•12 years ago
|
||
I missed to update this bug after my investigation early yesterday. So there should be two sides here. First, Mozmill needs a fix to gracefully handle a delayed disconnect of the back channel. Affected is the following code for Mozmill 1.5: https://github.com/mozilla/mozmill/blob/hotfix-1.5/mozmill/mozmill/__init__.py#L616 In the past `frame.runTestFile(test)` never returned but an exception was thrown which meant for us that Firefox shutdown or restarted itself. Now with the patch on the other bug landed this method returns normally. As result we handle an user shutdown/restart wrongly and are trying to stop the runner. Which is wrong. On the other side it means networking code has been changed in the Firefox product itself, which causes a delayed shutdown. Not sure what else could be affected here given that it is really hard to reproduce on other machines as the affected ubuntu 64bit one.
Assignee | ||
Comment 11•12 years ago
|
||
whimboo is correct in his analysis. I was able to reproduce this (on Debian x86_64). Prior to bug 87717 the network would go away entirely when offline, but in the patch it stopped going away except on shutdown. It should still go away on profile-change-net-teardown. This remedies that, and Mozmill will not hang. Pushed to try: https://tbpl.mozilla.org/?tree=Try&rev=10e26e037305
Attachment #686342 -
Flags: review?(mcmanus)
Comment 12•12 years ago
|
||
Wow, thanks Adam! That sounds reasonable. Is there a way to get a test for? If not we will be indeed able to have a test by Mozmill. Alex, I know you are able to reproduce this too on your Mozmill machine. Can you please check with the following try server build if it is fixed? https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/unusualtears@gmail.com-10e26e037305/
Flags: needinfo?(alex.lakatos)
Comment 13•12 years ago
|
||
Updating summary to better reflect what's going on here.
Summary: Allowing offline mode to connect to loopback doesn't let Mozmill reconnect to the application after a restart → Allowing offline mode to connect to loopback doesn't shutdown network on profile-change-net-teardown
Reporter | ||
Comment 14•12 years ago
|
||
(In reply to Henrik Skupin (:whimboo) from comment #12) > Alex, I know you are able to reproduce this too on your Mozmill machine. Can > you please check with the following try server build if it is fixed? > > https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/ > unusualtears@gmail.com-10e26e037305/ Tested the x86 build with my local machine. It passes and does not hang.
Flags: needinfo?(alex.lakatos)
Updated•12 years ago
|
Attachment #686342 -
Flags: review?(mcmanus) → review+
Comment 15•12 years ago
|
||
Patrick, can we get this landed so it will be part of tomorrows nightly?
Comment 16•12 years ago
|
||
(In reply to Henrik Skupin (:whimboo) from comment #15) > Patrick, can we get this landed so it will be part of tomorrows nightly? https://developer.mozilla.org/en-US/docs/Creating_a_patch_that_can_be_checked_in
Comment 17•12 years ago
|
||
(In reply to Patrick McManus [:mcmanus] from comment #16) > https://developer.mozilla.org/en-US/docs/ > Creating_a_patch_that_can_be_checked_in That's not that helpful. Is it only because of the missing 'r=mcmanus'? If that's the case I can add that and land it on inbound. Otherwise please tell me what's missing.
Comment 18•12 years ago
|
||
Also https://developer.mozilla.org/en-US/docs/Developer_Guide/How_to_Submit_a_Patch This is all for the patch author to do; that's not me.
Assignee | ||
Comment 19•12 years ago
|
||
Thanks, Patrick! Successful try: https://tbpl.mozilla.org/?tree=Try&rev=10e26e037305
Attachment #686342 -
Attachment is obsolete: true
Keywords: checkin-needed
Comment 20•12 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/e2fd9e9e3788
Keywords: checkin-needed
Comment 21•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/e2fd9e9e3788
Status: NEW → RESOLVED
Closed: 12 years ago
status-firefox20:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla20
Comment 22•12 years ago
|
||
Looks great on Linux64 and todays Nightly build. No abort happening anymore. Adam, can you please follow-up with all the necessary steps so we can land it on aurora too? Thanks. Todays testrun: http://10.250.73.243:8080/job/mozilla-central_functional/lastCompletedBuild/console
Status: RESOLVED → VERIFIED
Assignee | ||
Comment 23•12 years ago
|
||
Comment on attachment 686765 [details] [diff] [review] Ready for checkin [Approval Request Comment] Bug caused by (feature/regressing bug #): Bug 87717 User impact if declined: Broken Mozmill (hanging on certain tests) on Linux Testing completed (on m-c, etc.): m-i, m-c Risk to taking this patch (and alternatives if risky): None String or UUID changes made by this patch: None
Attachment #686765 -
Flags: approval-mozilla-aurora?
Updated•12 years ago
|
Attachment #686765 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
status-firefox20:
fixed → ---
Keywords: checkin-needed
Whiteboard: [qa-automation-blocked] → [qa-automation-blocked], push to aurora
Target Milestone: mozilla20 → ---
status-firefox20:
--- → fixed
Target Milestone: --- → mozilla20
Comment 24•12 years ago
|
||
https://hg.mozilla.org/releases/mozilla-aurora/rev/6952c37a602f
status-firefox19:
--- → fixed
Keywords: checkin-needed
Whiteboard: [qa-automation-blocked], push to aurora → [qa-automation-blocked]
Comment 25•12 years ago
|
||
All fine here for Nightly and Aurora. No aborts anymore. Thanks a lot!
Comment 26•11 years ago
|
||
We are also hitting this with Firefox 18 Beta. I totally missed that bug 87717 also landed for that release. So we have to backport this patch to mozilla-beta now. Adam, can you please take care of?
Assignee | ||
Comment 27•11 years ago
|
||
Comment on attachment 686765 [details] [diff] [review] Ready for checkin [Approval Request Comment] Bug caused by (feature/regressing bug #): Bug 87717 User impact if declined: Broken Mozmill (hanging on certain tests) on Linux Testing completed (on m-c, etc.): m-i, m-c, m-a Risk to taking this patch (and alternatives if risky): None String or UUID changes made by this patch: None
Attachment #686765 -
Flags: approval-mozilla-beta?
Updated•11 years ago
|
Attachment #686765 -
Flags: approval-mozilla-beta? → approval-mozilla-beta+
Updated•11 years ago
|
Keywords: checkin-needed
Whiteboard: [qa-automation-blocked] → [qa-automation-blocked], push to beta
Comment 28•11 years ago
|
||
https://hg.mozilla.org/releases/mozilla-beta/rev/8af1e554573b
Keywords: checkin-needed
Whiteboard: [qa-automation-blocked], push to beta → [qa-automation-blocked]
Comment 29•11 years ago
|
||
https://hg.mozilla.org/releases/mozilla-b2g18/rev/8af1e554573b
status-b2g18:
--- → fixed
Comment 30•11 years ago
|
||
No more aborts for Mozmill testruns with the latest Firefox 18.0 beta build. Marking as verified fixed!
Updated•11 years ago
|
Whiteboard: [qa-automation-blocked]
You need to log in
before you can comment on or make changes to this bug.
Description
•