New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 739256 link

Starred by 1 user

Issue metadata

Status: Verified
Owner:
Closed: Jul 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Bug



Sign in to add a comment

cheets_KeyboardTest failing on veyron_minnie-chrome-pfq with failed uiautomator import

Project Member Reported by derat@chromium.org, Jul 5 2017

Issue description

cheets_KeyboardTest has been failing on veyron_minnie-chrome-pfq with an import error about the uiautomator module:

START	----	----	timestamp=1499145812	localtime=Jul 03 22:23:32	
	START	cheets_KeyboardTest	cheets_KeyboardTest	timestamp=1499145813	localtime=Jul 03 22:23:33	
		FAIL	cheets_KeyboardTest	cheets_KeyboardTest	timestamp=1499145892	localtime=Jul 03 22:24:52	Unhandled ImportError: No module named uiautomator
  Traceback (most recent call last):
    File "/usr/local/autotest/common_lib/test.py", line 818, in _call_test_function
      return func(*args, **dargs)
    File "/usr/local/autotest/common_lib/test.py", line 471, in execute
      dargs)
    File "/usr/local/autotest/common_lib/test.py", line 348, in _call_run_once_with_retry
      postprocess_profiled_run, args, dargs)
    File "/usr/local/autotest/common_lib/test.py", line 381, in _call_run_once
      self.run_once(*args, **dargs)
    File "/usr/local/autotest/tests/cheets_KeyboardTest/cheets_KeyboardTest.py", line 36, in run_once
      from uiautomator import device as d
  ImportError: No module named uiautomator
	END FAIL	cheets_KeyboardTest	cheets_KeyboardTest	timestamp=1499145892	localtime=Jul 03 22:24:52	
END GOOD	----	----	timestamp=1499145895	localtime=Jul 03 22:24:55

I'm not sure where this test code lives, or even how to find out who wrote it. Chung-yih, it looks like you touched this part of the ebuild last, so hopefully you know. :-)
 
Cc: victorhsieh@chromium.org djkurtz@chromium.org
Cc: uekawa@chromium.org
Hi, 

I don't quite understand but the dashboard tells me it succeeds on retry (how?)
notiftication test (and keyboard test) is failing with same errror on minnie.

https://uberchromegw.corp.google.com/i/chromeos/builders/veyron_minnie-chrome-pfq/builds/1355


Cc: hidehiko@chromium.org
Although container looks booted, but autotest is confused it is not.
Here is the message;
07/04 19:19:56.735 ERROR|               arc:0482| Container is alive?

Because error log is missing, it is difficult to see the root cause, IMHO.
Maybe we should add more logging there?
This is a side-effect from launching parts of container, Victor, please have a way to make sure it is what you want as you skip the arc_setup() part?

=== test debug log
07/04 19:19:56.732 INFO |        arc_common:0043| Android has booted completely.
07/04 19:19:56.735 ERROR|               arc:0482| Container is alive?
07/04 19:19:56.771 DEBUG|              test:0363| starting before_iteration_hooks

=== arc.py
478         try:
479             if is_android_container_alive():
480                 self.arc_setup()
481             else:
482                 logging.error('Container is alive?')

Labels: M-61
The login screen feature has temporarily been disabled in r484215 but we should fix this in M61 anyway.
I couldn't reproduce the issue on my caroline even without the revert (r484215), but found one strange behavior.

If I run 'test_that caroline_ipaddr cheets_PerfBoot', DUT's /var/log will have arc-setup-for-login-screen.log and arc-boot-continue.log, but 'test_that caroline_ipaddr cheets_KeyboardTest' somehow creates arc-setup-for-login-screen.log and then arc-setup.log.

localhost ~ # head -1 /var/log/arc-setup*log                                                                                                
==> /var/log/arc-setup-for-login-screen.log <==
2017-07-05 05:54:41.151479625-07:00: Pre-start arc-setup-for-login-screen

==> /var/log/arc-setup.log <==
2017-07-05 05:54:43.800132193-07:00: Pre-start arc-setup

This means that the container upgrade path is not taken for cheets_KeyboardTest for some reason. This might be causing the 'process not found' issue on minnie.

Comment 9 by x...@chromium.org, Jul 5 2017

The PFQ build veyron_minnie-chrome-pfq has 2 green cycles since https://uberchromegw.corp.google.com/i/chromeos/builders/veyron_minnie-chrome-pfq/builds/1356. It might have a silent fix.

Comment 10 by uekawa@google.com, Jul 6 2017

#9, it's been flaky, retrying multiple times.
#8, upgrade not happening is probably because ARC++ is disabled by default in the test (e.g. sync is disabled?).
Comment #11:
Filed a separate bug b/63375213 for this.


Can we close this bug? The last 15 builds (#1365-1380) are green.
https://uberchromegw.corp.google.com/i/chromeos/builders/veyron_minnie-chrome-pfq

Status: Verified (was: Assigned)
Thanks!

Sign in to add a comment