Bug 196260 – [ews] Reset simctl states on reboot

• Status: RESOLVED
• Resolution: FIXED
• Component: Tools / Tests

[Jonathan Bedard]

It's possible for simctl to get in a pretty rotten state, especially if folks change infrastructure code in a patch. On reboot, we should do everything we can to reset simctl to a pristine state.

[Jonathan Bedard]

Created attachment 365976 [details]
Patch

[Aakash Jain]

Comment on attachment 365976 [details]
Patch

rs=me

[Jonathan Bedard]

Created attachment 365990 [details]
Patch for landing

[WebKit Commit Bot]

Comment on attachment 365990 [details]
Patch for landing

Clearing flags on attachment: 365990

Committed r243516: <https://trac.webkit.org/changeset/243516>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Radar WebKit Bug Importer]

<rdar://problem/49289644>

[Alexey Proskuryakov]

Comment on attachment 365990 [details]
Patch for landing

View in context: https://bugs.webkit.org/attachment.cgi?id=365990&action=review

> Tools/EWSTools/start-queue-mac.sh:68
> +/usr/bin/sudo /usr/bin/killall -9 com.apple.CoreSimulator.CoreSimulatorServer
> +/usr/bin/xcrun simctl delete unavailable

How did you choose this order of operations?

If CoreSimulatorServer is restarted automatically, then we would probably want to restart it after the state is clean, not before. Although there would be races either way I think.

[Jonathan Bedard]

Comment on attachment 365990 [details]
Patch for landing

View in context: https://bugs.webkit.org/attachment.cgi?id=365990&action=review

>> Tools/EWSTools/start-queue-mac.sh:68
>> +/usr/bin/xcrun simctl delete unavailable
> 
> How did you choose this order of operations?
> 
> If CoreSimulatorServer is restarted automatically, then we would probably want to restart it after the state is clean, not before. Although there would be races either way I think.

First we need to remove any corrupted devices (to do this, we remove all devices)
Second, we need to force the CoreSimulatorServer to recognize our deletions (because it won't immediately)

Last, we should remove any remaining devices that simctl thinks it has available, but aren't. This last step isn't strictly necessary to fix the problem which prompted this bug, but it's something we should have been doing in the first place. The trouble is, 'xcrun simctl delete unavailable' will fail if it tries to delete devices corrupted in a certain way.