[Mono-bugs] [Bug 47659][Maj] New - Cannot create another AppDomain after a first one was created and unloaded.

[bugzilla-daemon@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 vargaz@freemail.hu.

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

--- shadow/47659	2004-01-09 11:21:09.000000000 -0500
+++ shadow/47659.tmp.10559	2004-01-09 11:21:09.000000000 -0500
@@ -0,0 +1,133 @@
+Bug#: 47659
+Product: Mono/Runtime
+Version: unspecified
+OS: Debian Woody
+OS Details: 
+Status: RESOLVED   
+Resolution: FIXED
+Severity: Unknown
+Priority: Major
+Component: misc
+AssignedTo: mono-bugs@ximian.com                            
+ReportedBy: JoergR@voelcker.com               
+QAContact: mono-bugs@ximian.com
+TargetMilestone: ---
+URL: 
+Cc: 
+Summary: Cannot create another AppDomain after a first one was created and unloaded.
+OtherBugsDependingOnThis: 49651
+
+Description of Problem:
+After one AppDomain was loaded and unloaded another AppDomain.CreateDomain
+call fails with NullReferenceException.
+
+Steps to reproduce the problem:
+1. Compile the attached source.
+2. Run it.
+
+Actual Results:
+Create AppDomain.
+AppDomain created.
+AppDomain unloaded.
+Create AppDomain.
+
+Unhandled Exception: System.NullReferenceException: A null value was found
+where an object instance was required
+
+
+Expected Results:
+Create AppDomain.
+AppDomain created.
+AppDomain unloaded.
+Create AppDomain.
+AppDomain created.
+AppDomain unloaded.
+
+How often does this happen? 
+Always.
+
+Additional Information:
+
+------- Additional Comments From JoergR@voelcker.com  2003-08-15 11:02 -------
+Created an attachment (id=5141)
+Test case
+
+
+------- Additional Comments From JoergR@voelcker.com  2003-08-15 11:05 -------
+One additional notice:
+The exception is not caught by the surrounding exception handler! Is
+the runtime corrupted after the second call?
+
+------- Additional Comments From vargaz@freemail.hu  2003-10-29 10:15 -------
+Fixed in CVS.
+
+------- Additional Comments From vargaz@freemail.hu  2003-10-29 15:27 -------
+Oops, I forgot to check in some remoting code which needs a review.
+Stay tuned...
+
+------- Additional Comments From vargaz@freemail.hu  2003-10-31 10:48 -------
+Created an attachment (id=5816)
+remoting changes
+
+
+------- Additional Comments From vargaz@freemail.hu  2003-11-01 14:23 -------
+This really works now.
+
+------- Additional Comments From JoergR@voelcker.com  2003-11-04 05:53 -------
+I have to reopen this bug because it doesn't work when cross AppDomain
+remoting is involved. AppDomain.Unload hangs when a remoting call was
+done to this AppDomain.
+
+Try the attached sample.
+
+Actual Results:
+Create AppDomain.
+AppDomain created.
+Hello from AppDomain Test 0
+
+
+Expected Results:
+Create AppDomain.
+AppDomain created.
+Hello from AppDomain Test 0
+AppDomain unloaded.
+Create AppDomain.
+AppDomain created.
+Hello from AppDomain Test 1
+AppDomain unloaded.
+
+
+------- Additional Comments From JoergR@voelcker.com  2003-11-04 05:55 -------
+Created an attachment (id=5864)
+Test case
+
+
+------- Additional Comments From vargaz@freemail.hu  2003-11-06 16:02 -------
+This seems to be caused by some strange threading problem. Here is what
+happens:
+
+- mono_domain_unload will create a new thread to do the unloading
+- that thread calls mono_threads_abort_appdomain_threads
+- that function aborts one thread, then calls wait_for_tids for the
+  thread to exit
+- wait_for_tids calls WaitForMultipleObjects with a timeout of 1000, but
+  that function never returns, despite the timeout
+
+Here is what happens in WaitForMultipleObjects:
+
+- it calls _wapi_handle_ops_own on the thread handle, which calls
+  thread_own, which calls _wapi_timed_thread_join, which waits on
+  the thread's exit_cond variable.
+- that variable should be signalled by _wapi_timed_thread_exit,
+  but that function is stuck in thread_exit, which is stuck in
+  mono_mutex_lock (&thread_hash_mutex)
+
+That mutex is owned by the CreateThread function which started this
+whole stuff. That function releases the mutex eventually, but the
+mono_mutex_lock call in thread_exit does not seem to notice this.
+
+Creating the original thread suspended and resuming it immediately
+seems to make the problem go away. I checked in this workaround.
+
+------- Additional Comments From vargaz@freemail.hu  2004-01-09 11:21 -------
+This was fixed some time ago.