Bug 15950 - iOS6 simulator crash with Mavericks when using binding libraries
Summary: iOS6 simulator crash with Mavericks when using binding libraries
Status: VERIFIED FIXED
Alias: None
Product: iOS
Classification: Xamarin
Component: Xamarin.iOS.dll ()
Version: 7.0.4.x
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: 7.0.6
Assignee: Sebastien Pouliot
URL:
: 13602 ()
Depends on:
Blocks:
 
Reported: 2013-11-05 21:45 UTC by Brad Moore
Modified: 2013-12-23 08:40 UTC (History)
9 users (show)

Tags:
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:
Status:
VERIFIED FIXED

Description Brad Moore 2013-11-05 21:45:21 UTC
When trying to run my apps on iOS6.0/6.1 simulator the app fails to launch correctly.
The splash screen will display for about 500ms, then the simulator will go back to its home screen.
These three attached samples all have a dll from a monotouch binding project from the monotouch-bindings git repo.

The first two contain a dll built on mavericks (system details below) and dlls built on a mountain lion system.
The UrbanAirship binding library would not build on the Mountain Lion (https://pastebin.com/b2ELvpUN). Not sure if its an issue there, or an issue with my iMac (system details also below).
The dll's built in Mavericks are in the M_DLL folder, whereas the Mountain Lion dll's are in ML_DLL.

In each project is 1 line of code that will be sure the dll is actually included.

When I run in iOS6.1 simulator on my Mavericks machine I get the following outputs.
Debug:
Starting iOS simulator 6.1
Launching application
Application launched. PID = 483

Application Terminated


Release:
dyld: Symbol not found: ___CFObjCIsCollectable
  Referenced from: /System/Library/Frameworks/Security.framework/Versions/A/Security
  Expected in: /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/System/Library/Frameworks/CoreFoundation.framework/CoreFoundation
 in /System/Library/Frameworks/Security.framework/Versions/A/Security

If I set the linker behavior to "Link SDK assemblies only", the project will build and run fine in both release and debug builds.

These are the sample projects I have created.
http://files.bradmoore.com.au/xamarin/bugs/BugTest-01-SDWebImage.zip
http://files.bradmoore.com.au/xamarin/bugs/BugTest-02-iRate.zip
http://files.bradmoore.com.au/xamarin/bugs/BugTest-03-UrbanAirship.zip


My system specs are as follows.
Mavericks Machine:
OS X 10.9 (13A603)
Late 2012  Mac Mini (2.3 GHz i7, 2 GB RAM, Intel HD 4000)
Using everything in the alpha stream
Xamarin Studio
Version 4.1.13 (build 17)
Installation UUID: 1e19aec7-fae5-441f-b8c1-6aa58b552605
Runtime:
	Mono 3.2.4 ((no/294f999)
	GTK+ 2.24.20 theme: Raleigh
	GTK# (2.12.0.0)
	Package version: 302040000

Apple Developer Tools
Xcode 5.0.1 (3335.23)
Build 5A2053

Xamarin.Mac
Xamarin.Mac: Not Installed

Xamarin.Android
Not Installed

Xamarin.iOS
Version: 7.0.4.171 (Business Edition)
Hash: 2593576
Branch: 
Build date: 2013-31-10 21:12:14-0400

Build Information
Release ID: 401130017
Git revision: 9f5e11a6c7592b94b3cbb3582fcf0f9d774b9710
Build date: 2013-11-01 20:33:42+0000
Xamarin addins: 98c72290fde44b199ca0344a8c52ab5ab9dbf56d

Operating System
Mac OS X 10.9.0
Darwin 192-168-1-89.tpgi.com.au 13.0.0 Darwin Kernel Version 13.0.0
    Thu Sep 19 22:22:27 PDT 2013
    root:xnu-2422.1.72~6/RELEASE_X86_64 x86_64



Mountain Lion machine:
17" late 2006 iMac (2.0 GHz core 2 duo, 4 GB 667 MHz DDR2 SDRAM, ATI Radeon X1600 128 MB)
OS X 10.8.4 (Had to use MLPostFactor to get ML to run on this machine as its unsupported hardware for the OS)
Using everything from the XS stable stream.
Xamarin Studio
Version 4.0.13 (build 38)
Installation UUID: 73707f7f-3edd-48cc-9eef-a0a360f6a43f
Runtime:
	Mono 3.2.3 ((no/8d3b4b7)
	GTK+ 2.24.20 theme: Raleigh
	GTK# (2.12.0.0)
	Package version: 302030000

Apple Developer Tools
Xcode 5.0.1 (3335.23)
Build 5A2053

Xamarin.iOS
Version: 7.0.2.7 (Business Edition)
Hash: 57edee2
Branch: 
Build date: 2013-04-10 18:05:51-0400

Xamarin.Mac
Xamarin.Mac: Not Installed

Xamarin.Android
Not Installed

Build Information
Release ID: 400130038
Git revision: 07afec667f7be5d0ee511eb7115bbac6377fbae8
Build date: 2013-09-24 08:53:29+0000
Xamarin addins: 61140345a5b109633a94409edcbc7a4c19a425c6

Operating System
Mac OS X 10.8.4
Darwin fourpilabsimac 12.0.0 Darwin Kernel Version 12.0.0
    Mon Jan 30 18:40:46 PST 2012
    root:xnu-2050.1.12~1/RELEASE_I386 i386
Comment 1 Sebastien Pouliot 2013-11-05 23:18:18 UTC
The default pre-built simlauncher was fixed (in 7.0.3) to workaround Mavericks issues. However when you (natively) link a static library a custom simlauncher is build and it will link with every required framework*

* based on monotouch.dll, which is why using the managed linker works around the issue.
Comment 2 Brad Moore 2013-11-05 23:33:17 UTC
I don't quite know what a simlauncher is, but does that mean the solution would be just to add in the fixes included in 7.0.3 into the thing that generates the custom symlauncher?
Comment 3 Brad Moore 2013-11-07 19:34:35 UTC
Any word if any progress is being made on this yet Sebastien?
Comment 4 Sebastien Pouliot 2013-11-08 08:51:11 UTC
It will be fixed in a future release. You can continue uinsg "Link SDK" in the mean time.

note: you're also welcome to file a bug with Apple (radar) too - as more duplicate often means more likely/speedy resolution. We can work around this but the real issue it in Mavericks.
Comment 5 Rolf Bjarne Kvinge [MSFT] 2013-11-08 13:00:14 UTC
*** Bug 14891 has been marked as a duplicate of this bug. ***
Comment 6 Brad Moore 2013-11-11 22:02:31 UTC
xcode 5.0.2 mentions iOS6 simulator fixes thou this error still occurs.
Comment 7 Brad Moore 2013-11-11 22:06:18 UTC
Rolf, can we unmark this as a duplicate of Bug 14891, apparently adding the extra mtouch arguments solved it for them.
Comment 8 Rolf Bjarne Kvinge [MSFT] 2013-11-12 06:57:26 UTC
Brad, bug #14891 is a dup, but a bit confusing since the reporter added several issues in the same bug report. All but one are problems with his project (i.e. comment 2 and 5), while the remaining issue (comment 14) is the real dup of this bug.
Comment 9 Sebastien Pouliot 2013-11-12 08:12:14 UTC
Wrt comment #6 there are several Xcode issues with the iOS simulator and not all of them are fixed in 5.0.2 (i.e. Apple does not disclose all it's bugs is it's release notes, just the very common ones ;-).

Anyhow this issue is not with Xcode it's an interaction between the SDK and Mavericks (which influence which libraries gets loaded).
Comment 10 Bob Reck 2013-11-13 21:00:41 UTC
Guys, I'm having this same exact issue. I added myself to the list for this bug. I will try the Link SDK fix and see if that works for me.

Bob
Comment 11 Bob Reck 2013-11-14 09:41:46 UTC
Link SDK Assemblies did fix the issue for me. Will continue to use that until I hear otherwise. Thanks.
Comment 12 Sebastien Pouliot 2013-11-14 16:57:49 UTC
The main issue is that the build is done without knowing where it will execute, i.e. when building you can supply:

* the SDK version (e.g. --sdk=7.0)
* the minimum iOS version (e.g. -targetver=4.2)

and once built the .app will be given (separate invocation) to a 6.x simulator -> bang!

To fix this we don't provide the buggy "GameController" and "MediaAccessibility" frameworks when building with the SDK 7.0, on the simulator, without the linker on OSX Mavericks.


@Brad, all your 3 test cases starts (but the 3rd throws a ArgumentNullException, but I guess that's normal for `UrbanAirship.UAirship.TakeOff (null);` to do so.


Fixed in master / 92ee61e4348951090b1b70a9f492c713827d63cd

The fix should be available in the next maintenance (non-hotfix) release.
Comment 13 Brad Moore 2013-11-14 17:04:51 UTC
Awesome news!
Comment 14 PJ 2013-12-11 18:45:44 UTC
This fix is planned to be released with Xamarin.iOS 7.0.6, which should hit the beta channel before December 23rd.
Comment 15 Akhilesh kumar 2013-12-12 10:08:37 UTC
Today we have checked this issue with following builds :

XS 4.2.2 (build 2)
X.iOS 7.0.6.139

Now we are able to build and deploy attached sample in bug description successfully with iOS 6.1 simulator and device.

Hence closing this issue.
Comment 16 Oran Dennison 2013-12-17 19:35:16 UTC
Akhilesh, where can we get Xamarin.iOS build 7.0.6.139?  I don't see it in any of the channels.

I assume this would be released to the Alpha channel first, but since the Alpha channel is already on XS 4.3 and you listed XS 4.2.2, does this mean X.iOS 7.0.6 will soon be made available directly to the Beta channel?
Comment 17 Sebastien Pouliot 2013-12-17 20:34:36 UTC
Oran, 7.0.6.x will be available on the alpha channel once QA give its approval. Right now it's just an internal (candidate build) on which testing is being done.

Akhilesh is part of the QA team and just validated that this specific issue is really gone from 7.0.6.139. This validation is part of the process before moving to the alpha channel.
Comment 18 Rolf Bjarne Kvinge [MSFT] 2013-12-20 06:04:45 UTC
*** Bug 13602 has been marked as a duplicate of this bug. ***
Comment 19 Andy 2013-12-23 08:40:56 UTC
Just as a reference, I got the same issue while linking to Google Admob monotouch bindings. Workaround of linking sdk assemblies worked, nothing else.

Waiting for update to get to stable channel