[Mono-bugs] [Bug 34963][Wis] Changed - 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.6970	Tue Dec  3 20:21:40 2002
@@ -1,14 +1,14 @@
 Bug#: 34963
 Product: Mono/Runtime
 Version: unspecified
-OS: 
+OS: unknown
 OS Details: 
 Status: NEW   
 Resolution: 
-Severity: 
+Severity: Unknown
 Priority: Wishlist
 Component: misc
 AssignedTo: mono-bugs@ximian.com                            
 ReportedBy: tum@veridicus.com               
 QAContact: mono-bugs@ximian.com
 TargetMilestone: ---
@@ -121,6 +121,30 @@
 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 :(.
+
+------- Additional Comments From tum@veridicus.com  2002-12-03 20:21 -------
+I've had time to trace the source of the bug in the runtime.  It 
+appears that mon_finalize (thread.c) fails to delete a critical 
+section (waiters_count_lock).
+
+Here's what I believe the fix should be.  I can't test this cause 
+the CVS build is broken :(.
+
+
+static void mon_finalize (void *o, void *unused)
+{
+	MonoThreadsSync *mon=(MonoThreadsSync *)o;
+	
+#ifdef THREAD_LOCK_DEBUG
+	g_message (G_GNUC_PRETTY_FUNCTION ": Finalizing sync");
+#endif
+	
+	CloseHandle (mon->monitor);
+	CloseHandle (mon->sema);
+	CloseHandle (mon->waiters_done);
+	DeleteCriticalSection(&mon->waiters_count_lock);
+}
+