Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,026 | Comments: 44,842

filter by tags archive

Challengemulti threaded test failure

time to read 1 min | 192 words

On one of my machines, I can consistently get the following test failure, because of an exception throw here:


As you can see, we get an ObjectDisposedException here, which cause the test to fail. There is only one problem with that:


We only dispose the queue manager on the dispose method, and that can only be called if the test itself was completed.

On the face of it, it looks like I am doing things correctly, but there is a bug here. The CLR’s threading semantics are not broken, even though on first glance it appears so.

As a side note, people keep asking me how I blog so much. This post is a perfect example. When I started writing this blog post, I was truly stamped. By the time I finished, I already noticed where the bug was and fixed it.

Can you tell?

More posts in "Challenge" series:

  1. (28 Apr 2015) What is the meaning of this change?
  2. (26 Sep 2013) Spot the bug
  3. (27 May 2013) The problem of locking down tasks…
  4. (17 Oct 2011) Minimum number of round trips
  5. (23 Aug 2011) Recent Comments with Future Posts
  6. (02 Aug 2011) Modifying execution approaches
  7. (29 Apr 2011) Stop the leaks
  8. (23 Dec 2010) This code should never hit production
  9. (17 Dec 2010) Your own ThreadLocal
  10. (03 Dec 2010) Querying relative information with RavenDB
  11. (29 Jun 2010) Find the bug
  12. (23 Jun 2010) Dynamically dynamic
  13. (28 Apr 2010) What killed the application?
  14. (19 Mar 2010) What does this code do?
  15. (04 Mar 2010) Robust enumeration over external code
  16. (16 Feb 2010) Premature optimization, and all of that…
  17. (12 Feb 2010) Efficient querying
  18. (10 Feb 2010) Find the resource leak
  19. (21 Oct 2009) Can you spot the bug?
  20. (18 Oct 2009) Why is this wrong?
  21. (17 Oct 2009) Write the check in comment
  22. (15 Sep 2009) NH Prof Exporting Reports
  23. (02 Sep 2009) The lazy loaded inheritance many to one association OR/M conundrum
  24. (01 Sep 2009) Why isn’t select broken?
  25. (06 Aug 2009) Find the bug fixes
  26. (26 May 2009) Find the bug
  27. (14 May 2009) multi threaded test failure
  28. (11 May 2009) The regex that doesn’t match
  29. (24 Mar 2009) probability based selection
  30. (13 Mar 2009) C# Rewriting
  31. (18 Feb 2009) write a self extracting program
  32. (04 Sep 2008) Don't stop with the first DSL abstraction
  33. (02 Aug 2008) What is the problem?
  34. (28 Jul 2008) What does this code do?
  35. (26 Jul 2008) Find the bug fix
  36. (05 Jul 2008) Find the deadlock
  37. (03 Jul 2008) Find the bug
  38. (02 Jul 2008) What is wrong with this code
  39. (05 Jun 2008) why did the tests fail?
  40. (27 May 2008) Striving for better syntax
  41. (13 Apr 2008) calling generics without the generic type
  42. (12 Apr 2008) The directory tree
  43. (24 Mar 2008) Find the version
  44. (21 Jan 2008) Strongly typing weakly typed code
  45. (28 Jun 2007) Windsor Null Object Dependency Facility


Benny Thomas

This is fairly easy, it is in the nature of QueueUserWorkItem.

This code is not execute before the test is finished because the test is so short. Maybe the testrunner uses QueueUserWorkItem and there is not a free pool thread available before the test is finished.


Line 68 (Assert "hello-1") should read "hello-0" since that will pull a message before the pooled work item will. The test fails at that point, the queue is disposed, and the pooled item exception fires.

Ayende Rahien


No, we have synchronization there to prevent that.

Ayende Rahien



You got that, and quite fast


:) Cool. At the start of the post, you mention that it fails consistently on 'one' of your machines -- is it a single core machine? I'm guessing that on a single core, the main program flow has more of a chance to execute before the threadpool spins up (whereas on a multicore, the queued item might execute before the main method, which appears to be the expected result of the test).

Did you resolve the issue by adding a Sleep or another event (Set on line 56, WaitOne on line 65)?

Stefan Wenig

For someone who's used to cleaning up after himself, you're surprisingly laissez-faire about putting critical exit-code into finally-blocks ;-)

Ayende Rahien


I am not sure that I follow.

Stefan Wenig

To prevent that situation, wait.Set and wait.WaitOne could have gone into a finally block. But I was just refering to your kitchen joke about being a former C++ programmer, not making a point about thread-safe programming. So I'm not going to argue about how good a solution that would be - I firmly believe that concurrency is evil since I first read about the double-checked locking pattern, itanium chipsets and memory barriers. ;-)

Benny Thomas

Aaah, my bad! My skills improve all the time.

But the error show that your asserts should be the last thing to do in the test.

So you should have 2 variables to catch the Message.Data until the run was over and then test if the where correct!

Ayende Rahien


I tend not to care much for stuff like that in a test.

If I need reliability in a test, I have a bad test.

And +1 on concurrency

Stefan Wenig

I was just kidding about the finally-part, you would obviously be more concerned with making the code work reliably than fail beautifully. But it goes to show how good you need to understand concurrent test code to make sure you're actually testing what you think you're testing.

This seems to be an integration test, and those tend to be just spot tests (meaning we should not even attempt to cover every possible execution path by creating every possible permutation of circumstances - for coverage we have unit tests).

Introducing timing as one of those circumstances further reduces the evidence an integration test provides. If you want to remove timing as a random variable, you'd have to manually sync the code and have it execute using various permutations of relative timing/waiting. Argh!

If you feel like punishing yourself, you might even try to create a framework that does the permutations automatically for sync points you sprinkle over your code. But then again, you'd probably have to be catholic to do that ;-)

(Am I making any sense?)

Ayende Rahien

You make sense, but I do not enjoy pain, so I wouldn't do it


Should I draw the conclusion that catholics enjoy pain???

Stefan Wenig

You got that wrong: Catholism is not about enjoying pain, it's about deserving and enduring it.

Damned are those who strive for just happiness (from a Catholic standpoint as well as from a concurrency perspective)

Ayende Rahien

Thank goodness that I get to stand from the sidelines and wonder at all the things that exist in the world


Damned you. Come on, have some pain. Go back to C++!

Stefan Wenig


seems this is exactly what I was thinking about, thanks for the link!

not surprised that Peli de Halleux is on that team, that chess stuff does remind me of pex, which he presented at last year's lang.net. (on an unrelated note, he was the first person I watched rolling on shoes that can extend little wheels - how cool's that?)

now get this:

Before joining Microsoft, Peli earned a PhD in Applied Mathematics from the Catholic University of Louvain (2000-2004).

there must be something to my theory about Catholicism and concurrency ...

(and I discovered this just by accident, clicking on the name of the one team member I knew.)

Frank Quednau

+1 on the CHESS question. Since you do quite a bit with concurrently used code I was wondering whether you ever had a look at it.

Jeff Brown

The problem is that the Assert on "hello-1" fails which causes the test to fail before the queued user work item has had a chance to run so by the time it does run the queueManager has been disposed. The assumed order of execution is incorrect.

This is an example of why MbUnit v3 has a "Tasks" class to help with managing threads and processes in concurrent tests. It ensures the tasks get cleaned up properly when a test fails and that failures that occur within those tasks are all reported correctly. While that won't prevent test bugs like the above from occurring, it can make them a bit easier to diagnose.

John Smith

@stephan; @ayende

But I was just refering to your kitchen joke about being a former C++ programmer

You'll have to cite 3 examples before we believe Ayende was a C++ programmer.

Comment preview

Comments have been closed on this topic.


No future posts left, oh my!


  1. Technical observations from my wife (3):
    13 Nov 2015 - Production issues
  2. Production postmortem (13):
    13 Nov 2015 - The case of the “it is slow on that machine (only)”
  3. Speaking (5):
    09 Nov 2015 - Community talk in Kiev, Ukraine–What does it take to be a good developer
  4. Find the bug (5):
    11 Sep 2015 - The concurrent memory buster
  5. Buffer allocation strategies (3):
    09 Sep 2015 - Bad usage patterns
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats