[Mono-bugs] [Bug 31654][Nor] New - jit generates incorrect code for get address of element in array of value types

[bugzilla-daemon@rocky.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by hwang_rob@yahoo.ca.

http://bugzilla.ximian.com/show_bug.cgi?id=31654

--- shadow/31654	Wed Oct  2 22:00:21 2002
+++ shadow/31654.tmp.4717	Wed Oct  2 22:00:21 2002
@@ -0,0 +1,98 @@
+Bug#: 31654
+Product: Mono/Runtime
+Version: unspecified
+OS: 
+OS Details: 
+Status: NEW   
+Resolution: 
+Severity: 
+Priority: Normal
+Component: misc
+AssignedTo: mono-bugs@ximian.com                            
+ReportedBy: hwang_rob@yahoo.ca               
+QAContact: mono-bugs@ximian.com
+TargetMilestone: ---
+URL: 
+Cc: 
+Summary: jit generates incorrect code for get address of element in array of value types
+
+Please fill in this template when reporting a bug, unless you know what you
+are doing.
+Description of Problem:
+
+When attempting to run some simple programs that use 2D arrays of decimals
+and structs, mono fails with an assertion error.  When using mint, it works.
+
+Steps to reproduce the problem:
+1. Here is a sample program.  Compile with mcs.  Run with mono.
+
+using System;
+
+class Test
+{
+    public static void Main()
+    {
+        decimal[,] tab = new decimal[2,2] {{3,4},{5,6}};
+
+        decimal d = tab[1,2];
+    }
+}
+
+
+Actual Results:
+
+The following exception occurs which actually is thrown when mono received
+a SIGSEGV from ves_array_element_address
+
+Unhandled Exception: System.NullReferenceException: A null value was found
+where an object instance was required
+
+Expected Results:
+
+Should run to completion.
+
+How often does this happen? 
+
+Always
+
+Additional Information:
+
+After some investigation, I believe the problem is in jit.c.  When mono
+processes attempts to get the address of an element in a 2D array of value
+types in order to handle the CALL, it incorrectly invokes
+arch_allocate_var... Through a chain of events (see x86.brg), this results
+in an additional lea+push to the stack so that, for example, to get the
+address of element d[1,2] you get something that looks like
+
+push   $0x2
+push   $0x1
+mov    %esi,%eax
+mov    $0x80e0aa8,%ecx
+push   %eax
+cmpl   $0x0,(%eax)
+lea    0xffffff54(%ebp),%edx
+push   %edx                       // wrong!
+call   *%ecx                      // call to ves_array_element_address
+
+Since ves_array_element_address expect the "this" pointer for the array to
+be the first argument, followed by the array indices, a SIGSEGV results.
+
+I made the following modification to jit.c, and it appears to work for me;
+no idea if this is indeed the correct fix:
+
+--- jit.c.orig  Wed Oct  2 14:56:06 2002
++++ jit.c   Wed Oct  2 14:42:28 2002
+@@ -2195,7 +2195,7 @@
+                this = mono_ctree_new_leaf (mp, MB_TERM_NOP);
+
+
+-           if (MONO_TYPE_ISSTRUCT (csig->ret)) {
++           if (MONO_TYPE_ISSTRUCT (csig->ret) && !array_rank) {
+                int size, align;
+                if (csig->pinvoke)
+                    size = mono_class_native_size (csig->ret->data.klass,
+&align);
+
+After applying this patch, I was able to run DecimalTest (from the Nunit
+tests) to completion (although there were some other failures in that unit
+test case, unrelated I believe to this problem).