[Mono-bugs] [Bug 81642][Maj] New - Too many heap sections exception when adding many elements to a hashtable.

[bugzilla-daemon at 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 jonathan.gagnon at croesus.com.

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

--- shadow/81642	2007-05-16 15:12:56.000000000 -0400
+++ shadow/81642.tmp.5819	2007-05-16 15:12:56.000000000 -0400
@@ -0,0 +1,113 @@
+Bug#: 81642
+Product: Mono: Runtime
+Version: 1.2
+OS: other
+OS Details: Fedora Core 3
+Status: NEW   
+Resolution: 
+Severity: 
+Priority: Major
+Component: GC
+AssignedTo: lupus at ximian.com                            
+ReportedBy: jonathan.gagnon at croesus.com               
+QAContact: mono-bugs at ximian.com
+TargetMilestone: ---
+URL: 
+Cc: 
+Summary: Too many heap sections exception when adding many elements to a hashtable.
+
+Please fill in this template when reporting a bug, unless you know what 
+you are doing.
+Description of Problem:
+
+Getting the following exception when adding many objects to a hashtable :
+
+Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS
+
+Steps to reproduce the problem:
+Compile and execute the attached examples Hashtable.cs or 
+Serialization.cs.
+
+Actual Results:
+
+Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS
+Stacktrace:
+
+  at (wrapper managed-to-native) 
+System.Object.__icall_wrapper_mono_array_new_specific (intptr,int) 
+<0x00004>
+  at (wrapper managed-to-native) 
+System.Object.__icall_wrapper_mono_array_new_specific (intptr,int) 
+<0xffffffff>
+  at System.Collections.Hashtable..ctor 
+(int,single,System.Collections.IHashCodeProvider,System.Collections.ICompa
+rer
+) <0x0010a>
+  at System.Collections.Hashtable..ctor (int,single) <0x0001a>
+  at System.Collections.Hashtable..ctor () <0x00014>
+  at System.Runtime.Remoting.Contexts.Context..cctor () <0x00019>
+  at (wrapper runtime-invoke) System.Object.runtime_invoke_void 
+(object,intptr,intptr,intptr) <0xffffffff>
+
+Native stacktrace:
+
+        mono [0x8147e11]
+        [0xffffe600]
+        /lib/tls/i686/libc.so.6(abort+0xe4) [0x5563ee50]
+        mono [0x8107944]
+        mono [0x8101cd5]
+        mono [0x8101e92]
+        mono [0x8102109]
+        mono [0x8102230]
+        mono [0x8104585]
+        mono [0x8104634]
+        mono [0x81048be]
+        mono(mono_array_new_specific+0xb3) [0x808b1cb]
+        [0x55e8dbea]
+        [0x55e8e0cb]
+        [0x55e8ddd3]
+        [0x55e8dab5]
+        [0x55e8eae2]
+        [0x55e8daf6]
+        mono(mono_runtime_class_init+0x259) [0x808a2c9]
+        mono [0x8133b69]
+        mono [0x809ea7e]
+        mono [0x809f99f]
+        mono [0x80b6b45]
+        mono [0x80f87aa]
+        mono [0x810b5a9]
+        /lib/tls/i686/libpthread.so.0 [0x555e8080]
+        /lib/tls/i686/libc.so.6(__clone+0x5e) [0x556ce23e]
+
+Debug info from gdb:
+
+
+
+=================================================================
+Got a SIGABRT while executing native code. This usually indicates
+a fatal error in the mono runtime or one of the native libraries
+used by your application.
+=================================================================
+
+Aborted
+
+
+Expected Results:
+
+No exception.
+
+How often does this happen? 
+
+Every time with the attached examples.
+
+Additional Information:
+
+It seems like the bug does not occur on every linux distros.  I have the 
+error running Fedora core 3.  I don't have the error if I run on Mono 
+Windows, but when I run the serialization program on Mono Windows, the 
+resulting stream is not always of the same size, although I am always 
+serializing the same data, which is unexpected.
+
+Slightly changing the value of the "num" variable inside the examples may 
+lead to different results.  Sometimes I get some kind of infinite loop 
+where the runtime allocates 2.8 gigs of memory and takes all the cpu.