[Mono-bugs] [Bug 51776][Nor] Changed - Mono 0.28 appears to have problems running obfuscated code

[bugzilla-daemon@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 lupus@ximian.com.

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

--- shadow/51776	2003-12-05 11:41:03.000000000 -0500
+++ shadow/51776.tmp.22594	2003-12-05 12:46:41.000000000 -0500
@@ -2,13 +2,13 @@
 Product: Mono/Runtime
 Version: unspecified
 OS: Fedora 1.0
 OS Details: 
 Status: NEW   
 Resolution: 
-Severity: 
+Severity: Unknown
 Priority: Normal
 Component: misc
 AssignedTo: mono-bugs@ximian.com                            
 ReportedBy: eric@sourcegear.com               
 QAContact: mono-bugs@ximian.com
 TargetMilestone: ---
@@ -103,6 +103,73 @@
 Identical results were obtained on another box (Linux Intel) running a 
 fresh install of Fedora 1.0, also with Mono 0.28.
 
 Something very similar happens under MacOS X using Mono 0.29.  The first 
 few error messages are identical, but it proceeds to fail in a different 
 way due to the current state of Mono on PPC.
+
+------- Additional Comments From lupus@ximian.com  2003-12-05 12:46 -------
+I fixed the _Deleted issue in my tree (the metadata for the field is
+wrong, but since it's marked as deleted we should ignore it anyway).
+There is another issue, though, that the obfuscated code triggers.
+And this one is a bug in the obfuscator: it produces non
+standard-conforming code. The issue was discussed a few months ago on
+the mono list and at the ECMA meeting as well. The MS folks admitted
+the behaviour is accidentally allowed by their jit, but it's
+non-standard and broken IL code.
+Basically, the tool arranges the basic blocks in the code, but in
+doing so it doesn't respect the standard rules that specifically say
+(Partition III):
+
+It must be possible, with a single forward-pass through the CIL
+instruction stream for any method, to infer the
+exact state of the evaluation stack at every instruction (where by
+"state" we mean the number and type of each
+item on the evaluation stack).
+In particular, if that single-pass analysis arrives at an instruction,
+call it location X, that immediately follows an
+unconditional branch, and where X is not the target of an earlier
+branch instruction, then the state of the
+evaluation stack at X, clearly, cannot be derived from existing
+information. In this case, the CLI demands that
+the evaluation stack at X be empty.
+Following on from this rule, it would clearly be invalid CIL if a
+later branch instruction to X were to have a
+non-empty evaluation stack
+
+This doesn't happen in the FileCRC32::.ctor() method whre the
+following code is found:
+        IL_0000:  ldarg.0 
+        IL_0001:  ldnull 
+        IL_0002:  stfld  unsigned int32[]
+'VaultLib.FileCRC32'::'_crc32Table'
+        IL_0007:  ldarg.0 
+        IL_0008:  call instance void valuetype
+[mscorlib]'System.Object'::.ctor()
+        IL_000d:  ldc.i4 79764919
+        IL_0012:  stloc.0 
+        IL_0013:  ldarg.0 
+        IL_0014:  ldc.i4 256
+        IL_0019:  newarr valuetype [mscorlib]'System.UInt32'
+        IL_001e:  stfld  unsigned int32[]
+'VaultLib.FileCRC32'::'_crc32Table'
+        IL_0023:  ldc.i4.0 
+        IL_0024:  stloc.1 
+        IL_0025:  br.s IL_0065
+
+        IL_0027:  ldloc.2 
+        IL_0028:  ldc.i4.8 
+        IL_0029:  blt.s IL_003b
+
+        IL_002b:  br IL_0089
+
+        IL_0030:  xor 
+[...]
+        IL_00aa:  ldloc.0 
+        IL_00ab:  br IL_0030
+
+With a linear scan of the code, we conclude that at IL_0030 there are
+no items on the stack, but xor requires to arguments, so the code is
+invalid IL and we refuse to compile it.
+You may try to see if you can disable the control flow tranformations
+in the obfuscator, that likely makes the tool generate
+standards-conforming code.