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

bugzilla-daemon@bugzilla.ximian.com bugzilla-daemon@bugzilla.ximian.com
Thu, 13 May 2004 15:55:07 -0400 (EDT)

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 edasque@ximian.com.


--- shadow/51776	2004-05-13 15:55:07.000000000 -0400
+++ shadow/51776.tmp.29240	2004-05-13 15:55:07.000000000 -0400
@@ -0,0 +1,202 @@
+Bug#: 51776
+Product: Mono: Runtime
+Version: unspecified
+OS: unknown
+OS Details: 
+Status: NEW   
+Severity: Unknown
+Priority: Normal
+Component: misc
+AssignedTo: mono-bugs@ximian.com                            
+ReportedBy: eric@sourcegear.com               
+QAContact: mono-bugs@ximian.com
+TargetMilestone: ---
+Summary: Mono 0.28 appears to have problems running obfuscated code
+The SourceGear Vault command-line client is usually obfuscated (using 
+Dotfuscator by Preemptive Solutions).  Mono seems to have trouble running 
+the obfuscated version but can run a non-obfuscated version with no 
+To reproduce this bug, you need the Vault command line client.  It 
+consists of vault.exe plus five supporting DLLs, all of which are managed 
+code written in C#.
+An obfuscated version is available here:
+For comparison purposes, a non-obfuscated version is at:
+These require no special installation.  Simply unzip and run vault.exe.
+Here is a command line for testing:
+vault.exe -host vaultpub.sourcegear.com -user guest -password guest 
+This command line assumes connectivity to contact the Vault server on 
+When it works correctly, you get something like this:
+ <repository name="Build_Tool_Integration" files="18" folders="2" 
+dbsize="0" />
+ <repository name="Default Repository" files="2" folders="5" dbsize="0" />
+ <repository name="nGallery" files="803" folders="73" dbsize="0" />
+<result success="yes" />
+When this fails, we see the following error messages:
+** (vault.exe:29842): WARNING **: constant for field 
+WorkingFolderFileStatus:_Deleted not found
+** (vault.exe:29842): WARNING **: constant for field 
+ChangeSetItemType:_Deleted not found
+** (vault.exe:29842): WARNING **: constant for field 
+PerformDeletionsType:_Deleted not found
+** (vault.exe:29842): WARNING **: constant for field 
+ConnectionStateType:_Deleted not found
+** (vault.exe:29842): WARNING **: constant for field 
+ClientInstance:_Deleted not found
+A null value was found where an object instance was required
+System.NullReferenceException: A null value was found where an object 
+instance was required
+in (unmanaged) VaultCmdLineClient.VaultCmdLineClient:Login (bool,bool)
+in &lt;0x00015&gt; VaultCmdLineClient.VaultCmdLineClient:Login ()
+in &lt;0x00026&gt; 
+VaultCmdLineClient.VaultCmdLineClient:ProcessCommandListRepositories ()
+in &lt;0x01a38&gt; VaultCmdLineClient.VaultCmdLineClient:ProcessCommand ()
+in &lt;0x028ef&gt; VaultCmdLineClient.VaultCmdLineClient:ProcessCommand ()
+in &lt;0x00111&gt; VaultCmdLineClient.VaultCmdLineClient:.ctor (string[])
+<result success="no" />
+This bug seems to be consistent and completely reproduceable.  
+It has been seen on several different machines.  
+The bug appears to be in Mono 0.28 and in Mono 0.29.
+It was first reproduced under Mono 0.28 on a Linux (Intel) box running Red 
+Hat 9.
+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[]
+        IL_0007:  ldarg.0 
+        IL_0008:  call instance void valuetype
+        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[]
+        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.
+------- Additional Comments From eric@sourcegear.com  2003-12-08 10:26 -------
+I assume you guys have spent lots of time debating the issue of 
+whether you are trying to be compatible with Microsoft .NET or with 
+the ECMA spec.  I am quite familiar with this kind of debate.  There 
+are good reasons why the spec is the way to go, and yet, every time 
+somebody finds a difference between your implementation and 
+Redmond's, they will consider it your bug, not theirs.
+Thanks for looking into this.  We'll probably just figure out a 
+------- Additional Comments From miguel@ximian.com  2003-12-16 09:46 -------
+In our conversation with Microsoft, they said:
+* It is a bug in the generated code.
+* They would make PEVerify catch this error in future versions.
+* People should not depend on the lax use of their current JIT, as it
+will not be portable to other JITs (third party, or Microsofts) in the
+So today is kind of a plus that it works.
+------- Additional Comments From edasque@ximian.com  2004-05-13 15:55 -------
+can we close this bug then ?