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 [EMAIL PROTECTED] http://bugzilla.ximian.com/show_bug.cgi?id=82079 --- shadow/82079 2007-07-11 20:24:21.000000000 -0400 +++ shadow/82079.tmp.7509 2007-07-11 20:24:22.000000000 -0400 @@ -0,0 +1,104 @@ +Bug#: 82079 +Product: Mono: Class Libraries +Version: unspecified +OS: +OS Details: +Status: NEW +Resolution: +Severity: +Priority: Wishlist +Component: Cecil +AssignedTo: [EMAIL PROTECTED] +ReportedBy: [EMAIL PROTECTED] +QAContact: [EMAIL PROTECTED] +TargetMilestone: --- +URL: +Cc: +Summary: After applying Security Update for .NET Framework, Assembly User String table is written incorrectly + +Please fill in this template when reporting a bug, unless you know what +you are doing. + +Description of Problem: +After applying the Security Update for .NET Framework, the round-trip +reading and then writing of an Assembly produces errors in the User +String Table. [Security Update for Microsoft .NET Framework, Version 2.0 +(KB928365)] + +Analysis: +When Cecil reads an assembly, it calls System.Encoding.Unicode.GetString +(byte[], offset, length) to process the User String Table from the +assembly. Unfortunately, the length of the string in the string table is +the # of characters (x2) + 1 (byte) for the null terminator. The string +is actually terminated incorrectly as unicode NULL should be 0x0000, not +0x00. + +The routine System.Encoding.Unicode.GetString() does not expect to be +passed a length that includes the NULL & with the security patch applied +generates a string with \ufffd appended, causing all kinds of grief. +Prior to the update, this was innocuous as embeded NULLs in strings +caused the NULL & contents following to be dropped. The Security Update +translates them into an Invalid Unicode Character (0xfffd). + +I found the offending problem in Mono.Cecil.Metadata\UserStringsHeap.cs, +ReadStringAt() and applied the fix (length-1) vs (length). + +>>> return Encoding.Unicode.GetString (this.Data, offset, length-1); + +Other locations where this routine is called all pass the correct (even) +length. + +Steps to reproduce the problem: +1. Create a simple JavaScript program & compile with JSC (sorry, but +that's what I do, you could probably build any assembly that had a string +in it. + +Ex: +import System; +package Foo { + class Bar { + function hello() { + System.Console.WriteLine("Hello World"); + } + } +} + +jsc -t:library hello.js + +# builds hello.dll + +2. Next, read the .dll using Cecil & write it back out: +Something like: +using System; +using System.IO; +using System.Text; +using Mono.Cecil; + +namespace Foo { + class Program { + public static void Main(string[] args) { + AssemblyDefinition Assembly; + Assembly = AssemblyFactory.GetAssembly(args[0]); // name on cmd +line + string outFilename = args[0] + ".out"; + + AssemblyFactory.SaveAssembly(Assembly, outFilename); + } + } +} + +3. Load the resultant output assembly in ILDasm or .NET Reflector :-). +Inspect the IL for Main(). + +Actual Results: +Note that the string is "Hello World\ufffd". + +Expected Results: +"Hello World" in the original .dll + +How often does this happen? +Every time if you've applied the security update to .NET [Security Update +for Microsoft .NET Framework, Version 2.0 (KB928365)] + + +Additional Information: _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
