Bug 1477 - Cannot install to device
Summary: Cannot install to device
Alias: None
Product: iOS
Classification: Xamarin
Component: General ()
Version: 4.x
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: Untriaged
Assignee: Bugzilla
Depends on:
Reported: 2011-10-13 10:42 UTC by Dean Cleaver
Modified: 2013-12-05 18:34 UTC (History)
2 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 Dean Cleaver 2011-10-13 10:42:37 UTC
Just started happening today. Restarted both MacBook and device, no joy. Tried 2 devices, tried re-installing MonoTouch.

Prior to this happening, it told me that the "MonoTouch Framework was not installed" or very similar - I reinstalled MonoTouch and that fixed it. This also happened yesterday, but a reinstall fixed it with no further issues till today.

/Developer/MonoTouch/usr/bin/mtouch -installdev="/xsl-home/kleverlogic/FlashValet/Mobile/iPhone/Valet/bin/iPhone/AppStore/KleverLogic.FlashValet.iPhone.Valet.app"
Please ensure your device is connected...
Connected to: Dino’s iPhone

  at (wrapper managed-to-native) MonoTouch.Installation.Installer.CFArrayGetCount (intptr) <0xffffffff>
  at MonoTouch.Installation.Installer.UploadApplication (object,System.EventArgs) <0x001fd>
  at MonoTouch.Installation.Device.NotificationCallback (MonoTouch.Installation.Device/am_device_notification_callback_info&) <0x0006e>
  at (wrapper native-to-managed) MonoTouch.Installation.Device.NotificationCallback (MonoTouch.Installation.Device/am_device_notification_callback_info&) <0xffffffff>
  at (wrapper managed-to-native) MonoTouch.CoreFoundation.CFRunLoop.CFRunLoopRun () <0xffffffff>
  at MonoTouch.CoreFoundation.CFRunLoop.Run () <0x0000d>
  at MonoTouch.Installation.Installer.InstallApplication (string) <0x000c5>
  at MTouch.Main (string[]) <0x032d1>
  at (wrapper runtime-invoke) <Module>.runtime_invoke_int_object (object,intptr,intptr,intptr) <0xffffffff>

Native stacktrace:

	0   mtouch                              0x000e013e mtouch + 913726
	1   mtouch                              0x0001aa68 mtouch + 105064
	2   libsystem_c.dylib                   0x9a79759b _sigtramp + 43
	3   ???                                 0xffffffff 0x0 + 4294967295
	4   ???                                 0x027e4cbc 0x0 + 41831612
	5   ???                                 0x027e3826 0x0 + 41826342
	6   ???                                 0x027e351f 0x0 + 41825567
	7   ???                                 0x020f0046 0x0 + 34537542
	8   MobileDevice                        0x0409c5fe _AMDDeviceAttachedCallbackv3 + 163
	9   MobileDevice                        0x040533d5 USBMuxIntCFSocketCallback + 1633
	10  CoreFoundation                      0x91002adb __CFSocketPerformV0 + 1163
	11  CoreFoundation                      0x90fb610f __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 15
	12  CoreFoundation                      0x90fb5ac6 __CFRunLoopDoSources0 + 246
	13  CoreFoundation                      0x90fdf9d8 __CFRunLoopRun + 1112
	14  CoreFoundation                      0x90fdf1ec CFRunLoopRunSpecific + 332
	15  CoreFoundation                      0x90feff11 CFRunLoopRun + 129
	16  ???                                 0x027e342e 0x0 + 41825326
	17  ???                                 0x027e33f6 0x0 + 41825270
	18  ???                                 0x027dfe3e 0x0 + 41811518
	19  ???                                 0x0202536a 0x0 + 33706858
	20  ???                                 0x02027e74 0x0 + 33717876
	21  mtouch                              0x0001a823 mtouch + 104483
	22  mtouch                              0x001f8e92 mtouch + 2064018
	23  mtouch                              0x001fb74c mtouch + 2074444
	24  mtouch                              0x001faada mtouch + 2071258
	25  mtouch                              0x000b0e3f mtouch + 720447
	26  mtouch                              0x000b1076 mtouch + 721014
	27  mtouch                              0x000b3156 mtouch + 729430
	28  mtouch                              0x00002f93 mtouch + 8083
	29  mtouch                              0x00002815 mtouch + 6165

Debug info from gdb:

/tmp/mono-gdb-commands.TwhqBQ:1: Error in sourced command file:
unable to debug self

Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries 
used by your application.

The application was terminated by a signal: SIGIOT
Comment 1 Sebastien Pouliot 2011-10-13 17:49:34 UTC
Please provide us with the version number of MT, like:

/Developer/MonoTouch/usr/bin/mtouch --version

on a terminal window and also state which version of the iOS SDK and MonoDevelop you're presently using.

If anything else is using the USB port (e.g. iTunes) also try closing the application and try again.
Comment 2 Dean Cleaver 2011-10-16 10:35:40 UTC
MT 4.0.6, iOS SDK is current AppStore version of XCode for Lion (4.1 I believe), and no other USB devices.
Comment 3 Dean Cleaver 2011-10-16 11:42:46 UTC
Have just returned home from a trip, installed MD 2.8.1, Mono 2.10.6 and MT 5 and it's working fine - you can consider this closed if you wish.
Comment 4 Dean Cleaver 2011-10-16 13:56:02 UTC
Ok - maybe not. It just happened on all the latest code too, but I noticed something - if I delete the output folder (bin\iPhone\QA) contents, do a clean all, and then deploy to device it works. I think something might be messing up when switching from Debug\Simulator to iPhone releases.

Something else I have noticed is that after doing a delete and clean build of QA, I have a KleverLogicFlashValetSmartClientiPhone.dll in the folder. If I switch to Debug\Simulator and build, it puts more files in my QA folder, including a KleverLogic.FlashValet.SmartClient.iPhone.dll - any ideas why one build is removing the .s and why a Debug build for simulator is building to my iPhone QA folder?
Comment 5 Sebastien Pouliot 2011-10-16 14:56:53 UTC
ok, let's do this one step at the time :-)

Comment #3 made a lot of sense since it's identical to a bug that was fixed after 4.0.6 release (and why I asked for the monotouch version you were using). You need a recent 4.2.x or 5.0 to get the fix.

The first part of comment #4 is confusing. 

a) Are you getting the same stack trace as the original description ? 

b) If so are you using 5.0 ? or something else ?

I noticed (and filled a bug report) that MonoDevelop does not rebuild solutions automagically when a MonoTouch update is done. That can lead to some weird errors but it should not result in the same stack trace (since that's involves mtouch, not MD).

The second part (missing '.') is also something I noticed this weekend. I _think_ MD changed it's behavior to avoid invalid file names for iOS projects. If a "clean" does not solve this then please fill a separate MD bug for this one.
Comment 6 Dean Cleaver 2011-10-16 18:52:55 UTC
Regarding Comment #3: Well, I have been using 4.0.6 for a while - all subsequent releases caused problems for me. I packed up my laptop, went away on a business trip, and suddenly it couldn't deploy to device - so it's not an old problem, or I would have had problems deploying for months.

Regarding Comment #4: No - you're right. Totally different stack trace. And I'm using 5.latest whatever that is.

Rebuilding after an MT update isn't the problem I don't think. It seems if I switch from debug to QA, and try to compile and upload to device it fails. I have to clean all, then rebuild, then upload.

As for the missing .s, clean etc does nothing - it's repeatable every time. Clean all, delete from the QA output folder, compile QA\iPhone and it produces the binary without .s. Change to Debug\Simulator and it produces the binaries with .s into the QA\iPhone folder.
Comment 7 Sebastien Pouliot 2011-10-16 19:12:48 UTC
for #3 it's an old problem as far as bug fixes are concerned ;-)
The most likely causes are the ones in comment #2 and comment #4 of bug #921. All of them can happen anytime (and cause the crash instead of an error message in 4.0.x releases) since a provisioning profile has a limited lifespan.

for #4 I need to see stack traces and (if there was not only a single 5.0 release) I would need the exact MT version number too (since we have, form time to time, some non public builds around for testing). Without those we're blind to the problem(s) you're experiencing (or worse we assume that the old ones are still meaningful).

The last part (about the missing '.') seems an MD issue/feature. It's possible, since the simulator/devices builds are very different, that this happens only for the device. Please open a new bug report so this can be tracked correctly.
Comment 8 Sebastien Pouliot 2011-10-17 11:06:52 UTC
filled bug #1532 for missing '.'
Comment 9 PJ 2013-11-19 17:04:45 UTC
This bug has been in the NEEDINFO state with no changes for the last 90 days. Can we put this back into the NEW or CONFIRMED state, or are we still awaiting response?

If there is no change in the status of this bug over the next two weeks, this bug will be marked as NORESPONSE.
Comment 10 PJ 2013-12-05 18:34:55 UTC
This bug has not been changed from the NEEDINFO state since my previous comment, marking as RESOLVED NORESPONSE.

Please feel free to REOPEN this bug at any time if you are still experiencing the issue. Please add the requested information and set the bug back to the NEW (or CONFIRMED) state.