Closed Bug 1083279 Opened 10 years ago Closed 10 years ago

mach: Exception: Binary expected... when trying to run reftests locally

Categories

(Firefox Build System :: Android Studio and Gradle Integration, defect)

All
Android
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
mozilla36

People

(Reporter: miketaylr, Assigned: nalexander)

References

Details

Attachments

(2 files)

Trying to follow along at https://wiki.mozilla.org/Mobile/Fennec/Android#Reftests, but it seems like build_obj.get_binary_path() is assuming a desktop-runnable fennec binary.


Bug 854545 was the closest thing I could find to this error.

mtaylor at omg-4 in ~/dev/fennec/gecko-dev on 1082757/1
$ echo $DM_TRANS
adb
mtaylor at omg-4 in ~/dev/fennec/gecko-dev on 1082757/1
$ echo $MOZ_HOST_BIN
/Users/mtaylor/dev/fennec/bin
mtaylor at omg-4 in ~/dev/fennec/gecko-dev on 1082757/1
$ echo $TEST_PATH
layout/reftests/forms/reftest.list
mtaylor at omg-4 in ~/dev/fennec/gecko-dev on 1082757/1
$ ./mach reftest
 0:00.26 /usr/bin/make -C . -j8 -s -w reftest
 0:00.43 make: Entering directory `/Users/mtaylor/dev/fennec/gecko-dev/obj-arm-linux-androidabi'
 0:00.81 Traceback (most recent call last):
 0:00.81   File "_tests/reftest/runreftest.py", line 791, in <module>
 0:00.81     main()
 0:00.81   File "_tests/reftest/runreftest.py", line 762, in main
 0:00.81     parser = ReftestOptions()
 0:00.81   File "_tests/reftest/runreftest.py", line 624, in __init__
 0:00.81     default = build_obj.get_binary_path() if build_obj else None,
 0:00.81   File "/Users/mtaylor/dev/fennec/gecko-dev/python/mozbuild/mozbuild/base.py", line 342, in get_binary_path
 0:00.81     raise Exception('Binary expected at %s does not exist.' % path)
 0:00.81 Exception: Binary expected at /Users/mtaylor/dev/fennec/gecko-dev/obj-arm-linux-androidabi/dist/bin/fennec does not exist.
 0:00.83 make: Leaving directory `/Users/mtaylor/dev/fennec/gecko-dev/obj-arm-linux-androidabi'
mtaylor at omg-4 in ~/dev/fennec/gecko-dev on 1082757/1
$ TEST_PATH=$TEST_PATH make -C obj-arm-linux-androidabi/ reftest-remote
Traceback (most recent call last):
  File "_tests/reftest/remotereftest.py", line 539, in <module>
    sys.exit(main(sys.argv[1:]))
  File "_tests/reftest/remotereftest.py", line 449, in main
    parser = RemoteOptions(automation)
  File "_tests/reftest/remotereftest.py", line 24, in __init__
    ReftestOptions.__init__(self)
  File "/Users/mtaylor/dev/fennec/gecko-dev/layout/tools/reftest/runreftest.py", line 624, in __init__
    default = build_obj.get_binary_path() if build_obj else None,
  File "/Users/mtaylor/dev/fennec/gecko-dev/python/mozbuild/mozbuild/base.py", line 342, in get_binary_path
    raise Exception('Binary expected at %s does not exist.' % path)
Exception: Binary expected at /Users/mtaylor/dev/fennec/gecko-dev/obj-arm-linux-androidabi/dist/bin/fennec does not exist.
/bin/sh: @errors=: command not found

I'm able to run robocop tests, so MOZ_HOST_BIN is set up correctly.
I'm not sure if you can use mach to run Android reftests locally, but your make command certainly looks valid, and I can reproduce that problem. 

I think this is a regression from bug 915865; I am able to run "make reftest-remote" locally if I backout 199775c34d69.
Blocks: 915865
:ted -- Do you know what went wrong / how to fix this?
Flags: needinfo?(ted)
This is a regression from bug 915865:
http://hg.mozilla.org/mozilla-central/annotate/4c449dcda453/layout/tools/reftest/runreftest.py#l624

Apparently get_binary_path doesn't work properly in Fennec builds (it's sort of meaningless there, I suppose).

We can either hack get_binary_path to just return some fake value in Fennec builds, or tweak this code to only call get_binary_path when we're not targeting Android.
Flags: needinfo?(ted)
This is kinda blocking me from figuring out a fix for a tracking bug, so I'd be very appreciative of a fix.
The logic was cribbed from the final output of |mach run|.
Attachment #8509644 - Flags: review?(gbrown)
The patch I've attached does not go far enough locally.  Bug 915865 appeared to change the expected path to the reftest extension.  Everything works if you're running from mozharness/package tests in automation; the extension is not installed if you're running from |make reftest-remote| or similar.  I'm investigating this further.
OS: Mac OS X → Android
Hardware: x86 → All
This issue manifests itself as the reftest extension not being installed
for local testers.  This is because the extension's location is
determined relative to SCRIPT_DIRECTORY, and for local testers, __file__
ignores the symlink from $OBJDIR/_tests/reftest/runreftest.py ->
$SRCDIR/layout/tools/reftest/runreftest.py.

This was changed in Bug 915865.
Attachment #8509719 - Flags: review?(ted)
Attachment #8509719 - Flags: review?(ted) → review+
Comment on attachment 8509644 [details] [diff] [review]
Part 1: Don't get_binary_path on mobile/android. r=gbrown

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

Thanks Nick. With both of your patches applied, I can run reftests locally again.

I have a slight preference for keeping the default setting inside each add_option call (so that all of the --appname settings are in one place, etc). You should be able to use something like:

default = build_obj.get_binary_path() if build_obj and build_obj.substs['MOZ_BUILD_APP'] != 'mobile/android' else None,

::: layout/tools/reftest/runreftest.py
@@ +727,5 @@
> +    # logic is cribbed from the example in
> +    # python/mozbuild/mozbuild/mach_commands.py.
> +    if build_obj and build_obj.substs['MOZ_BUILD_APP'] != 'mobile/android':
> +        defaults['appname'] = build_obj.get_binary_path() if build_obj else None
> +        defaults["utilityPath"] = build_obj.bindir if build_obj else None

It looks like "if build_obj else None" is redundant here.
Attachment #8509644 - Flags: review?(gbrown) → review+
See Also: → 1087791
Depends on: 1089002
Product: Firefox for Android → Firefox Build System
Target Milestone: Firefox 36 → mozilla36
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: