Is this bug has the same root cause of https://bugs.chromium.org/p/chromium/issues/detail?id=709374

+------------------------------------------------------------------------------+
| Shard 0  https://chromium-swarm.appspot.com/user/task/3a4a9ae38985d110       |
+------------------------------------------------------------------------------+
Device wiped.
Using Xcode version 9.0 build 9A235 at /Applications/Xcode9.0.app/Contents/Developer
/b/s/w/ir/src/out/Debug-iphonesimulator/iossim -d iPad Air 2 -s 11.0 /b/s/w/ir/src/out/Debug-iphonesimulator/gfx_unittests.app
User defaults from command line:
    IDETestRunSpecificationPath = /var/folders/2j/22s2gz0s7hn48k32d47clxf80000gm/T/14BE1DC4-683C-49E9-B26C-F37EE51590B2
+------------------------------------------------------------------------------+
| End of shard 0  Pending: 0.3s  Duration: 1207.9s  Bot: build27-m9  Exit: -15 |
+------------------------------------------------------------------------------+
Total duration: 1207.9s
WARNING:root:collect_cmd had non-zero return code: 241

The root cause of  bug 709374  was fixed in Xcode 9 in theory, so either the fix was incomplete or this has a different root cause.

From IM conversation with liaoyuke, sounds like they're not a good owner for this bug.  Switching to justincohen.

Can't really disable all of gfx_unittests, so just removing this from the sheriff queue for now.

sergeyberezin@ The only thing that's changed in the past week is some of the CIPD hermetic has started to roll out, although that may be totally unrelated.  Any chance cipd-hermetic development is related?

I don't think it's related. It runs with the updated test_runner, but still uses the system Xcode:

  Using Xcode version 9.0 build 9A235 at /Applications/Xcode9.0.app/Contents/Developer

Once the test runner figures out where Xcode is, the execution path is identical to the version before the update.

I've seen this hang in my recent tests in Xcode 9.0, I'm not sure why it's happening. FWIW, wrong file permissions may cause a simulator to hang silently (I had to chmod -R u+w Xcode.app to fix it). But I doubt the system-wide install has this problem. Not sure...

Detected 44 new flakes for test/step "gfx_unittests". To see the actual flakes, please visit https://chromium-try-flakes.appspot.com/all_flake_occurrences?key=ahVzfmNocm9taXVtLXRyeS1mbGFrZXNyGAsSBUZsYWtlIg1nZnhfdW5pdHRlc3RzDA. This message was posted automatically by the chromium-try-flakes app.

The latest errors seem to be capacity problems.

Yes, these are likely due to https://crrev.com/c/835359 landing at 3pm PST. The bots had to pick up the new Xcode and took extra time, leading to longer cycle times which in turn led to increased capacity requirements, long pending queues and timeouts:

  http://vi/chrome_infra/Jobs/per_job?duration=3d&job_regexp=.%2Aios-simulator%3A.%2A&refresh=-1&service_name=chromium-swarm&utc_end=1513857651

There is nothing we can realistically do, other than to come up with a way to warm up the Xcode caches on the bots before we roll out a new version. Perhaps, updating the configs at off-peak hours may do the cache warmup organically. But the downside is that MTV won't be watching if it fails...

I'm not seeing these anymore.