[Mono-bugs] [Bug 79060][Maj] Changed - CreateThread: error creating thread handle

bugzilla-daemon at bugzilla.ximian.com bugzilla-daemon at bugzilla.ximian.com
Thu Sep 21 18:35:28 EDT 2006

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 bugzilla at patearl.net.


--- shadow/79060	2006-09-21 16:36:39.000000000 -0400
+++ shadow/79060.tmp.8259	2006-09-21 18:35:28.000000000 -0400
@@ -240,6 +240,27 @@
 The problem may be in the threadpool somewhere.
 The thread pool creates threads and then about 10 seconds later it
 destroys one.  Once it destroys it, the threadpool thinks it doesn't
 have enough worker threads and creates another one.  Somehow, the
 handles from these automatically created/destroyed threads are leaking.
+------- Additional Comments From bugzilla at patearl.net  2006-09-21 18:35 -------
+I assume that thread handled should stick around until the thread
+finishes executing.  If so, it seems that the leaking wapi handles
+(created in the thread pool) are caused by missing code in 
+mono/metadata/threads.c:start_wrapper() function.  After looking
+through all the code that occurs after the main thread function is
+called, I don't see any place that the wapi handle would be released.
+Brian pointed out on the mailing list that there is a finalizer that
+should get called by the garbage collector for thread instances.
+However, I believe the thread pool threads are not garbage collected
+and as such are leaking handles.
+Adding an explicit CloseHandle(thread->handle) call right after
+thread_cleanup in the start_wrapper function stopped those
+particularly nasty thread pool leaks for me.  Since start_wrapper also
+seems to be used for garbage collected threads, perhaps this is not
+the best solution.  Maybe there needs to be a flag in start_info that
+indicates if a thread should manually free its handle or not.

More information about the mono-bugs mailing list