[Mono-bugs] [Bug 75518][Maj] New - runtime deadlocks on a simple, non-threaded program

[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 trow at ximian.com.

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

--- shadow/75518	2005-07-10 01:03:14.000000000 -0400
+++ shadow/75518.tmp.8680	2005-07-10 01:03:14.000000000 -0400
@@ -0,0 +1,74 @@
+Bug#: 75518
+Product: Mono: Runtime
+Version: 1.1
+OS: 
+OS Details: 
+Status: NEW   
+Resolution: 
+Severity: 
+Priority: Major
+Component: GC
+AssignedTo: mono-bugs at ximian.com                            
+ReportedBy: trow at ximian.com               
+QAContact: mono-bugs at ximian.com
+TargetMilestone: ---
+URL: 
+Cc: 
+Summary: runtime deadlocks on a simple, non-threaded program
+
+I've run into an annoying deadlock while hacking on my heap profiler.  The
+deadlock is in program that reads and analyzes the file containing the GC
+history.  It is a simple, single-threaded program than just opens the
+history file and parses it using a BinaryReader.
+
+The deadlock is repeatable and always happens at the same point in the file
+for a given executable.  Adding debug spew to the program changes the point
+where the deadlock happens.
+
+This is with mono 1.1.8.2 on SUSE 9.3.
+
+Here is a backtrace of the deadlocked program produced with mdb:
+(mdb) bt
+(*) #0: 0x401609fe in GC_mark_from+0x4ee
+    #1: 0x40160291 in GC_mark_some+0x201
+    #2: 0x40159335 in GC_stopped_mark+0xb5
+    #3: 0x40158f34 in GC_try_to_collect_inner+0xa4
+    #4: 0x4015a073 in GC_collect_or_expand+0x93
+    #5: 0x4015a2b6 in GC_allocobj+0xe6
+    #6: 0x4015ea51 in GC_generic_malloc_inner+0xc1
+    #7: 0x4015eb71 in GC_generic_malloc+0x61
+    #8: 0x4015ee5d in GC_malloc+0xad
+    #9: 0x400db580 in mono_array_new_specific+0xc0
+    #10: 0x400db46e in mono_array_new+0x4e
+    #11: 0x40d8aea2
+    #12: 0x40fa5467 in
+System.Collections.SortedList.InitTable(System.Int32,System.Boolean)+0x3f
+at
+/tmp/scratch/BUILD/mono-1.1.8.2/mcs/class/corlib/System.Collections/SortedList.cs:565
+    #13: 0x40fa53d6 in
+System.Collections.SortedList..ctor(System.Collections.IComparer,System.Int32)+0x56
+at
+/tmp/scratch/BUILD/mono-1.1.8.2/mcs/class/corlib/System.Collections/SortedList.cs:91
+    #14: 0x40fa5337 in System.Collections.SortedList..ctor()+0x27 at
+/tmp/scratch/BUILD/mono-1.1.8.2/mcs/class/corlib/System.Collections/SortedList.cs:71
+    #15: 0x40fa50ab in
+HeapBuddy.ObjectHistory..ctor(System.String,HeapBuddy.Backtrace)+0x2b
+    #16: 0x40fa4f29 in
+HeapBuddy.HeapBuddyMain.OnGcInfo(System.Int32,System.String,HeapBuddy.Backtrace,HeapBuddy.ObjectStats)+0x79
+at /home/trow/src/heap-buddy/analyzer/HeapBuddy.cs:48
+    #17: 0x40fa4e98
+    #18: 0x40fa4bf1 in HeapBuddy.OutfileReader.ProcessGc()+0x1e9 at
+/home/trow/src/heap-buddy/analyzer/OutfileReader.cs:251
+    #19: 0x40d93a83 in HeapBuddy.OutfileReader.ProcessOneChunk()+0x103 at
+/home/trow/src/heap-buddy/analyzer/OutfileReader.cs:137
+    #20: 0x40d9391c in HeapBuddy.OutfileReader.Load()+0x24 at
+/home/trow/src/heap-buddy/analyzer/OutfileReader.cs:100
+    #21: 0x40d8a95d in HeapBuddy.HeapBuddyMain.Main(System.String[])+0x1c5
+at /home/trow/src/heap-buddy/analyzer/HeapBuddy.cs:90
+
+Since the backtraces shows that we are stuck in the GC, I'm filing this bug
+under the 'GC' component.
+
+The heap-buddy source code is available from
+svn://svn.trowbridge.org/heap-buddy
+If you want the 38MB data file that triggers the deadlock, just let me know.