5

We have an NUnit test project with 1000 tests or so. The project contains high level component test mainly for a custom WPF control. The test process frequently fails on our build server (TeamCity) with:

InvalidOperationException "LocalDataStoreSlot storage has been freed"

mscorlib.dll!System.LocalDataStore.GetData(System.LocalDataStoreSlot slot)

mscorlib.dll!System.Threading.Thread.GetData(System.LocalDataStoreSlot slot)

WindowsBase.dll!System.Windows.Interop.ComponentDispatcher.CurrentThreadData.get() ...

The tests contain [RequiresSTA] attributes, Window.Show(), Dispatcher operations etc... so it is definitely not a regular unit test project.

The failure looks totally random, we have revisions where it occurs with 80% chance, however most of the time it doesn't happen at all. Absolutely mysterious, sometimes simple changes in the production code -like changing styles in the xaml code- triggers the failures, then the next change in the production code fixes it.

This specific random like failure makes our developer team pretty upset sometimes, our extended build system is hampered seriously by this failure.

We could very rarely reproduce it locally running the project with nunit-console.exe.

Have you guys ever seen such a test process failure? Any hints how to resolve this issue would be highly appreciated.

Thanks

pappati
  • 171
  • 1
  • 9
  • We have the same issue on our build servers, but using Jenkins. Almost never seen locally on dev machines. We also do much testing of WPF stuff that's not really unit tests. For a while the theory was that this problem arose with non-terminated dispatchers doing weird stuff, but now we seem to have it even when properly killing of any started dispatcher. Did you manage to solve this? Any updates at all? – Niclas Nov 14 '14 at 13:19
  • we are still struggling with it. No solution yet. – pappati Nov 15 '14 at 18:37

1 Answers1

1

We've encountered exactly the same issue in our environment (Jenkins, Windows 8, NUnit 2.6.3).

These measures fixed it for us.

  1. Ensure that NUnit doesn't run under .NET 3.5 or earlier. This post explains how.
  2. Work around the NUnit crash on shut-down by utilizing the NUnit runner command line option /nothread. If you're using the MS Build Community Tasks you need to set the TestInNewThread attribute of the NUnit task to false.

Some background information regarding the nature of the crash can be found in this MSDN forum thread. Eventually this needs to be fixed in NUnit.

Community
  • 1
  • 1
Rudi Brunner
  • 11
  • 1