Bug 733 - System.MissingMethodException: No constructor found for ViewController::.ctor(System.IntPtr)
Summary: System.MissingMethodException: No constructor found for ViewController::.ctor...
Alias: None
Product: iOS
Classification: Xamarin
Component: General ()
Version: 4.x
Hardware: Macintosh Mac OS
: Normal critical
Target Milestone: 6.4 (async)
Assignee: Bugzilla
Depends on:
Reported: 2011-09-11 00:34 UTC by Andrew Young
Modified: 2013-07-09 03:15 UTC (History)
6 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 Andrew Young 2011-09-11 00:34:33 UTC
Usually when you see an error for "System.MissingMethodException: No constructor found for ViewController::.ctor(System.IntPtr)" its because you didn't keep a hard reference for your object around. I assure you that I'm keeping a ref to this ViewController via a private class member.

In low memory situations, when the phone has lots of background apps open, my app gets a memory warning and this is usually when the crash occurs. I think what is happening is that GC collects the ViewController before native code calls ViewDidUnload(). GC collecting the object is the right thing at that point because I am finished with the ViewController; I don't need it anymore.

Should I just go ahead and implement the ctor(IntPtr handle) to satiate MonoTouch? Implementing the ctor definitely gets rid of the crash. Or is there something else I can do?

[ERROR] FATAL UNHANDLED EXCEPTION: System.Exception: Selector invoked from objective-c on a managed object that has been GC'ed ---> System.MissingMethodException: No constructor found for SomeApp.iPhone.Controllers.Plans.Details.DetailsViewController::.ctor(System.IntPtr)
  at System.Activator.CreateInstance (System.Type type, BindingFlags bindingAttr, System.Reflection.Binder binder, System.Object[] args, System.Globalization.CultureInfo culture, System.Object[] activationAttributes) [0x00000] in <filename unknown>:0
  at System.Activator.CreateInstance (System.Type type, System.Object[] args, System.Object[] activationAttributes) [0x00000] in <filename unknown>:0
  at System.Activator.CreateInstance (System.Type type, System.Object[] args) [0x00000] in <filename unknown>:0
  at MonoTouch.ObjCRuntime.Runtime.ConstructNSObject (IntPtr ptr, IntPtr klass) [0x00000] in <filename unknown>:0
  --- End of inner exception stack trace ---
  at MonoTouch.ObjCRuntime.Runtime.ConstructNSObject (IntPtr ptr, IntPtr klass) [0x00000] in <filename unknown>:0
  at MonoTouch.ObjCRuntime.Runtime.GetNSObject (IntPtr ptr) [0x00000] in <filename unknown>:0
  at MonoTouch.ObjCRuntime.Runtime.GetNSObjectWrapped (IntPtr ptr) [0x00000] in <filename unknown>:0
  at (wrapper native-to-managed) MonoTouch.ObjCRuntime.Runtime:GetNSObjectWrapped (intptr)
  at MonoTouch.UIKit.UIApplication.Main (System.String[] args, System.String principalClassName, System.String delegateClassName) [0x00000] in <filename unknown>:0
  at MonoTouch.UIKit.UIApplication.Main (System.String[] args) [0x00000] in <filename unknown>:0
  at SomeApp.iPhone.Application.Main (System.String[] args) [0x00000] in /Users/Andrew/Projects/saambaa-iphone/SomeApp.iPhone/Main.cs:23
Terminating runtime due to unhandled exception
Native stacktrace:
	0   SomeAppiPhone                       0x00b597cc mono_handle_native_sigsegv + 412
	1   SomeAppiPhone                       0x00b85000 sigabrt_signal_handler + 148
	2   libsystem_c.dylib                   0x34bd272f _sigtramp + 42
	3   libsystem_c.dylib                   0x34bc73bb pthread_kill + 58
	4   libsystem_c.dylib                   0x34bbfbff abort + 78
	5   SomeAppiPhone                       0x00cc3874 monoeg_g_logv + 248
	6   SomeAppiPhone                       0x00cc3908 monoeg_assertion_message + 44
	7   SomeAppiPhone                       0x00b2dca0 mono_thread_abort + 224
	8   SomeAppiPhone                       0x00b581f0 mono_handle_exception_internal + 2436
	9   SomeAppiPhone                       0x00b58e68 mono_handle_exception + 108
	10  SomeAppiPhone                       0x00b82e64 mono_arm_throw_exception + 324
	11  SomeAppiPhone                       0x00833b14 throw_exception + 48
	12  SomeAppiPhone                       0x00491330 MonoTouch_ObjCRuntime_Runtime_GetNSObject_intptr + 144
	13  SomeAppiPhone                       0x004913b0 MonoTouch_ObjCRuntime_Runtime_GetNSObjectWrapped_intptr + 28
	14  SomeAppiPhone                       0x004cf1f8 wrapper_native_to_managed_MonoTouch_ObjCRuntime_Runtime_GetNSObjectWrapped_intptr + 64
	15  SomeAppiPhone                       0x00ce7744 get_managed_object_for_ptr + 136
	16  SomeAppiPhone                       0x00cea8e0 monotouch_trampoline + 76
	17  UIKit                               0x35df7a29 -[UIViewController unloadViewForced:] + 172
	18  UIKit                               0x35e076b9 -[UIViewController unloadViewIfReloadable] + 16
	19  UIKit                               0x35e4e12d -[UIViewController purgeMemoryForReason:] + 40
	20  UIKit                               0x35e4e14d -[UIViewController didReceiveMemoryWarning] + 16
	21  UIKit                               0x35e4e163 -[UIViewController _didReceiveMemoryWarning:] + 14
	22  Foundation                          0x3529d183 _nsnote_callback + 142
	23  CoreFoundation                      0x36eb420f __CFXNotificationPost_old + 402
	24  CoreFoundation                      0x36e4eeeb _CFXNotificationPostNotification + 118
	25  Foundation                          0x3529a5d3 -[NSNotificationCenter postNotificationName:object:userInfo:] + 70
	26  Foundation                          0x3529c1c1 -[NSNotificationCenter postNotificationName:object:] + 24
	27  UIKit                               0x35e24361 -[UIApplication _performMemoryWarning] + 48
	28  UIKit                               0x35e24d83 -[UIApplication _receivedMemoryNotification] + 126
	29  UIKit                               0x35e22507 _memoryStatusChanged + 42
	30  CoreFoundation                      0x36eb4d69 __CFNotificationCenterDarwinCallBack + 24
	31  CoreFoundation                      0x36eb1bdf __CFMachPortPerform + 210
	32  CoreFoundation                      0x36ebca97 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 26
	33  CoreFoundation                      0x36ebe83f __CFRunLoopDoSource1 + 166
	34  CoreFoundation                      0x36ebf60d __CFRunLoopRun + 520
	35  CoreFoundation                      0x36e4fec3 CFRunLoopRunSpecific + 230
	36  CoreFoundation                      0x36e4fdcb CFRunLoopRunInMode + 58
	37  GraphicsServices                    0x3660941f GSEventRunModal + 114
	38  GraphicsServices                    0x366094cb GSEventRun + 62
	39  UIKit                               0x35cf9d69 -[UIApplication _run] + 404
	40  UIKit                               0x35cf7807 UIApplicationMain + 670
	41  SomeAppiPhone                       0x004ce9f4 wrapper_managed_to_native_MonoTouch_UIKit_UIApplication_UIApplicationMain_int_string___intptr_intptr + 240
	42  SomeAppiPhone                       0x0049498c MonoTouch_UIKit_UIApplication_Main_string__ + 36
	43  SomeAppiPhone                       0x00328738 SomeApp_iPhone_Application_Main_string__ + 128
	44  SomeAppiPhone                       0x007e2d00 wrapper_runtime_invoke_object_runtime_invoke_dynamic_intptr_intptr_intptr_intptr + 200
	45  SomeAppiPhone                       0x00b32760 mono_jit_runtime_invoke + 2800
	46  SomeAppiPhone                       0x00c3c89c mono_runtime_invoke + 140
	47  SomeAppiPhone                       0x00c3f934 mono_runtime_exec_main + 784
	48  SomeAppiPhone                       0x00c3e964 mono_runtime_run_main + 1048
	49  SomeAppiPhone                       0x00b3ddf8 mono_jit_exec + 216
	50  SomeAppiPhone                       0x00b28d20 main + 5300
	51  SomeAppiPhone                       0x00002c08 start + 40
Debug info from gdb:
Got a SIGABRT while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
Comment 1 Andrew Young 2011-09-11 00:35:24 UTC
If you need a sample of our project I can provide via private email.
Comment 2 Sebastien Pouliot 2011-09-12 08:52:13 UTC
I'm not convince this is a (MT) bug. What's happening is that MonoTouch is trying to re-surface a native object and since it does not find an existing managed peer it will try to create a new one using the .ctor(IntPtr). Of course this new object will not be identical (e.g. state) to the original one and that might cause problem - depending on your application (e.g. if you were releasing native resources/memory from that code).

> GC collecting the object is the right thing at that
> point because I am finished with the ViewController; I don't need it anymore.

Here I assume that you do not have the (previously mentioned) reference to your view anymore, so "yes" (collect) and "no" (need). 

This situation can happen if the object was collected on the managed side while it still exists and being used on the native side. If you overrided ViewDidUnload then this could be the case (i.e. you still need that object). You can confirm this by implementing the .ctor(IntPtr) and put a breakpoint (or Console.WriteLine) on ViewDidUnload and other overrides/selectors you have.

You have two choices:

1) make sure the object is not used anymore natively before dropping your managed reference to it. That will make sure it won't be re-surfaced and re-allocated, which is something to avoid in a low-memory situation.

2) implement the .ctor after making sure the code it will call will not (now and in the future) cause issues when called from a new managed instance.

The first is safer against future code changes but can be harder to implement - but that really depends on your application.
Comment 3 Andrew Young 2011-09-12 15:18:08 UTC
I would like to go with method #1 but like you said it is more difficult to implement because you pretty much have no idea how long iOS will need your object to be kept alive for. In some cases you might not even need to keep your object alive. It just all depends on the whims of iOS and how much memory is available on the device; its not deterministic. I would like to be able to just get rid of my object when I need to and not have to worry about all the other variables of the environment to determine how long to keep my managed object alive.

Note: I logged this as a bug as suggested by Jeff Steadfast on the MonoTouch forums (I assume he's part of the MonoTouch team?)
Comment 4 Sebastien Pouliot 2011-09-15 14:59:44 UTC
I understand. It's hard to generalize a answer for #1, some bits depends on the type or on the application itself.

You might want to add #2 in "backup" and log when it's used (while debugging) to help you catch more cases and keep it around (maybe without logging) in non-debug builds until your sure #1 is complete.

note: Yes Jeff is a Xamaritan and whenever in doubt* always fill a bug

* with code and stacktraces ;-)
Comment 7 PJ 2013-07-09 03:15:57 UTC
Marking this one as RESOLVED, NO RESPONSE for now. Please feel free to re-open
if you still have an issue. If you do, please add full version info and, if
possible, some steps to reproduce or a test project.