[Mono-bugs] [Bug 74957][Wis] Changed - [PATCH] very strange NullRefernce (SEGV probably)

[bugzilla-daemon at bugzilla.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 malekith at pld-linux.org.

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

--- shadow/74957	2005-07-02 18:08:08.000000000 -0400
+++ shadow/74957.tmp.1505	2005-08-06 07:03:03.000000000 -0400
@@ -11,13 +11,13 @@
 AssignedTo: mono-bugs at ximian.com                            
 ReportedBy: malekith at pld-linux.org               
 QAContact: mono-bugs at ximian.com
 TargetMilestone: ---
 URL: 
 Cc: 
-Summary: very strange NullRefernce (SEGV probably)
+Summary: [PATCH] very strange NullRefernce (SEGV probably)
 
 Description of Problem:
 
 I have a problem with booting nemerle compiler under mono 1.1.7, amd64. A
 very tiny change (like adding a debug output, removing some file from
 compilation command line and so on) fixes the problem. It works perfectly
@@ -126,6 +126,62 @@
 
 Recently USE_MMAP was enabled on amd64 which appears to make this bug
 show up more often (I wasn't able to compile anything using nemerle
 compiler that used to work). I disabled it in my local mono tree.
 
 I'll get back to this issue, after all that generic stuff works...
+
+------- Additional Comments From malekith at pld-linux.org  2005-08-06 07:03 -------
+I guess I found it. It seems to be
+mono_arch_nullify_class_init_trampoline. The condition:
+
+if ((code [0] == 0x49) && (code [1] == 0xff)) {
+
+seems to happen by accident (the offset of callq is 0x49 0xff).
+code [-2] == 0xe8 is also true.
+
+I exchanged the conditions, like:
+
+Index: tramp-amd64.c
+===================================================================
+--- tramp-amd64.c       (revision 47928)
++++ tramp-amd64.c       (working copy)
+@@ -83,7 +83,15 @@
+ {
+        code -= 3;
+
+-       if ((code [0] == 0x49) && (code [1] == 0xff)) {
++       if (code [-2] == 0xe8) {
++               guint8 *buf = code - 2;
++
++               buf [0] = 0x66;
++               buf [1] = 0x66;
++               buf [2] = 0x90;
++               buf [3] = 0x66;
++               buf [4] = 0x90;
++       } else if ((code [0] == 0x49) && (code [1] == 0xff)) {
+                /* amd64_set_reg_template is 10 bytes long */
+                guint8* buf = code - 10;
+
+@@ -102,14 +110,6 @@
+                buf [10] = 0x90;
+                buf [11] = 0x66;
+                buf [12] = 0x90;
+-       } else if (code [-2] == 0xe8) {
+-               guint8 *buf = code - 2;
+-
+-               buf [0] = 0x66;
+-               buf [1] = 0x66;
+-               buf [2] = 0x90;
+-               buf [3] = 0x66;
+-               buf [4] = 0x90;
+        } else if (code [0] == 0x90 || code [0] == 0xeb || code [0] ==
+0x66)
+                /* Already changed by another thread */
+                ;
+
+and it seems to cure the problem. However I'm not sure if it won't
+break anything else.
+
+One way or another this code is wrong, just fails when offset happen
+to use the same byte pattern. Probably other code paths in this
+function should also be inspected.