|mach reftest| hangs when trying to run reftest on Fennec device build (poor reporting of network setup problems)

RESOLVED FIXED in Firefox 66

Status

()

defect
P1
normal
RESOLVED FIXED
7 months ago
7 months ago

People

(Reporter: botond, Assigned: gbrown)

Tracking

unspecified
Firefox 66
Points:
---

Firefox Tracking Flags

(firefox66 fixed)

Details

Attachments

(3 attachments)

When I try to run |mach reftest| to run a reftest on a Fennec device build, the browser opens on the device, but then the test hangs. The last line of output before the hang is:

REFTEST ERROR | EXCEPTION: [Exception... "Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIHttpChannel.responseStatus]" nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)" location: "JS frame :: resource://reftest/manifest.jsm :: ReadManifest :: line 55" data: no]

I attached the entire output.

Logcat from the device might be helpful.

Is it possible the device is not on wifi, or otherwise cannot make a network connection back to the host?

(In reply to Geoff Brown [:gbrown] from comment #2)

Is it possible the device is not on wifi, or otherwise cannot make a network connection back to the host?

Argh, sorry. I keep forgetting the devices need to be on the same network. That was indeed the problem.

I'll leave it up to you if you'd like to use this report to track giving a clearer error about this, or just close it.

No worries.

I'll see if I can improve the error.

Assignee: nobody → gbrown
Priority: -- → P1
Summary: |mach reftest| hangs when trying to run reftest on Fennec device build → |mach reftest| hangs when trying to run reftest on Fennec device build (poor reporting of network setup problems)

I think this fits in well with existing verify_android_device() functionality: just as most mach test commands want to ensure that a device is connected, that the test app is installed, that host-utils are available, let's also check the network.

Checking the network is unlikely to be useful when using an emulator -- let's not try to when the device-serial looks like an emulator.

Actually checking the network is potentially problematic. I'd kind-of like to ping the host from the device, but I worry about the availability of ping on Android, and whether it might vary in behavior across Android OS versions. Rather than add that dependency, I'm just pinging the device from the host, believing that usually, if the host can see the device, the device should be able to see the host.

If the device IP cannot be obtained or ping fails, mach reports a WARNING but doesn't fail. My reasoning here is that if the network is actually problematic, tests will fail quickly and the curious will look through scrollback and find the WARNINGs; on the other hand, if the network is good enough for tests to run but these new checks are failing inappropriately, the warnings won't get in anyone's way.

Attachment #9036752 - Flags: review?(bob)
Comment on attachment 9036752 [details] [diff] [review]
warn if unable to ping device from host, in mach, via verify_android_device

Review of attachment 9036752 [details] [diff] [review]:
-----------------------------------------------------------------

r+. lgtm though if we don't need the str(addr) let's remove it.

::: testing/mozbase/mozrunner/mozrunner/devices/android_device.py
@@ +320,5 @@
> +                if not addr:
> +                    _log_warning("unable to get Android device's IP address!")
> +                    _log_warning("tests may fail without network connectivity to the device!")
> +                else:
> +                    _log_info("Android device's IP address: %s" % str(addr))

is str(...) required?
Attachment #9036752 - Flags: review?(bob) → review+

str() is not required - will tidy. Thanks.

Pushed by gbrown@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/4c08e7df7398
Try to detect networking connectivity problems before running local tests on android; r=bc
Status: NEW → RESOLVED
Closed: 7 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 66
You need to log in before you can comment on or make changes to this bug.