Same thing happened on veyron_minnie-paladin:
https://luci-milo.appspot.com/buildbot/chromeos/veyron_minnie-paladin/4934

According to suite detail:
https://viceroy.corp.google.com/chromeos/suite_details?job_id=167265098

It seems like DUT is crashed while testing cheets_WindowManagerTest, so timeout occurs after about 1 hour for autoserv.


FYI, it didn't recur in the later builds
https://uberchromegw.corp.google.com/i/chromeos/builders/bob-paladin

This looks like a product bug:  Either the test is flaky, or
the underlying feature under test is.

Passing to the ARC++ constable for further evaluation.

We might want to add some timeouts to the intermediate adb commands (cc-ing ricardoq@ for that), but the test itself is working well. A system_server crash is the root cause:

01-03 09:37:24.821   123   136 I ActivityManager: START u0 {flg=0x10008000 cmp=org.chromium.arc.testapp.windowmanager24/org.chromium.arc.testapp.windowmanager.MainActivity (has extras)} from uid 10052 on display 0
01-03 09:37:24.825   123   136 I TaskWindowPlacerArc: Topmost activity added to task with orientation: SCREEN_ORIENTATION_SENSOR
01-03 09:37:24.830   123   145 D DecorView[windowmanager24]: Cannot get the activity to get CaptionConfiguration.
01-03 09:37:24.835   123  1056 I TaskWindowPlacerArc: Root activity removed from task: ActivityRecord{aa26e29 u0 org.chromium.arc.testapp.windowmanager24/org.chromium.arc.testapp.windowmanager.MainPortraitActivity t3 f}
01-03 09:37:24.836   123   138 E AndroidRuntime: *** FATAL EXCEPTION IN SYSTEM PROCESS: ActivityManager
01-03 09:37:24.836   123   138 E AndroidRuntime: java.lang.IndexOutOfBoundsException: Index: 2, Size: 2
01-03 09:37:24.836   123   138 E AndroidRuntime: 	at java.util.ArrayList.get(ArrayList.java:411)
01-03 09:37:24.836   123   138 E AndroidRuntime: 	at com.android.server.am.TaskRecord.getTopActivity(TaskRecord.java:705)
01-03 09:37:24.836   123   138 E AndroidRuntime: 	at com.android.server.am.TaskWindowStateArc.getTopActivity(TaskWindowStateArc.java:657)
01-03 09:37:24.836   123   138 E AndroidRuntime: 	at com.android.server.am.TaskWindowPlacerArc$MainHandler.handleMessage(TaskWindowPlacerArc.java:389)
01-03 09:37:24.836   123   138 E AndroidRuntime: 	at android.os.Handler.dispatchMessage(Handler.java:102)
01-03 09:37:24.836   123   138 E AndroidRuntime: 	at android.os.Looper.loop(Looper.java:154)
01-03 09:37:24.836   123   138 E AndroidRuntime: 	at android.os.HandlerThread.run(HandlerThread.java:61)
01-03 09:37:24.836   123   138 E AndroidRuntime: 	at com.android.server.ServiceThread.run(ServiceThread.java:46)
01-03 09:37:24.837   123   469 E ActivityManager: applyOptionsLocked: Unknown animationType=0

I'll keep looking.

Figured out the root cause, and tracking in https://b.corp.google.com/issues/71602109. This is going to take some time to fix :(

Ricardo: given that the cheets_WindowManager test does exercise the racy code significantly more than regular tests, do you think there is a way to detect these kinds of crashes while the test is running? Otherwise we might need to temporarily disable this test until it's fixed.

@luis: 
(I don't know the answer, not sure what's possible from python/autotests)

do you know if there is any other test that detects crash? If so, I can do the same.

Marking it as fixed since https://b.corp.google.com/issues/71602109 was fixed.