Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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.
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>
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.
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
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.)
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).
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.
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:
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:
And you are saying they need to be restored before TakeOff is called, which
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.
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.
Could you create a test project we can use to reproduce the issue?
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!