Bug 8785 - No constructor found for MonoTouch.UIKit.UIControlEventProxy::.ctor(System.IntPtr)
Summary: No constructor found for MonoTouch.UIKit.UIControlEventProxy::.ctor(System.In...
Alias: None
Product: iOS
Classification: Xamarin
Component: XI runtime ()
Version: 6.0.x
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: Untriaged
Assignee: Bugzilla
Depends on:
Reported: 2012-12-05 16:51 UTC by Bart
Modified: 2013-12-05 18:35 UTC (History)
5 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 Bart 2012-12-05 16:51:35 UTC
I've been trying to debug a SIGSEGV error that was occurring after a touch event on a UIButton on a UITableView.

I asked about this problem on Xamarin chat as was told this often occurs because of garbage collection issues with anonymous delegates. As I'm using lambda expressions for the button touch handlers this seemed like it could be the problem. After changing around my code to use class methods, I received the following error below. When I've seen this particular error before, I was not creating a ctor that takes in an IntPtr handle. 

I likely still have issues with my code, but this seems like a bug in the MonoTouch implementation of UIControlEventProxy.

Selector invoked from objective-c on a managed object of type MonoTouch.UIKit.UIControlEventProxy (0x16D2EDC0) that has been GC'ed

System.Exception: Selector invoked from objective-c on a managed object of type MonoTouch.UIKit.UIControlEventProxy (0x16D2EDC0) that has been GC'ed ---> System.Exception: No constructor found for MonoTouch.UIKit.UIControlEventProxy::.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) [0x000f1] in /Developer/MonoTouch/Source/mono/mcs/class/corlib/System/Activator.cs:280
  at System.Activator.CreateInstance (System.Type type, System.Object[] args, System.Object[] activationAttributes) [0x00000] in /Developer/MonoTouch/Source/mono/mcs/class/corlib/System/Activator.cs:234
  at System.Activator.CreateInstance (System.Type type, System.Object[] args) [0x00000] in /Developer/MonoTouch/Source/mono/mcs/class/corlib/System/Activator.cs:229
  at MonoTouch.ObjCRuntime.Runtime.ConstructNSObject (IntPtr ptr, IntPtr klass) [0x0000d] in /Developer/MonoTouch/Source/monotouch/src/ObjCRuntime/Runtime.cs:210
  --- End of inner exception stack trace ---
  at MonoTouch.ObjCRuntime.Runtime.ConstructNSObject (IntPtr ptr, IntPtr klass) [0x00045] in /Developer/MonoTouch/Source/monotouch/src/ObjCRuntime/Runtime.cs:215
  at MonoTouch.ObjCRuntime.Runtime.GetNSObject (IntPtr ptr) [0x0001f] in /Developer/MonoTouch/Source/monotouch/src/ObjCRuntime/Runtime.cs:259
  at MonoTouch.ObjCRuntime.Runtime.GetNSObjectWrapped (IntPtr ptr) [0x00000] in /Developer/MonoTouch/Source/monotouch/src/ObjCRuntime/Runtime.cs:276
  at (wrapper native-to-managed) MonoTouch.ObjCRuntime.Runtime:GetNSObjectWrapped (intptr)
  at (wrapper managed-to-native) MonoTouch.UIKit.UIApplication:UIApplicationMain (int,string[],intptr,intptr)
  at MonoTouch.UIKit.UIApplication.Main (System.String[] args, System.String principalClassName, System.String delegateClassName) [0x0004c] in /Developer/MonoTouch/Source/monotouch/src/UIKit/UIApplication.cs:38
  at CHRobinson.eCommerce.Customer.App.iOS.Application.Main (System.String[] args) [0x00000] in /Users/bartsipes/Workspaces/MDeComm/Customer_App/Dev/Customer.App.iOS/Main.cs:17
Comment 1 Rolf Bjarne Kvinge [MSFT] 2012-12-05 17:40:03 UTC
Can you attach a test project that reproduces this issue?
Comment 2 Bart 2012-12-06 14:46:38 UTC
Unfortunately no, I haven't been able to get the problem to consistently reproduce in my own code. I'll keep trying to debug it and see if I can't get to a spot where I can consistently reproduce it then I'll try to create a test project.

I thought this might be a case where UIControlEventProxy should have the IntPtr ctor regardless of the scenario that produced this error.
Comment 3 Rolf Bjarne Kvinge [MSFT] 2012-12-06 17:06:53 UTC
UIControlEventProxy should not need this ctor, the problem is elsewhere.

I'll leave this bug as NEEDINFO for now then.
Comment 4 Miguel de Icaza [MSFT] 2012-12-10 11:36:11 UTC
Hello guys,

What I suspect is happening is the pattern where events are being attached to an UITableViewCell, and since nobody is referencing the UITableViewCell, the managed code is disposed.

As a workaround, what you kind do is keep all of the cells that you return from GetCell in a Hashtable associated with your view, for the duration of the view's life   That will fix the problem.

Something like:

HashSet<UITableViewCell> cache;

UITableViewCell GetCell (...)
    cell = new UITableViewCell (...);
    if (!cache.Contains (cell))
       cache [cell] = cell;

Then when you are done with the UITableViewCell, clear the cache:

cache = null;
Comment 5 Bart 2013-01-25 11:54:18 UTC
Hi all, I was finally able to get back to looking into this and Miguel's suggestion was right on target. In my scenario it wound up being the header views that needed to be cached (I added them in the GetViewForHeader method), but the early GC was the issue.

Thanks for your help. You can close this ticket now.
Comment 6 Miguel de Icaza [MSFT] 2013-01-25 14:48:28 UTC
We are working on a long-term solution that wont require this.

Stay tuned.
Comment 7 Alex Soto [MSFT] 2013-05-09 16:00:32 UTC
Here is a Small test case showing the error reported


Comment 8 PJ 2013-11-19 17:04:59 UTC
This bug has been in the NEEDINFO state with no changes for the last 90 days. Can we put this back into the NEW or CONFIRMED state, or are we still awaiting response?

If there is no change in the status of this bug over the next two weeks, this bug will be marked as NORESPONSE.
Comment 9 Bart 2013-11-19 17:09:47 UTC
PJ, are you asking me for a response? I had already reported I was able to work around the issue based on Miguel's example and Miguel said you guys are working on a long term fix. Have plans changed on that long term fix?
Comment 10 PJ 2013-12-05 18:35:16 UTC
This bug has not been changed from the NEEDINFO state since my previous comment, marking as RESOLVED NORESPONSE.

Please feel free to REOPEN this bug at any time if you are still experiencing the issue. Please add the requested information and set the bug back to the NEW (or CONFIRMED) state.