Bug 16552 - Crashes when attempting to deploy to device, can't debug on device once TestFlight's TakeOff has been called. (Calling it causes it to exit debugger)
Summary: Crashes when attempting to deploy to device, can't debug on device once TestF...
Alias: None
Product: iOS
Classification: Xamarin
Component: General ()
Version: 7.0.4.x
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: Untriaged
Assignee: Bugzilla
Depends on:
Reported: 2013-12-03 00:44 UTC by traderhut
Modified: 2016-05-24 20:52 UTC (History)
3 users (show)

Is this bug a regression?: ---
Last known good build:

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 on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description traderhut 2013-12-03 00:44:05 UTC
The last couple of revs I've not been able to debug on a physical device (iOS 5.1.1, iPhone 4S)

Now, it won't even transfer the code to the device.

I'm also plagued with random crashes in the developer environment (I would have reported the last one, but selecting the text in the crash reporter caused it to crash and exit Xamarin Studio and then ask me again, this time with no details.

Log is below

Please ensure your device is connected...
error MT0000: Unexpected error - Please file a bug report at http://bugzilla.xamarin.com
MonoTouch.MobileDevice.MobileDeviceException: AMDeviceConnect returned: 0xe8000065 (kAMDMuxConnectError)
at MonoTouch.Installation.Device.Connect () <0x0007b>
at MonoTouch.Installation.Installer/<ExecuteWithSession>c__AnonStorey17.<>m__22 (object,System.EventArgs) <0x00017>
at MonoTouch.Installation.Device.NotificationCallback (MonoTouch.MobileDevice.am_device_notification_callback_info&) <0x00075>
at (wrapper native-to-managed) MonoTouch.Installation.Device.NotificationCallback (MonoTouch.MobileDevice.am_device_notification_callback_info&) <0x0005b>
at (wrapper managed-to-native) MonoMac.CoreFoundation.CFRunLoop.CFRunLoopRun () <0x00003>
at MonoMac.CoreFoundation.CFRunLoop.Run () <0x0000b>
at MonoTouch.Installation.Installer.ExecuteWithSession (string,MonoTouch.Installation.Installer/Executor) <0x000d7>
at MonoTouch.Installation.Installer.InstallApplicationWithoutSymbols (string,string) <0x00067>
at MonoTouch.Installation.Installer.InstallApplication (string,string,bool) <0x0002f>
at MTouch.Main2 (string[]) <0x027db>
at MTouch.Main (string[]) <0x00017>
Comment 1 traderhut 2013-12-03 01:00:10 UTC
The upload appears to have been a bad cable.

And I figured out the other issue - you can't debug with TestFlight Enabled, calling the TakeOff causes the debugger to exit.

If anyone has fixed that, I'd love to know how to.

   -Traderhut Games
Comment 2 Sebastien Pouliot 2013-12-03 09:38:26 UTC
That sounds like the signals (that both Mono and Testflight each requires) are not set up properly.

For reference you can read (and try): http://stackoverflow.com/q/14499334/220643
Comment 3 traderhut 2013-12-03 12:51:44 UTC
Actually, it doesn't.

The reference you refer to relates to exception handling.

In this case, I start up the App, and the method TakeOff() never returns - it causes the app to exit.

According to the page, it saves the current exception handling vectors, and you would call TakeOff() and then restore the exception handling vectors.

At step #2, it blows out of the app.  (I can run it outside of the debugger just fine without it crashing - same build, just touch it again to run it.)

  -Traderhut Games
Comment 4 Sebastien Pouliot 2013-12-03 19:54:41 UTC
It sounds like something might occurs in TakeOff that would requires Mono signals to be (already) restored.

Can you attach a self-contained test case so we can have a look ?

Also please add the iOS version you tried and the software versions*

* The easiest way to get exact version information is to use the "Xamarin Studio" menu, "About Xamarin Studio" item, "Show Details" button and copy/paste the version informations (you can use the "Copy Information" button).
Comment 7 Rolf Bjarne Kvinge [MSFT] 2013-12-06 05:29:58 UTC
This is probably because the debugger uses additional signals not handled by the signal restoration code. The crash report from TestFlight probably says which signal, but my guess would be SIGUSR1.

Note that setting a breakpoint after TakeOff, but before restoring the signals would also cause problems.
Comment 8 traderhut 2013-12-10 17:06:12 UTC
I'm not sure if I wasn't clear.   There is no crash report in TestFlight, as TestFlight's TakeOff() call is what crashes under the debugger.

Also, there is nothing to 'restore' after calling TakeOff(), as the app exits when it crashes, and you simply can not call any code after that to avoid the crash that has already happened.

I can set a breakpoint on the TakeOff() call, and it stops, but step over it and you are gone.  Not having a breakpoint after that in the code still crashes the app.

Commenting out the TakeOff() causes it to work.  (I have code that says something like:

if (Options.DisableTestFlight)
    TestFlight.TakeOff ();     // Or whatever the exact call actually is.

Also, for what it's worth, I posted the following before, but because I posted ID's and such before it, it was posted as private.  This part, doesn't need to be:

I don't have a self contained test case at this time.

OK, perhaps it needs them already restored, but that doesn't make sense to me,
and there is no way to do it.  I can't restore them to what they already are. 
I mean, the process is:

Save them
Restore them.

And you are saying they need to be restored before TakeOff is called, which
would be:

Save Them
Restore them (???)

  - Maybe restore them again?

int A = 34;   // whatever value that MonoTouch initializes the vector to, exact
value doesn't matter. 

int save_A;   // A Var to save the value of A (the vector for the SIG Vector in

Save_A = A;  // Save them
A = Save_A;  // Restore them  (??)

TakeOff ();   // Get them changed.

A = Save_A;  // Restore them.

I can't see how it can be related to having a saved copy of the vectors before
I call TakeOff() and have it mess with them.

IOS Version 5.1.1 on iPhone 4S for sure, Pretty sure I also tried it in iOS 6.x
 (would have to look it up, that would be on the iPad or iPad Mini)

Haven't tried either of those with the latest version, but with one of the
versions over the last 2-4 months that this has been happening.

   -Traderhut Games
Comment 9 traderhut 2013-12-10 17:09:48 UTC
Please note, in the preceding example, the line A = Save_A; is not reached, as TakeOff() exits the app.

And I also stated, that I have the latest stable build of XS, and XCode.

   -Traderhut Games
Comment 10 Rolf Bjarne Kvinge [MSFT] 2013-12-12 08:50:17 UTC
Could you create a test project we can use to reproduce the issue?
Comment 11 Sebastien Pouliot 2016-05-24 20:52:15 UTC
We have not received the requested information. If you are still experiencing this issue please provide all the requested information and re-open the bug report. Thanks!