Bug 7422 - Crashes generating class init trampoline
Summary: Crashes generating class init trampoline
Status: RESOLVED FIXED
Alias: None
Product: iOS
Classification: Xamarin
Component: XI runtime ()
Version: 6.0.x
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: Untriaged
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2012-09-24 13:25 UTC by Michael Bayne
Modified: 2012-10-02 13:09 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 Michael Bayne 2012-09-24 13:25:22 UTC
After upgrading to the latest MonoTouch, I'm seeing a lot of crashes like this:


0   libsystem_kernel.dylib        	0x31ae3350 __pthread_kill + 8
1   libsystem_c.dylib             	0x36ebe11e pthread_kill + 54
2   libsystem_c.dylib             	0x36efa96e abort + 90
3   dictionopolis                 	0x00e446d0 mono_handle_native_sigsegv (mini-exceptions.c:2281)
4   dictionopolis                 	0x00e75c34 sigabrt_signal_handler (mini-posix.c:196)
5   libsystem_c.dylib             	0x36ec7e90 _sigtramp + 40
6   libsystem_c.dylib             	0x36ebe11e pthread_kill + 54
7   libsystem_c.dylib             	0x36efa96e abort + 90
8   dictionopolis                 	0x00e19536 monoeg_g_log (goutput.c:159)
9   dictionopolis                 	0x00e1e5c2 get_numerous_trampoline (aot-runtime.c:3527)
10  dictionopolis                 	0x00e21dd2 mono_aot_create_specific_trampoline (aot-runtime.c:3587)
11  dictionopolis                 	0x00e48e4a mono_create_class_init_trampoline (mini-trampolines.c:1171)
12  dictionopolis                 	0x00dff35a mono_resolve_patch_target (mini.c:3080)
13  dictionopolis                 	0x00e22176 mono_aot_plt_resolve (aot-runtime.c:3203)
14  dictionopolis                 	0x00e47d9e mono_aot_plt_trampoline (mini-trampolines.c:770)
15  dictionopolis                 	0x0043e3f4 generic_trampoline_aot_plt + 132
16  dictionopolis                 	0x00b00c0c d11s_battle_client_PrePostScreen_createIface + 156
...

I'm still using -aot "nimt-trampolines=512" which may or may not be appropriate. Is there something else I should be doing trampoline-wise to avoid these crashes?
Comment 1 Sebastien Pouliot 2012-09-24 16:06:10 UTC
8   dictionopolis                     0x00e19536 monoeg_g_log (goutput.c:159)

^ that line indicates that the runtime printed something in the console log. Try using Xcode and look at the console logs after running/crashing your apps (or it might still be in your device history).

Augmenting the number of trampolines is very likely what's being printed out - but there's many (0, 1, 2) types of trampolines that might be needed. The message will tell you which limit you have hit.
Comment 2 Michael Bayne 2012-09-24 16:13:48 UTC
Great, thanks!

Is there reason to believe that I would need more trampolines as a result of the MonoTouch 6 upgrade? I already have my trampolines increased, but had not been running into this problem at all with the previous version (5.4.x).
Comment 3 Sebastien Pouliot 2012-09-24 16:22:36 UTC
Not really. MonoTouch 5.4 and 6.0 are pretty close, the later having iOS6 bindings included. 

It's likely you were very close to the limit of (one type of) trampolines and the little extra code (after linking) from MonoTouch 6 might have just been enough to trigger this.

Let us know if this console logs contains the right data to fix this (just in case it's somethign else). Thanks!
Comment 4 Michael Bayne 2012-09-24 16:28:09 UTC
I reproduced the crash and the logs indicated that I was out of trampolines of type 0 (which I had not changed from the default, I had only been increasing type 2 trampolines).

I've doubled those from 1024 to 2048, and I'll hopefully not see these crashes. They happened somewhat randomly, so I can't confirm that this fixes it, but it seems pretty likely that it will.
Comment 5 Sebastien Pouliot 2012-09-24 17:18:59 UTC
Thanks for confirming the fix!

It's not really random, but different executed code path will fill the slots at different places (so it will crash at different place for the same reason). Rolf has explained this a bit more in details in this post:

http://monotouch.2284126.n4.nabble.com/Understanding-the-impact-of-trampolines-td4495086.html
Comment 6 Miguel de Icaza [MSFT] 2012-10-02 09:51:53 UTC
In other news, we are developing a new technology that removes the need for manually setting trampolines for good.
Comment 7 Michael Bayne 2012-10-02 13:09:09 UTC
Excellent! I look forward to reading the interesting technical details in future release notes.