Bug 318324 (MONO75331) - [GMCS] strange difference in loading mono generated dll and its reassembled version
Summary: [GMCS] strange difference in loading mono generated dll and its reassembled v...
Status: RESOLVED FIXED
Alias: MONO75331
Product: Mono: Runtime
Classification: Mono
Component: misc (show other bugs)
Version: 1.0
Hardware: Other Other
: P3 - Medium : Normal
Target Milestone: ---
Assignee: Martin Baulig
QA Contact: Mono Bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-06-20 23:20 UTC by Kamil Skalski
Modified: 2007-09-15 21:24 UTC (History)
0 users

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
Zip file containing binaries and C# code (3.19 KB, application/octet-stream)
2005-06-20 23:23 UTC, Thomas Wiest
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Wiest 2007-09-15 19:22:01 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".