Bug 7547 - MonoTouch 6.0.2 breaks generic struct type sub-classing of controllers/views
Summary: MonoTouch 6.0.2 breaks generic struct type sub-classing of controllers/views
Alias: None
Product: iOS
Classification: Xamarin
Component: General ()
Version: 6.0.x
Hardware: PC Mac OS
: --- normal
Target Milestone: Untriaged
Assignee: Bugzilla
Depends on:
Reported: 2012-09-29 14:21 UTC by t9mike
Modified: 2013-05-07 08:27 UTC (History)
7 users (show)

Is this bug a regression?: ---
Last known good build:

Stacktrace for AppMachine (37.74 KB, text/plain)
2012-10-25 14:43 UTC, Andrew Way
Source code for Stacktrace (5.14 KB, application/zip)
2012-10-25 14:44 UTC, Andrew Way

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 t9mike 2012-09-29 14:21:02 UTC
Fine prior to MT 6.0.2:

public abstract class RadioDialogViewController<TKey> : MuegelDialogViewController
   where TKey : struct

MuegelDialogViewController is ultimately a descendant of UITableViewController via MonoTouch.Dialog.

In 6.0.2:

Error MT4112: The registrar found an invalid type 'Com.Muegel.MonoTouch.Dialog.RadioDialogViewController`1'. The generic type argument 'TKey' must have a reference type constraint in order to be exportable to ObjectiveC. (MT4112)

I don't need this to be exportable to Objective-C. I have three other classes which can also not compile. Perhaps you can skip these cases and generate a warning and/or provide attribute to control this? I assume this is related to allowing Objective-C to call a .NET class, but I don't use this nor intend to anytime soon.
Comment 1 t9mike 2012-09-29 14:54:38 UTC
I verified that under 6.0.1 and below my overrides of ViewDidLoad(), LoadView(), etc. in the "problem" classes are called.
Comment 2 Sebastien Pouliot 2012-09-30 19:27:05 UTC
MT4112 was changed to be a warning in 6.0.3.
Comment 3 Rolf Bjarne Kvinge [MSFT] 2012-10-01 19:17:57 UTC
This has been fixed (to a warning) in 6.0.3.

Note that generic subclasses of exported types is not a supported scenario, and may fail/crash randomly. 

If you don't need your class to be exportable to ObjectiveC, then don't inherit from an exported class (any subclass of an exported class is automatically exported too).
Comment 4 James Moger 2012-10-03 13:54:01 UTC
Is that statement to cover your bases or is there a concrete issue with subclassing a ui controller with generics?  I use that trick too.
Comment 5 Rolf Bjarne Kvinge [MSFT] 2012-10-03 16:23:37 UTC
There are several issues when exporting generic classes - I spent several days last week tracking down a completely inexplicable crash because of it. You may be lucky and not run into any problems, but if/when you do, you'll have a hard time figuring out what's making your program crash.

We do plan to support this scenario in the future (or at least certain parts of it), but it's not on the immediate roadmap, so we don't have a timeline yet.
Comment 6 Ben Horgen 2012-10-04 17:28:25 UTC
My code base struggled with this issue too when compiled against the MT 6.0.2 release.  

I've used Generics all over my MT project when to creating additional views types within my MonoCross projects.  I've found only a few classes aren't compiling (ones built with multiple class inheritance rooting in a CocoaTouch object). 

I hadn't noticed any strange crashes in the apps, but maybe you've just saved me the future troubleshooting headaches Rolf; thanks for the insight!  I'll refactor it out for now, but generics help so much in creating reusable code bases.  With that said, switching it to a warning in MonoTouch 6.0.3 was appreciated.  

The 'NoDataConnectionView' abstract class in the code snippet below fails to compile in 6.0.2 however the 'MXTouchViewController' compiles without issue.  I would have expected the compiler to balk at both classes.

------ Code snippet -----

public abstract partial class NoDataConnectionView<T> : MXTouchViewController<T> { ... }

public abstract class MXTouchViewController<T>: UIViewController, IMXView { ... }
Comment 7 Andrew Way 2012-10-25 14:42:35 UTC
--- FROM APPMACHINE---  jouke@appmachine.com

In the mono/mini/aot_compiler.c a change was made to set the pointer info for the trampoline. (https://github.com/mono/mono/commit/2a63257bf810ddfdb9a1e36a4f899d1ae599d558#mono/mini/aot-runtime.c)

The ptr setting was changed from method (and default klass) to a method/klass or other. 
This change seems to affect the pointer tables kept internally. BTW: This is not the only place where this change is made, but the effect is the same.
If an interface (or and abstract class as in the 7457 case) with a generic parameter is used (i;e; IMyInterface<T> : ISomeOtherInterface), the table is corrupted.

The third or fourth time this info is used, I vrified this by running a fixed path in our platform which does this. It now reproduces the error consistently.
I reproduced this in a sample app, but the table corruption only appears with enough other type info in the app. So the sample app is too simple to reprodue the error.

The main generator for this kind of interfaces is based on an open source app (https://github.com/Redth/MonoTouch.UrlImageStore). Maybe you can combine my code or a sample app for this. I got sidetracked by a major issue, so I didn't have the time to finish the testing :-)

I attached a few stacktraces from the main app (AppstraDev) and  the sourcecode. If you pass this information on, you should be able to tackle this problem. If get the same issue reproducable in my testapp, I'll attach it to the bugreport. This is still registered as fixed by the way.

Anyway, let me know if I can test hotfixes or provide you with more information.
Comment 8 Andrew Way 2012-10-25 14:43:47 UTC
Created attachment 2792 [details]
Stacktrace for AppMachine

Submitted on behalf of jouke@appmachine.com
Comment 9 Andrew Way 2012-10-25 14:44:49 UTC
Created attachment 2793 [details]
Source code for Stacktrace

Submitted on behalf of jouke@appmachine.com
Comment 10 Andrew Way 2012-10-25 17:06:03 UTC
Moved APPMACHINE comments and created new bug report