[Mono-bugs] [Bug 76331][Cri] New - Objects on the stack can have their contents mangled

bugzilla-daemon at bugzilla.ximian.com bugzilla-daemon at bugzilla.ximian.com
Tue Oct 4 18:08:26 EDT 2005


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 will at cambia.com.

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

--- shadow/76331	2005-10-04 18:08:26.000000000 -0400
+++ shadow/76331.tmp.21585	2005-10-04 18:08:26.000000000 -0400
@@ -0,0 +1,145 @@
+Bug#: 76331
+Product: Mono: Runtime
+Version: 1.1
+OS: 
+OS Details: Fedora Core 4, Red Hat Enterprise 4
+Status: NEW   
+Resolution: 
+Severity: 
+Priority: Critical
+Component: GC
+AssignedTo: lupus at ximian.com                            
+ReportedBy: will at cambia.com               
+QAContact: mono-bugs at ximian.com
+TargetMilestone: ---
+URL: 
+Cc: 
+Summary: Objects on the stack can have their contents mangled
+
+Description of Problem:
+
+Under certain circumstances, it appears as if a structure on the stack 
+which contains a reference to a heap object has its contents mangled.
+
+Steps to reproduce the problem:
+
+Compile & run the following program:
+
+using System;
+using System.IO;
+using System.Reflection;
+
+namespace t {
+        public struct alloc {
+                public byte b1; public byte b2; public byte b3; public 
+byte b4;
+                public byte b5; public byte b6; public byte b7; public 
+byte b8;
+                public substruct sub;
+                public byte b13; public byte b14; public byte b15; public 
+byte b16;
+                public byte b17; public byte b18; public byte b19; public 
+byte b20;
+                public byte b21; public byte b22; public byte b23; public 
+byte b24;
+                public byte b25; public byte b26; public byte b27; public 
+byte b28;
+                public byte b29; public byte b30; public byte b31; public 
+byte b32;
+
+                public void DebugPrint() {
+                        string[] s = new string[sub.arr.Length];
+                        for (int i = 0; i < s.Length; i++) s[i] = sub.arr
+[i].ToString("x2");
+                        Console.WriteLine("{0}", string.Join(" ", s));
+                }
+        }
+        public struct substruct {
+                public byte b1;
+                public byte b2;
+                public byte[] arr;
+        }
+
+        class Test {
+                public static object Alloc(int num) {
+                        object[] ret = new object[10 * num];
+                        for (int i = 0; i < 10 * num; i++)
+                                ret[i] = new string((char)i, 50);
+                        return ret;
+                }
+                public static object Create(Type _type) {
+                        object o = Alloc(1);
+                        object ret = Activator.CreateInstance(_type);
+
+                        FieldInfo[] fields = _type.GetFields();
+                        foreach (FieldInfo field in fields) {
+                                Type fieldtype = field.FieldType;
+                                object o2 = Alloc(1);
+                                if (fieldtype.Equals(typeof(byte))) {
+                                        object o3 = Alloc(3);
+                                        field.SetValue(ret, 
+Activator.CreateInstance(fieldtype));
+                                } else if (fieldtype.Equals(typeof
+(substruct))) {
+                                        object o3 = Alloc(1);
+                                        field.SetValue(ret, Create
+(fieldtype));
+                                } else {
+                                        object o3 = Alloc(2);
+                                        field.SetValue(ret, new byte[4]);
+                                }
+                        }
+                        return ret;
+                }
+                static void Main() {
+                        alloc t = (alloc)Create(typeof(alloc));
+
+                        while (t.sub.arr.Length == 4) {
+                                t.DebugPrint();
+                        }
+                }
+        }
+}
+
+Actual Results:
+
+The program either throws an exception or exits
+
+Expected Results:
+
+The program should run forever
+
+How often does this happen? 
+
+Every time.
+
+Additional Information:
+
+What this program does is create a specially-laid-out structure in a 
+specific way, allocating heap memory as it goes.  The reproduction of 
+this bug is very dependant on the amount of memory you allocate while 
+constructing the object in question.  After the object is constructed and 
+placed on the stack in Main(), it will contain a reference to an array of 
+4 bytes.  The program then enters a while loop and prints out the 
+contents of the array each time through.  After some period of time (it 
+happens asynchronously but this test program it always happens very 
+quickly for me) the array reference will no longer be valid.  The address 
+stored in the structure has stayed the same but it appears the garbage 
+collector has ignored the outstanding reference and collected the memory 
+it points to.  This causes the array reference to point to random garbage 
+(this typically causes the loop to throw a NullReferenceException, but it 
+can also change the size or contents of the array as well).  Oddly enough 
+if I add a GC.Collect() directly after the allocation this will prevent 
+the bug from occurring.  Apparently there is a difference between the 
+full collection and whatever it is doing asynchronously when GC.Collect 
+is not present.
+
+While finding a small example which could reproduce this problem was 
+difficult, this behavior occurs regularly in our production code and is 
+causing immense havoc, since objects can no longer be trusted to contain 
+the values they were set to. Any help is greatly appreciated.
+
+The above code reproduces the bug on a celeron running Red Hat Enterprise 
+4 as well as a dual Xeon running Fedora Core 4.  I don't know if it will 
+work on other machines as it seems highly dependant on the behavior of 
+the memory allocator.


More information about the mono-bugs mailing list