A deadlock is caused while executing a simple Console.WriteLine( ) statement. The deadlock only occurs while using the /domain command line option. When you set this option to 'none', NUnit will sometimes deadlock when Console.WriteLine( ) in the
client test code is called (see below).
The issue was found for NUnit version 2.4.0, but it does also occur in version 2.4.8.
How to reproduce?
1. Build the following test code:
namespace NUnitDeadlock
{
[TestFixture]
public class Tester
{
public Tester()
{
}
[TestFixtureSetUp]
public void Init()
{
Console.WriteLine("\n---- Init ----");
}
[TestFixtureTearDown]
public void TearDown()
{
Console.WriteLine("\n---- TearDown ----");
}
[Test]
public void Foo()
{
Console.WriteLine("\n---- Foo ----");
}
}
}
2. Run the generated assembly (NUnitDeadlock.dll) using nunit- console.exe. Since the deadlock does not always occur, put the following in a batch file and then run the batch file:
:start
nunit-console.exe nunitdeadlock.dll /domain=none /
xml=nunitdeadlock.xml
goto start
Note that running the same test assembly in a loop (batch file) is necessary just to reproduce the deadlock. My test cases run as part of a daily regression test. Test cases are performed only once per regression test session. This leads to deadlocks (hang ups) as well (occasionally).
You will notice that after some time NUnit ends up in a deadlock. Attach a debugger to the running nunit-console.exe process and break into the debugger. The following is clear from the call stack:
- For one thread, the debugger breaks at NUnit.Core.EventQueue.Enqueue ( ), line 182. Here, a lock is done. This method is called, because
Console.WriteLine("\n---- Foo ----"); is being executed.
- For another thread, the debugger breaks at
NUnit.Core.TestRunnerThread.Wait( ), line 118. Here, a thread.Join( ) is done.
- For the third thread, the debugger breaks at
NUnit.ConsoleRunner.ConsolUi.EventCollector.TestStarted( ), line 450. Here, a Console.Write( ) is done.
When you run the same test assembly without the /domain option (I guess, NUnit then assumes a single domain), no deadlock occurs. Just remove /domain=none from the batch file, run the batch file, and you will notice that NUnit will execute the test case 30 minutes or more without problems.
Thus, it seems that executing Console.WriteLine in combination with / domain=none can cause a deadlock.
