I mean, it seems like the test itself crashed. That's what a crash looks like on devices, less debug information is emitted than on simulators when it happens it's just sort of cut off.

+lod as sheriff for tomorrow, sdefresne for being most likely to know what's going on in components. 

Failing swarming task https://touch-swarming.appspot.com/task?id=32a86b6926b70510 shows the following in the log:

[----------] 1 test from UpdaterStateTest
[ RUN ] UpdaterStateTest.Serialize
idevice-app-runner returned 1

Crashed during UpdaterStateTest.Serialize, resuming...

Note, that ComponentUpdaterUpdateResponseTest also failed in the same build, but on a different device (iPad Air):
https://uberchromegw.corp.google.com/i/official.ios/builders/ios/builds/932/steps/components_unittests%20%28iPad%20Air%20iOS%209.3.2%29%20on%20iOS-9.3.2/logs/test_summary.json

Similarly for the other build. As smut@ said, it looks like a crash in a test, probably a flaky one. I'm not familiar with tests, and it doesn't look like an infra failure - other tests passed on the same device. Please provide an explanation if you still believe it's a failure in the infrastructure.

BTW, for suspected infra failures, please file bugs at go/bugatrooper - you'll have a guaranteed response. I'm not monitoring my bug queue frequently enough (was lucky this time :-)

The test was recently (November 16) updated here:
https://codereview.chromium.org/2509723003/

Why is this test now flaky for iOS? +cc:hans@chromium.org

I don't know much about this test. It was broken in chrome-branded builds, and my patch fixed that.

+sorin who refactored it in https://codereview.chromium.org/2498873003

This change landed yesterday and I expect to resolve the issue with the crash in UpdaterStateTest.Serialize. I am not sure about ComponentUpdaterUpdateResponseTest.TestParser, I am still looking. Is it possible to get some kind of stack to see where ComponentUpdaterUpdateResponseTest.TestParser might be crashing?

smut@ may know more. Though I doubt we can get more info from a device as it is - it seems the app is wiped out at the end of the run. I wonder if it's possible to reproduce the crash in a simulator?

I just landed a CL to fetch crash reports off the device. If TestParser creates a stack trace on the device, we should have it next time.

It looks like this does not reproduce on simulator because canary-simulator has been green for days:
https://uberchromegw.corp.google.com/i/internal.bling.main/builders/canary-simulator

This bot has cycled green:
https://uberchromegw.corp.google.com/i/official.ios/builders/ios-canary/builds/451

This bot is still sad but not because of the components_unittests.

It is still possible that ComponentUpdaterUpdateResponseTest.TestParser is flaky, perhaps is using uninitialized memory somewhere, please let me when we have a stack, if the test is still crashing.

Other than that, is there anything I could be doing now? I come from the Chrome desktop land and I have no experience with devices.

ComponentUpdaterUpdateResponseTest.TestParser seems to crash on M56. I'll need to cherry pick this CL if we want crash reports on M56:
https://chromium.googlesource.com/chromium/src/+/be0138751bd1cdc97878fde88a4289e729131a6c

Oh shit I meant to remove sorin from owner, not cc, when reassigning to me. Sorry.

it seems that https://uberchromegw.corp.google.com/i/official.ios/builders/ios/ and https://uberchromegw.corp.google.com/i/official.ios/builders/ios-canary/ are cycling green now.

UpdaterStateTest was clearly broken and fix, hence the deterministic green run.
ComponentUpdaterUpdateResponseTest should not have been affected by the past refactoring work, so I have no clear idea why the recent flakiness. I will keep an eye on the bot though.

The "ios" builder has not necessarily cycled green, it is a release builder which interleaves builds for various branches. The green build #956 is for M57. M55 and M56 are still red, M56 with components_unittests failures.

You have to look builds with the same version number on "ios" to see if it's really cycling green.

Understood. It makes sense now.

The UpdaterStateTest was fixed by https://codereview.chromium.org/2536723004, which landed in M57. It has not been merged to M56, so I will have to do the merge.

Approving for merge into M56

https://codereview.chromium.org/2536723004 has been merged to M56 by https://codereview.chromium.org/2549623005. This should resolve UpdaterStateTest.Serialize issue. 

ComponentUpdaterUpdateResponseTest is still being investigated and waiting for a stack, if possible.

This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Haven't seen ComponentUpdaterUpdateResponseTest.TestParser failures in awhile, but UpdaterStateTest.Serialize is fixed so marking this fixed. We can re-open if the other failure resurfaces.