---- Reported by bmaurer@users.sf.net 2005-02-18 16:12:01 MST ----

This test case will deadlock, usually within 10-20 iterations.

I am running on a hyperthreaded cpu, so that may be affecthing things.

using System;
using System.Threading;

class X {
	static void Main ()
	{
		Thread [] threads = new Thread [10];
		while (true) {
			
			for (int i = 0; i < threads.Length; i ++) {
				threads [i] = new Thread (Worker);
				threads [i].Start ();
			}
			
			for (int i = 0; i < threads.Length; i ++) {
				threads [i].Abort ();
			}
			
			Console.Write (".");
			
		}
	}
	
	static void Worker ()
	{
		while (true) {
			Type [] x = typeof (object).Assembly.GetTypes ();
		}
	}
}



---- Additional Comments From vargaz@gmail.com 2005-03-17 07:17:48 MST ----

This seems to be caused by this line in sigusr1_signal_handler ()
in mini.c:

	running_managed = (mono_jit_info_table_find (mono_domain_get (),
mono_arch_ip_from_context(ctx)) != NULL);

The jit_info_table_find () function acquires the domain lock, and
the pthread locking functions are not async safe, so they should only
be invoked from a signal handler if it is guaranteed that the code
interrupted by the signal is not inside another POSIX function. 
For the abort signal this is not true, since it can be
delivered while a thread is in pthread_mutex_lock () / unlock ().








---- Additional Comments From lluis@ximian.com 2005-05-09 07:50:58 MST ----

Is there any other safe way of determining if the thread has been
interrupted while running managed code?



---- Additional Comments From bmaurer@users.sf.net 2005-06-29 15:00:29 MST ----



*** This bug has been marked as a duplicate of https://bugzilla.novell.com/show_bug.cgi?id=MONO58065 ***


Unknown operating system unknown. Setting to default OS "Other".
This bug was marked DUPLICATE in the database it was moved from.
    Changing resolution to "MOVED"