Bug 196260 - [ews] Reset simctl states on reboot
Summary: [ews] Reset simctl states on reboot
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Tools / Tests (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Jonathan Bedard
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2019-03-26 10:41 PDT by Jonathan Bedard
Modified: 2019-03-26 16:22 PDT (History)
5 users (show)

See Also:


Attachments
Patch (1.13 KB, patch)
2019-03-26 11:23 PDT, Jonathan Bedard
no flags Details | Formatted Diff | Diff
Patch for landing (1.14 KB, patch)
2019-03-26 13:01 PDT, Jonathan Bedard
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jonathan Bedard 2019-03-26 10:41:08 PDT
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.
Comment 1 Jonathan Bedard 2019-03-26 11:23:45 PDT
Created attachment 365976 [details]
Patch
Comment 2 Aakash Jain 2019-03-26 11:46:45 PDT
Comment on attachment 365976 [details]
Patch

rs=me
Comment 3 Jonathan Bedard 2019-03-26 13:01:24 PDT
Created attachment 365990 [details]
Patch for landing
Comment 4 WebKit Commit Bot 2019-03-26 13:42:04 PDT
Comment on attachment 365990 [details]
Patch for landing

Clearing flags on attachment: 365990

Committed r243516: <https://trac.webkit.org/changeset/243516>
Comment 5 WebKit Commit Bot 2019-03-26 13:42:06 PDT
All reviewed patches have been landed.  Closing bug.
Comment 6 Radar WebKit Bug Importer 2019-03-26 13:51:09 PDT
<rdar://problem/49289644>
Comment 7 Alexey Proskuryakov 2019-03-26 14:17:55 PDT
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.
Comment 8 Jonathan Bedard 2019-03-26 16:22:09 PDT
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.