Mono Boehm vs SGen GC - ios

Question

I have an application developed (renamed in my error as MyApplication for privacy) on the following enviroment:
Monotouch 2.1
MonoDevelop 2.4.2
MacOS 10.6.8
iOS SDK 4.3
that work fine.
Now i'm try to migrate to iOS 5.0/5.1 and Monotouch 5.2.5 with MonoDevelop 2.8.8.4.
My application crashes immediately with the following error:
Stacktrace:
at (wrapper managed-to-native) MonoTouch.UIKit.UIApplication.UIApplicationMain (int,string[],intptr,intptr) <IL 0x0009f, 0xffffffff>
at MonoTouch.UIKit.UIApplication.Main (string[],string,string) [0x00042] in /Developer/MonoTouch/Source/monotouch/src/UIKit/UIApplication.cs:29
at MonoTouch.UIKit.UIApplication.Main (string[]) [0x00000] in /Developer/MonoTouch/Source/monotouch/src/UIKit/UIApplication.cs:34
at MyApplication.Application.Main (string[]) [0x00000] in /Users/MyPC/Projects/Test/MyApplication/Main.cs:19
at (wrapper runtime-invoke) <Module>.runtime_invoke_void_object (object,intptr,intptr,intptr) <IL 0x00050, 0xffffffff>
Native stacktrace:
0 MyApplication 0x000908fc mono_handle_native_sigsegv + 284
1 MyApplication 0x00005c98 mono_sigsegv_signal_handler + 248
2 libSystem.B.dylib 0x9138145b _sigtramp + 43
3 ??? 0xffffffff 0x0 + 4294967295
4 libobjc.A.dylib 0x02958753 prepareForMethodLookup + 93
5 libobjc.A.dylib 0x0294f069 lookUpMethod + 86
6 libobjc.A.dylib 0x0294f1d6 _class_lookupMethodAndLoadCache + 40
7 libobjc.A.dylib 0x029620e3 objc_msgSend + 87
8 UIKit 0x01cba799 -[UIControl sendAction:to:forEvent:] + 67
9 UIKit 0x01cbcc2b -[UIControl(Internal) _sendActionsForEvents:withEvent:] + 527
10 UIKit 0x01cbba1c -[UIControl touchesBegan:withEvent:] + 277
11 UIKit 0x01c4ed41 -[UIWindow _sendTouchesForEvent:] + 395
12 UIKit 0x01c2fc37 -[UIApplication sendEvent:] + 447
13 UIKit 0x01c34f2e _UIApplicationHandleEvent + 7576
14 GraphicsServices 0x03fa5992 PurpleEventCallback + 1550
15 CoreFoundation 0x00df8944 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 52
16 CoreFoundation 0x00d58cf7 __CFRunLoopDoSource1 + 215
17 CoreFoundation 0x00d55f83 __CFRunLoopRun + 979
18 CoreFoundation 0x00d55840 CFRunLoopRunSpecific + 208
19 CoreFoundation 0x00d55761 CFRunLoopRunInMode + 97
20 GraphicsServices 0x03fa41c4 GSEventRunModal + 217
21 GraphicsServices 0x03fa4289 GSEventRun + 115
22 UIKit 0x01c38c93 UIApplicationMain + 1160
23 ??? 0x090a61fc 0x0 + 151675388
24 ??? 0x090a60c8 0x0 + 151675080
25 ??? 0x090a59c0 0x0 + 151673280
26 ??? 0x090a590c 0x0 + 151673100
27 ??? 0x090a5997 0x0 + 151673239
28 MyApplication 0x0000a002 mono_jit_runtime_invoke + 722
29 MyApplication 0x00169efe mono_runtime_invoke + 126
30 MyApplication 0x0016dfe4 mono_runtime_exec_main + 420
31 MyApplication 0x00173405 mono_runtime_run_main + 725
32 MyApplication 0x00067205 mono_jit_exec + 149
33 MyApplication 0x002116d5 main + 2837
34 MyApplication 0x00003055 start + 53
35 ??? 0x00000004 0x0 + 4
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.
It is the same if i deploy it to iOS SDK 4.3. I'm thinking it might be a problem with the new GC SGen as mentioned here http://www.infoq.com/news/2012/02/MonoTouch-SGen
UPDATE: In fact error is showed on a Alert show as lv.Message = "Copy...";
Class Handle: the requested operation cannot be completed because the
object has been garbage collected
How could i solve it?

Answer 1

In MonoTouch 4 the GC is executed more aggressively to catch as early as possible a certain type of programming errors: ensuring that native objects aren't freed to early by the GC.
The most common pattern is to declare variables in a method:
void Method ()
{
var view = new UIView ();
otherNativeObject.NativeProperty = view;
}
What happens here is that the managed GC does not see that the otherNativeObject has a reference to the view, so when the method finishes executing, the GC will free the view. At a later point otherNativeObject will try to use the view, and you will end up with a crash similar to the one you reported (the exact stack trace and messages will vary a bit depending on where the freed native object is accessed).
The fix for the above example is easy, just make the view a class variable:
UIView view;
void Method ()
{
view = new UIView ();
otherNativeObject.NativeProperty = view;
}
now the GC will not be able to free the view when the method exits.
Note that this crash isn't new in MonoTouch 4, the effect of making the GC more aggressive is that you'll see the problem when debugging, as opposed to hearing it from your clients when they (very randomly) crash.