Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.
Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.
Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.
Please create a new report for Bug 43566 on Developer Community or GitHub if you have new information to add and do not yet see a matching new report.
If the latest results still closely match this report, you can use the original description:
In special cases on GitHub you might also want the comments: GitHub Markdown with public comments
Created attachment 17143 [details] Hung Simulator process sample from Activity Monitor [Cycle 8 Beta] iOS Designer initialization causes any already running iOS 10 simulator to hang, (get stuck, freeze, become non-responsive) ## Regression status: new incompatibility with Xcode 8 that was not a problem with Xcode 7.3 BAD: Cycle 8 Beta + Xcode 8, iOS 10 simulator GOOD: Cycle 8 Beta + Xcode 7.3, iOS 9.3 simulator ## Steps to replicate 1. Install Xcode 8 Beta 5, and run it once to allow it to set itself up. 2. Open the Cycle 8 Beta version of Xamarin Studio and set "Xamarin Studio > Preferences > Projects > SDK Locations > Apple > Apple SDK > Location" to point to the beta version of Xcode. For example, in my case: /Applications/Xcode-beta.app 3. Open Xcode and select "Xcode > Open Developer Tool > Simulator" to start up the iOS 10 simulator (I tested with the "iPhone 6s Plus" configuration). Wait until the simulator has launched and you are able to navigate around the home screen. 4. Go back to Xamarin Studio, open an existing project that was created via "iOS > App > Single View App", or create a new project using that template. 5. After the project loads in Xamarin Studio, return to the iOS simulator and attempt to navigate on the home screen by swiping left and right. ## Alternate way to replicate that more clearly highlights the involvement of the iOS Designer At step 4, instead of opening a project in Xamarin Studio, instead run the `Designer.exe` agent that is used by Xamarin for Visual Studio: mono64 "$HOME/Library/Caches/Xamarin/XMA/Agents/Designer/4.2.0.508/Designer.exe" (The agent will quit when it fails to establish a connection, but it will still "successfully" causes the iOS simulator to freeze before then.) ## Results The iOS 10 simulator is frozen and does not respond to any user input. (See also the attached process sample of the simulator taken via Activity Monitor while in this frozen state.) ## Additional version info (brief) Xamarin Studio 6.1 (build 5345) Mono 4.6.0 (mono-4.6.0-branch/d0fc1a6) Xcode 8.0 (11239.2), Build 8S201h OS X 10.11.6
Created attachment 17144 [details] Xamarin Studio log files
This is unlikely to be something we can affect
Marking as low/minor as there is a trivial workaround - restart the sim. Apple broke a lot of stuff with the sim this time round and it is much less stable than it used to be. This is towards the bottom of the list of things we need to look at
One potential complication is whether Xamarin might need to switch around the failure mode to be a good citizen: rather than causing the simulator to become unresponsive, perhaps the designer could semi-gracefully refuse to initialize if the iOS 10 simulator is currently running. There are some pros and cons either way from a perspective of "least surprise" for a user, but perhaps the "good citizen" consideration is enough to tip the balance slightly in favor of changing the failure mode. ## Possible adjustments for Cycle 8 For expediency for now, maybe it would be possible to do something similar to the following: - Check if the iOS 10 simulator is running at each of the following times: (a) During iOS project load in Xamarin Studio (when the designer normally initializes) (b) During the build host connection from Visual Studio (when the `Designer.exe` process is starting up) (c) When attempting to open a storyboard in Xamarin Studio - If the iOS 10 simulator is running, cancel the designer initialization and output an error message in the IDE log file similar to the following: > Initialization of the designer service has been aborted to avoid > interfering with a running iOS 10 simulator. If use of the designer > service is desired, please quit the iOS 10 simulator and retry. As > soon as the designer service is initialized, the iOS 10 simulator can > safely be relaunched. - Additionally, if the error happens during (c) (when attempting to explicitly open a storyboard in Xamarin Studio), perhaps the error message can also be shown in the "standard" error dialog box within the designer surface. ### Potential complications - If the new logic to detect the run state of iOS 10 simulator is sometimes incorrect (e.g., it thinks the iOS 10 simulator is running when it's not), then aborting the designer initialization based on that logic could block users from being able to use the designer at all. And the error message would be frustratingly inaccurate in that case. - The error message would potentially be a bit confusing to users because starting up the designer service is not something the user usually does directly. It's also tricky to convey in only a few words that the conflict is only a problem during _initialization_, and that it's fine to start the iOS 10 simulator after that. One of the problems is that the error message inevitably has to briefly teach the user that the designer has a distinct initialization phase that is separate from the normal usage phase. ## Possible further enhancements for Cycle 8 – Service Release 1 or later One possible idea to combat the potential complications of a raw error message could be to display a dialog message instead. The dialog could say something like: > The designer service detected a running iOS 10 simulator during > initialization. Continuing with the initialization would likely cause the > simulator to become non-responsive, so you would need to quit and restart the > simulator after the designer service starts. > > Please choose how to proceed: > > ( ) Quit the iOS 10 simulator for me and then restart it after the designer > service is initialized. > > ( ) Leave the iOS 10 simulator running _and_ start the designer service. > > ( ) Cancel starting the designer service. > > > ( ) Remember this option for next time. > > (OK) (Cancel)
Adding detection for a running simulator is tricky for the visual studio case. We have to round trip from windows to mac before initialising the designer just to check its running. I suspect that any change would have to happen for the next service release. It's too big a change to rush this week. We can review it when the GM is released. If it ends up being a common problem we could add a temporary notice when starting the designer or forms previewer.
since C8 is now closed, and is shipping this week, I will move this but to the C8SR1 milestone. We'll continue working on the issue seeking it's resolution as soon as possible.
Fixed in version 6.2.0.492 (master) Author: Alan McGovern Commit: 626ce66504b019adeca29fc4b6374a0b2cc14812 (xamarin/ios-sim-sharp) Included in Commit: b81325eef8adf74178c7465ce4ea9979a558ba09 (mono/monodevelop)
Fixed in version 6.1.0.5442 (cycle8) Author: Alan McGovern Commit: 626ce66504b019adeca29fc4b6374a0b2cc14812 (xamarin/ios-sim-sharp) Included in Commit: d3e6b3050a54e805ad4d8f0f2ba53d1afd1e7e3a (mono/monodevelop)
This has been mitigated to make it less frequent, but not completely resolved.
I'm marking this as resolved/fixed so we can test the mitigation that @Alan describes in the trello card: "A mitigation to make the reset less frequent has been added to master and C8. The full fix (never having to reset the services) falls outside the scope of SR0. We'll leave the bug open until we can properly resolve it." We will track the full fix in bug 44373
lets do it the other way around. This has all the info i need. Let's use 44373 to verify the mitigation :)
44373 has been verified as fixed. Would this then also be considered fixed as per my understanding of comment 17?