[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.
http://bugzilla.ximian.com/show_bug.cgi?id=51776
--- 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
+Resolution:
+Severity: Unknown
+Priority: Normal
+Component: misc
+AssignedTo: mono-bugs@ximian.com
+ReportedBy: eric@sourcegear.com
+QAContact: mono-bugs@ximian.com
+TargetMilestone: ---
+URL:
+Cc:
+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
+difficulty.
+
+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:
+
+http://vaultpub.sourcegear.com/cmdline/vault_ob.zip
+
+For comparison purposes, a non-obfuscated version is at:
+
+http://vaultpub.sourcegear.com/cmdline/vault_no_ob.zip
+
+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
+listrepositories
+
+This command line assumes connectivity to contact the Vault server on
+vaultpub.sourcegear.com.
+
+When it works correctly, you get something like this:
+
+<vault>
+<listrepositories>
+ <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" />
+</listrepositories>
+<result success="yes" />
+</vault>
+
+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
+<vault>
+<error>
+A null value was found where an object instance was required
+</error>
+<exception>
+System.NullReferenceException: A null value was found where an object
+instance was required
+in (unmanaged) VaultCmdLineClient.VaultCmdLineClient:Login (bool,bool)
+in <0x00015> VaultCmdLineClient.VaultCmdLineClient:Login ()
+in <0x00026>
+VaultCmdLineClient.VaultCmdLineClient:ProcessCommandListRepositories ()
+in <0x01a38> VaultCmdLineClient.VaultCmdLineClient:ProcessCommand ()
+in <0x028ef> VaultCmdLineClient.VaultCmdLineClient:ProcessCommand ()
+in <0x00111> VaultCmdLineClient.VaultCmdLineClient:.ctor (string[])
+
+</exception>
+<result success="no" />
+</vault>
+
+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[]
+'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.
+
+------- 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
+workaround.
+
+
+
+------- 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
+future.
+
+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 ?