Bug 12779 - AOT assertion: "* Assertion at ../../../../../mono/mono/metadata/metadata.c:3409, condition `ptr' not met"
Summary: AOT assertion: "* Assertion at ../../../../../mono/mono/metadata/metadata.c:3...
Alias: None
Product: iOS
Classification: Xamarin
Component: Tools ()
Version: 6.9.1.x
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: Untriaged
Assignee: Bugzilla
Depends on:
Reported: 2013-06-19 22:17 UTC by Brian Berry
Modified: 2013-06-20 08: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 Brian Berry 2013-06-19 22:17:59 UTC
Debug builds for a certain app of mine fail to AOT with the following symptom:

Compiling to native code
/Developer/MonoTouch/usr/bin/mtouch -sdkroot "/Applications/Xcode5-DP.app/Contents/Developer" --cache "/Users/XXX/WS/YYY/Application/iOS/obj/iPhone/Debug/mtouch-cache" --nomanifest --nosign -dev "/Users/XXX/WS/YYY/Application/iOS/bin/iPhone/Debug/iOS.app" -r "/Users/XXX/WS/PTCommon/bin/Debug/PTCommon.iOS.dll" -r "/Developer/MonoTouch/usr/lib/mono/2.1/System.dll" -r "/Developer/MonoTouch/usr/lib/mono/2.1/System.Xml.dll" -r "/Developer/MonoTouch/usr/lib/mono/2.1/System.Core.dll" -r "/Developer/MonoTouch/usr/lib/mono/2.1/monotouch.dll" -r "/Developer/MonoTouch/usr/lib/mono/2.1/OpenTK-1.0.dll" -debug -nolink -sdk "7.0" -targetver "4.3" --sgen --new-refcount --abi=armv7,armv7s "-compiler:clang" "/Users/XXX/WS/YYY/Application/iOS/bin/iPhone/Debug/iOS.exe"
AOT Compilation exited with code 134, command:
MONO_PATH=/Users/XXX/WS/YYY/Application/iOS/bin/iPhone/Debug/iOS.app /Developer/MonoTouch/usr/bin/arm-darwin-mono-sgen --debug -O=gsharedvt  --aot=mtriple=armv7-ios,full,static,asmonly,direct-icalls,dwarfdebug,no-direct-calls,iphone-abi,outfile=/var/folders/__/rbtxrnc93cxc_hvdsf74rtrr0000gn/T/tmp274d87f8.tmp/monotouch.dll.armv7.s "/Users/XXX/WS/YYY/Application/iOS/bin/iPhone/Debug/iOS.app/monotouch.dll"
* Assertion at ../../../../../mono/mono/metadata/metadata.c:3409, condition `ptr' not met

Mono Ahead of Time compiler - compiling assembly /Users/XXX/WS/YYY/Application/iOS/bin/iPhone/Debug/iOS.app/monotouch.dll

error MT3001: Could not AOT the assembly '/Developer/MonoTouch/usr/lib/mono/2.1/monotouch.dll'

Release builds for the same solution/project do not exhibit the behavior.
A minimal app does not demonstrate the behavior---I will attempt to find a repro case that I can attach to the report.

Xamarin Studio 4.1.4 with Xamarin.iOS
Comment 1 Sebastien Pouliot 2013-06-19 22:30:17 UTC
You can easily fix this by changing your application Deployment Target to 3.1 (or later, as required by your application).

The default (3.0) does not work when using the new Apple provider compiler (clang). This is a known issue and the next version will set the default value to 3.1 to avoid this.
Comment 2 Brian Berry 2013-06-19 22:34:24 UTC
I checked and my deployment target was set to 4.3.
I bumped it up to 7.0 and issued a clean build, no change in outcome.
Anything else I can do to extract more info for you?

Thanks for the quick response.
Comment 3 Sebastien Pouliot 2013-06-19 22:36:43 UTC
Uho, sorry, that was a different issue. This one is caused by the use of "Dont link" [1] on your project. 

This will be fixed in the next alpha release. Right now the workaround is to let the default "Link SDK" option on your project.

Note that you should not disable the linker as it will make your application a lot bigger [2], slower to build and disable quite a few optimizations for your application [3].

[1] `-nolink` on your command line
[2] Apple has a size limit for native executables
[3] See my Evolve presentation on Advanced Build Mecanics for more details @ http://xamarin.com/evolve/2013
Comment 4 Brian Berry 2013-06-19 22:53:01 UTC
Yep, now that worked.  Thanks.

Note that the default setting "Link SDK assemblies only" flags a warning at the right of the drop-down:  "Enabling this feature may hinder debugging....," which was likely what prompted me to back it off to the don't-link state (the IDE then reverts from warning to a normal info mouse-over state).   This is probably worth making a bit more clear --- or, if it's an illegal combination it should not be selectable.

(What should we be looking for in debugging degradation per the warning, anyway?)
Comment 5 Sebastien Pouliot 2013-06-20 08:34:23 UTC
The linker's job is to remove unused code. E.g. it can remove a property getter that is not used anywhere. OTOH you could find it useful while debugging (as a watch) to expose the state of an object.

So it *may* hinder debugging but, without it, it *does* hinder debugging too (requiring a lot more time to build and deploy to devices).