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

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

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

--- shadow/79060	2006-09-22 12:13:08.000000000 -0400
+++ shadow/79060.tmp.24693	2006-10-13 08:45:37.000000000 -0400
@@ -268,6 +268,32 @@
 ------- Additional Comments From bugzilla at patearl.net  2006-09-22 12:13 -------
 Although the above CloseHandle eliminates the problem in the provided
 test, running XSP and doing mostly boring ASP.NET type things still
 leaks handles all over the place.  It's leaking handles more slowly,
 but still leaking them.  Is there some way that the wapi handles can
 be automatically freed when they're no longer needed?
+
+------- Additional Comments From dick at ximian.com  2006-10-13 08:45 -------
+Lines such as
+
+118 (  1) [ Thread]    4 Sg (proc: 18230, tid: -1232311376, state: 1,
+exit: 0, join: 0)
+119 (  1) [ Thread]    4 Sg (proc: 18230, tid: -1232311376, state: 1,
+exit: 0, join: 0)
+
+are normal, those handles will be closed when the thread object has
+been garbage collected and finalised.  The number of signalled
+threadpool threads should not grow unbounded when running the test
+from bug 78241; I see a maximum of 25 or so while running the test for
+about an hour.  You should  see the numbers in the first column vary
+over time, which shows that it's a different handle, old ones being
+finalised and removed.
+
+The errors you reported at startup are caused when the handle table is
+full.  When handles are "stale" (ie the number before Sg or Un is >
+59) the entries are removed on the assumption that no running mono
+process has a reference.  In normal operation the value will be reset
+to 0 every 10 seconds by a running process.
+
+It's possible that the problem you're seeing is caused by forked
+processes not being cleaned up properly.  I fixed a bug in this area
+yesterday, so please retest with svn head.