Bugzilla – Bug 318324
[GMCS] strange difference in loading mono generated dll and its reassembled version
Last modified: 2007-09-15 21:24:46 UTC
---- Reported by nazgul@omega.pl 2005-06-20 16:20:10 MST ---- Please fill in this template when reporting a bug, unless you know what you are doing. Description of Problem: We came into a very strange issue. Assembly generated with nemerle (mono S.R.E) causes assertion in mono runtime, but after reassembling it (the IL is identicall) on MS.NET it runs ok. The t.exe was compiled with csc from class C : IComparable <C> { int IComparable<C>.CompareTo (C x) { return 1; } } class M { static void Main () { NemerleMap<C,int> y = new NemerleMap<C,int> (); y.Add (new C(), 1); } } tlib1.dll is compiled from nemerle public interface IComparable ['a] { CompareTo(x : 'a) : int; } internal struct NodeNem ['a, 'b] : IComparable [NodeNem ['a, 'b]] { public x : int; public CompareTo (x : NodeNem ['a, 'b]) : int { 1 } public this (k : 'a, v : 'b) { } } public class NemerleMap ['a, 'b] { public Add (k : 'a, v : 'b) : void { def x = NodeNem (k, v); null } } and tlib2.dll is generated by ildasm /text tlib1.dll > tlib2.il; ilasm /dll tlib2.il Steps to reproduce the problem: 1. Unpack attached testcase 2. run mono t.exe 3. mv tlib2.dll tlib1.dll 3. run mono t.exe Actual Results: ** ERROR **: file metadata.c: line 1790 (mono_metadata_parse_generic_param): assertion failed: (generic_context) aborting... Aborted clear run Expected Results: clear run clear run How often does this happen? Always Additional Information: Unfortunately I was not able to reproduce it with gmcs generated tlib (C# source is as follows) public interface IComparable <a> { int CompareTo(a x); } internal struct NodeNem <a, b> : IComparable <NodeNem <a, b> > { public int x; int IComparable<NodeNem<a,b>>.CompareTo (NodeNem <a, b> x) { return 1; } public NodeNem (a k, b v) { x = 1; } } public class NemerleMap <a, b> { public void Add (a k, b v) { NodeNem <a,b> x = new NodeNem <a,b> (k, v); } } Also I noticed, that changing struct to class in nemerle source made this error disappear... ---- Additional Comments From nazgul@omega.pl 2005-06-20 16:23:47 MST ---- Created an attachment (id=168154) Zip file containing binaries and C# code ---- Additional Comments From martin@ximian.com 2005-06-22 11:55:44 MST ---- Is this bug urgent or can it wait a few days ? I think it's better if I first fix monodis, so we can actually see what's going on here. ---- Additional Comments From nazgul@omega.pl 2005-06-22 12:46:21 MST ---- There is a workaround for it - the struct must be changed to class. So I guess it can wait. ---- Additional Comments From martin@ximian.com 2005-06-23 09:15:15 MST ---- Fixing this bug tured out to be easy in the end :-) I also tried to figure out why it worked with class and not with struct, ie. why tlib2.dll worked and tlib1.dll did not - this was hard. Both tlib1.dll and tlib2.dll PEVerify ok - so there must be some other reason. The only difference between them is that tlib1.dll is using a separate TypeSpec entry to the MethodOverride - in tlib2.dll, that typespec is already in the cache while in tlib1.dll it obviously isn't. So - finally FIXED in SVN. Imported an attachment (id=168154) Unknown bug field "cf_op_sys_details" encountered while moving bug <cf_op_sys_details>mono svn</cf_op_sys_details> Unknown operating system unknown. Setting to default OS "Other".