Bug 318757 (MONO75831) - [GMCS] [PATCH] Multidimensional array as generic paramater causes gmcs to crash
Summary: [GMCS] [PATCH] Multidimensional array as generic paramater causes gmcs to crash
Status: RESOLVED FIXED
Alias: MONO75831
Product: Mono: Compilers
Classification: Mono
Component: C# (show other bugs)
Version: unspecified
Hardware: Other Other
: P3 - Medium : Normal
Target Milestone: ---
Assignee: Martin Baulig
QA Contact: Mono Bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-08-17 15:15 UTC by Steffen Kieß
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
fix (2.38 KB, patch)
2005-08-22 22:41 UTC, Thomas Wiest
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Wiest 2007-09-15 19:27:43 UTC


---- Reported by kiess@h3c.de 2005-08-17 08:15:22 MST ----

Description of Problem: Using int[,] as a type parameter for a generic type
crashes gmcs


Steps to reproduce the problem:
1.
cat > test.cs << EOF
class B {
  System.Collections.Generic.List<int[,]> x;

  static void Main() {}
}
EOF
2. gmcs test.cs

Actual Results:

Unhandled Exception: System.NullReferenceException: Object reference not
set to an instance of an object
in <0x00000> <unknown method>
in (wrapper managed-to-native) System.Type:BindGenericParameters
(System.Type,System.Type[])
in <0x00068> System.Type:MakeGenericType (System.Type[] types)
in <0x000e7> Mono.CSharp.ConstructedType:DoResolveType
(Mono.CSharp.EmitContext ec)
in <0x0012f> Mono.CSharp.ConstructedType:ResolveConstructedType
(Mono.CSharp.EmitContext ec)
in <0x0000d> Mono.CSharp.ConstructedType:DoResolveAsTypeStep
(Mono.CSharp.EmitContext ec)
in <0x00011> Mono.CSharp.TypeExpr:ResolveAsTypeStep
(Mono.CSharp.EmitContext ec, Boolean silent)
in <0x00010> Mono.CSharp.Expression:ResolveAsTypeStep
(Mono.CSharp.EmitContext ec)
in <0x00149> Mono.CSharp.MemberAccess:ResolveNamespaceOrType
(Mono.CSharp.EmitContext ec, Boolean silent)
in <0x00012> Mono.CSharp.MemberAccess:ResolveAsTypeStep
(Mono.CSharp.EmitContext ec, Boolean silent)
in <0x00036> Mono.CSharp.Expression:ResolveAsTypeTerminal
(Mono.CSharp.EmitContext ec, Boolean silent)
in <0x00010> Mono.CSharp.Expression:ResolveAsTypeTerminal
(Mono.CSharp.EmitContext ec)
in <0x00065> Mono.CSharp.MemberBase:get_MemberType ()
in <0x0002d> Mono.CSharp.FieldMember:Define ()
in <0x0001f> Mono.CSharp.Field:Define ()
in <0x0005a>
Mono.CSharp.TypeContainer+MemberCoreArrayList:DefineContainerMembers ()
in <0x00014> Mono.CSharp.TypeContainer:DefineContainerMembers
(Mono.CSharp.MemberCoreArrayList mcal)
in <0x002ec> Mono.CSharp.TypeContainer:DoDefineMembers ()
in <0x0003f> Mono.CSharp.TypeContainer:DefineMembers
(Mono.CSharp.TypeContainer container)
in <0x00247> Mono.CSharp.RootContext:PopulateTypes ()
in <0x00ae1> Mono.CSharp.Driver:MainDriver (System.String[] args)
in <0x0001f> Mono.CSharp.Driver:Main (System.String[] args)


Expected Results:
The code should compile.

How often does this happen? 
Always

Additional Information:
The same error appears with the nemerle compiler, so the bug is probably in
System.Reflection.Emit.

I'm using Mono svn r48453.



---- Additional Comments From malekith@pld-linux.org 2005-08-22 09:21:58 MST ----

It seems to be ,,fixed'' by:

Index: metadata.c
===================================================================
--- metadata.c  (revision 48620)
+++ metadata.c  (working copy)
@@ -1642,8 +1642,8 @@

        cached = g_hash_table_lookup (generic_inst_cache, ginst);
        if (cached) {
-               for (i = 0; i < ginst->type_argc; i++)
-                       mono_metadata_free_type (ginst->type_argv [i]);
+               // for (i = 0; i < ginst->type_argc; i++)
+               //      mono_metadata_free_type (ginst->type_argv [i]);
                g_free (ginst->type_argv);
                g_free (ginst);
                return cached;

the problem is that some type is not duplicated, then freed and used
again.



---- Additional Comments From malekith@pld-linux.org 2005-08-22 09:49:33 MST ----

Ok, the real problem is that dup_type doesn't correctly copy stuff for
arrays (and for function pointers). It does for regular pointers
though (
http://lists.ximian.com/pipermail/mono-patches/2005-February/055177.html )

I will create a patch shortly.



---- Additional Comments From malekith@pld-linux.org 2005-08-22 15:40:27 MST ----

I attach a patch to fix this issue. It adds copying of MonoArrayType
and MonoMethodSignatur for MONO_TYPE_ARRAY and MONO_TYPE_FNPTR
respectively. Now it is safe to do:

  tmp = dup_type (t); 
  mono_metadata_free_type (tmp);
  use (t);

The dup_type function got quite big. Maybe it would be good not to
mark it inline and make it non-static, so only one copy can be used?
If so I can post a patch for it.




---- Additional Comments From malekith@pld-linux.org 2005-08-22 15:41:08 MST ----

Created an attachment (id=168371)
fix




---- Additional Comments From martin@ximian.com 2005-09-05 02:29:58 MST ----

Fixed in SVN.

Imported an attachment (id=168371)

Unknown bug field "cf_op_sys_details" encountered while moving bug
   <cf_op_sys_details>Debian Sarge</cf_op_sys_details>
Unknown operating system unknown. Setting to default OS "Other".