[Mono-bugs] [Bug 34963][Wis] New - Mono leaks lock/monitor handles

[bugzilla-daemon@rocky.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 tum@veridicus.com.

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

--- shadow/34963	Tue Dec  3 12:35:14 2002
+++ shadow/34963.tmp.29392	Tue Dec  3 12:35:14 2002
@@ -0,0 +1,126 @@
+Bug#: 34963
+Product: Mono/Runtime
+Version: unspecified
+OS: 
+OS Details: 
+Status: NEW   
+Resolution: 
+Severity: 
+Priority: Wishlist
+Component: misc
+AssignedTo: mono-bugs@ximian.com                            
+ReportedBy: tum@veridicus.com               
+QAContact: mono-bugs@ximian.com
+TargetMilestone: ---
+URL: 
+Cc: 
+Summary: Mono leaks lock/monitor handles
+
+Description of Problem:
+-----------------------
+
+When Monitor.Enter is first called on an object (say obj1), the mono 
+runtime creates an OS level handle for the lock on obj1.  When obj1 is 
+garbage collected or the last thread has left the lock, mono doesn't free 
+the OS level handle.
+
+
+Steps to reproduce the problem:
+-------------------------------
+
+You'll need a windows box.
+
+Open up Task Manager and make it display the handle count for the process 
+(View -> Select Columns -> Handle Count).
+
+Compile and run the following program using mono.  You should notice the 
+handle count skyrocket.
+
+
+---begin---testhandleleak.cs---
+
+using System;
+using System.IO;
+using System.Threading;
+
+public class Test
+{
+	public static void Main()
+	{		
+		for (;;)
+		{
+			object o = new object();
+
+			// Create a lock.  Task manager indicates
+			// that a handle is being allocated.
+			
+			lock (o)
+			{
+			}
+
+			System.GC.Collect();
+		}
+	}
+}
+
+---end---testhandleleak.cs---
+
+
+Actual Results:
+---------------
+
+Mono never frees handles for locks aquired on objects.
+
+
+Expected Results:
+-----------------
+
+The handles should be freed when the last lock has been released on the 
+object (or maybe when it has been garbage collected?).
+
+
+How often does this happen? 
+---------------------------
+
+All the time :(.
+
+
+Additional Information:
+-----------------------
+
+The MS.NET runtime doesn't appear to need to allocate handles for each 
+unique lock on an object and does not have this problem.
+
+Here's the code i used to test this:
+
+using System;
+using System.IO;
+using System.Collections;
+using System.Threading;
+
+class Test
+{
+	static void Main()
+	{
+		object x;
+		IList list = new ArrayList();
+
+		for (;;)
+		{
+			x = new Object();
+
+			Monitor.Enter(x);
+
+			// Prevent x from being collected.
+
+			list.Add(x);
+		}		
+	}
+}
+
+As you can see with the above code, LOTS of unique object locks are 
+created but the task manager doesn't seem to indicate much of an increase 
+in native OS handles.
+
+I stumbled on the handle leak by accident and it took a _long_ time to 
+trace the cause back to the lock :(.