Bug 3205 - Assertion in aot-runtime.c:2232, condition `(guint8*)addr < (guint8*)jinfo->code_start + jinfo->code_size' not met
Summary: Assertion in aot-runtime.c:2232, condition `(guint8*)addr < (guint8*)jinfo->c...
Status: RESOLVED FIXED
Alias: None
Product: iOS
Classification: Xamarin
Component: XI runtime ()
Version: 5.2
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: Untriaged
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2012-02-02 13:46 UTC by jesse.attas
Modified: 2012-03-27 19:29 UTC (History)
3 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:
RESOLVED FIXED

Description jesse.attas 2012-02-02 13:46:45 UTC
This is the same crash location as bug 3008, but I'm filing a new bug in case they have different root causes.

The crash only happens on a device, not in the simulator. It happens intermittently from build to build (some builds show the crash, others don't). When you get a build with the crash, it will crash every time you execute the steps to reproduce. Sometimes a rebuild will fix the crash, sometimes it will not. 

The crash occurs while calling an empty constructor for one of my classes. The constructor is under a call stack that's instantiating a new UIView (although the constructor itself is not for a view, but for a utility class that the view uses).

Not sure if any of this is relevant, but the LLVM compiler is turned on with support for ARMv7 but not Thumb-2. We've increased the number of trampolines to 2048 as a workaround for another issue. I can try toggling any settings you suggest, but it will be tough to tell what's working because the crash is so intermittent to begin with.

Here's the top of the Console log for the device from Xcode:
Jan 31 14:58:58 unknown UIKitApplication:myappname[0xa717][8107] <Notice>: * Assertion at ../../../../../mono/mono/mini/aot-runtime.c:2232, condition `(guint8*)addr < (guint8*)jinfo->code_start + jinfo->code_size' not met
Jan 31 14:58:58 unknown UIKitApplication:myappname[0xa717][8107] <Notice>: Stacktrace:
Jan 31 14:58:58 unknown UIKitApplication:myappname[0xa717][8107] <Notice>:   at MyNameSpace.NumericPointerCoercionMode..cctor () <0x0007b>
Jan 31 14:58:58 unknown UIKitApplication:myappname[0xa717][8107] <Notice>:   at (wrapper runtime-invoke) object.runtime_invoke_dynamic (intptr,intptr,intptr,intptr) <0xffffffff>

Here's my version info:
MonoDevelop 2.8.6.3
Installation UUID: 1480f558-ce01-4cc9-8f58-058dda76f061
Runtime:
	Mono 2.10.8 (tarball Mon Dec 19 17:43:18 EST 2011)
	GTK 2.24.5
	GTK# (2.12.0.0)
Apple Developer Tools:
	 Xcode 4.2 (828)
	 Build 4D199
Monotouch: 5.0.4
Mono for Android not installed
Build information:
	Release ID: 20806003
	Git revision: f4289daf57621f5593ad5bf78b3ff5ad878e3c7a
	Build date: 2012-01-23 22:07:07+0000
Operating System:
	Mac OS X 10.7.2
Comment 1 Zoltan Varga 2012-02-02 15:22:42 UTC
Could you attach or send the exact binary build which reproduces the crash ?
Comment 2 Rolf Bjarne Kvinge [MSFT] 2012-02-03 03:35:07 UTC
This sounds very much like bug #707. Can you try the latest beta (where #707 has been fixed) to see if it still crashes?
Comment 3 jesse.attas 2012-02-03 14:59:31 UTC
I am happy to try both of those options. Just a few questions before we go down these paths:

1) Exactly which files would you want? The entire contents of bin/iPhone/Release?

2) Will you be able to deploy the binary to an iPad to test it? Won't it be provisioned with a developer profile for my company, blocking you from using it? 

3) We can try the beta build but due to the intermittent nature of the crash, we may not be able to conclude anything. The crash might go away because it was fixed in the beta or it might go away by luck. The only conclusive outcome would be if the crash is still repeatable in the beta. But we can try it and see what happens.
Comment 4 Rolf Bjarne Kvinge [MSFT] 2012-02-03 16:31:45 UTC
1) Yes, please.

2) It is possible to resign the application, so this is not a problem.

3) You'll obviously have to try out the beta for a while to see if it still happens, if you never get inconsistent builds again you can be fairly sure it's fixed.
Comment 5 jesse.attas 2012-02-03 18:04:11 UTC
I just emailed a build to you, Rolf and Varga. It was a big email attachment (20MB), so let me know if you don't receive it.
Comment 6 Rolf Bjarne Kvinge [MSFT] 2012-02-06 05:13:59 UTC
Jesse: I didn't get anything (iirc we have a 10mb attachment limit).

That said I'd appreciate it if you could try the latest beta first, since it is a lot easier and faster for you to just rebuild and retry using the beta than it is for us to figure out the problem disassembling the executable.
Comment 7 jesse.attas 2012-02-06 11:13:03 UTC
We'll try the beta this week and I'll let you know what we learn. I also emailed you the app again, broken into 3 smaller attachments.
Comment 8 Rolf Bjarne Kvinge [MSFT] 2012-02-09 18:22:11 UTC
You can also try the recently released MonoTouch 5.2 version, which incorporates the fixes I've previously mentioned as well.
Comment 9 jesse.attas 2012-02-20 16:58:06 UTC
We haven't seen this bug since upgrading MonoTouch to 5.2 (and subsequent updates).
Comment 10 Rolf Bjarne Kvinge [MSFT] 2012-02-20 17:55:09 UTC
Thanks for reporting back!

I will close this bug as a duplicate of #707 then. Feel free to reopen it if you ever run into the same issues again.

*** This bug has been marked as a duplicate of bug 707 ***
Comment 11 jesse.attas 2012-03-22 14:16:32 UTC
Unfortunately this bug has re-appeared for me. Pretty much the same call stack, except the assertion has moved to line 2247 in this build of MonoTouch. Let me know what I can do to help get this fixed.

Here's my current version info:

MonoDevelop 2.8.6.5
Installation UUID: 1480f558-ce01-4cc9-8f58-058dda76f061
Runtime:
	Mono 2.10.8 (tarball Mon Dec 19 17:43:18 EST 2011)
	GTK 2.24.5
	GTK# (2.12.0.0)
Apple Developer Tools:
	 Xcode 4.3.1 (1176)
	 Build 4E1019
Monotouch: 5.2.5
Mono for Android not installed
Build information:
	Release ID: 20806005
	Git revision: 96a2067d048f7e91f9515c869f214243f1926953
	Build date: 2012-02-17 03:31:11+0000
Operating System:
	Mac OS X 10.7.3
Comment 12 Rolf Bjarne Kvinge [MSFT] 2012-03-22 18:33:36 UTC
Can you attach the entire console output (including the full stack trace)?
Comment 16 Zoltan Varga 2012-03-26 14:17:35 UTC
I can reproduce this now. It looks like the usual thumb problem, the exception handling tables generated by LLVM contain offsets instead of direct pointers to compiled code, and the linker movements make these offsets invalid.
Comment 17 Zoltan Varga 2012-03-27 15:05:07 UTC
Should be fixed in mobile-master.