locked
Child thread raised exception : Safe handle has been closed RRS feed

  • Question

  • Any ideas what's going on here? I've chopped out great swathes of my code to try and get this test to run, but now I'm just getting this:

    ***************** CHESS assertion ***********************
    Child thread raised exception
    Safe handle has been closed
    Stack trace:
       at __Substitutions.System.Threading.WaitHandleHelper.WaitGeneralRaw(ClrSyncMa
    nager manager, WaitHandle[] waitHandles, Int32 millisecondsTimeout, Boolean exit
    Context, String op)
       at __Substitutions.System.Threading.WaitHandleHelper.<>c__DisplayClass2.<Wait
    General>b__0(ClrSyncManager manager)
       at Microsoft.ManagedChess.EREngine.Helper.SimpleWrap[T](SimpleDelmanager`1 fo
    o, SimpleDel`1 bar)
       at __Substitutions.System.Threading.WaitHandleHelper.WaitGeneral(WaitHandle[]
     waitHandles, Int32 millisecondsTimeout, Boolean exitContext, String op)
       at __Substitutions.System.Threading.WaitHandle.WaitOne(WaitHandle h, Int32 mi
    llisecondsTimeout, Boolean exitContext)
       at Microsoft.ManagedChess.EREngine.RegisterWaitHelper.<>c__DisplayClass1.<Reg
    isterWaitForSingleObjectWrapper>b__0(Object argument, Boolean timedOut)

    Tests: 1941 Threads: 5 ExecSteps: 72 Time: 39.781

    Tuesday, March 30, 2010 3:35 PM

Answers

  • Running a (slightly modified) test in mchess, with the correct /includeassemblies I am unable to replicate this, so whether the code has changed or it was an artefact of the integrated test host I'm unsure.

    What's the equivilent of /includeassemblies in the integrated host. Not that I'm using that any more, but if it needs one, and I wasn't supplying it, that would certainally lead to issues (the AsyncResult impl is not in the same assembly as the test).

    Thursday, April 15, 2010 12:56 AM

All replies

  • I think I may know why this is happening.

    We have our own implementations of IAsyncResult for certain async activities. These spin up an AsyncWaitHandle, but when the async operation is completed (the EndXXX method is called) these wait handles are freed (by calling their Close() method) to avoid resource leakage.

    We also implement a timeout pattern based on the waithandle and ThreadPool.WaitForSingleObject. If the async operation completes prior to the timeout elapsing, the timeout is cancelled (RegisteredWaitHandle.Unregister(waithandle)) and will never fire.

    If I remove the call to waithandle.Close() the waithandle the test runs to completion, which makes me think Chess is intercepting the ThreadPool.WaitForSingleObject call and setting up it's own callback. However it appears to do this asyncronously (see stack trace above). Either way, there is a race because Chess is operating with my waithandle outside of the lock that I normally operate within, and so another thread can close the waithandle prior to Chess ever setting up the WaitForSingleObject replacement.

    I think.

    Why is the WaitForSingleObject interception being done async (if indeed it is)?

    Wednesday, March 31, 2010 4:49 AM
  • > Either way, there is a race because Chess is operating with my waithandle outside of the lock that I normally operate within,

    > and so another thread can close the waithandle prior to Chess ever setting up the WaitForSingleObject replacement.

    Hmm. This shouldn't be the case, but I will investigate. Another possibility has to do with CHESS's handling of IAsyncResult. Is it possible you can share a small code example that illustrats the problem?

    -- Tom

    Saturday, April 10, 2010 5:35 PM
  • Running a (slightly modified) test in mchess, with the correct /includeassemblies I am unable to replicate this, so whether the code has changed or it was an artefact of the integrated test host I'm unsure.

    What's the equivilent of /includeassemblies in the integrated host. Not that I'm using that any more, but if it needs one, and I wasn't supplying it, that would certainally lead to issues (the AsyncResult impl is not in the same assembly as the test).

    Thursday, April 15, 2010 12:56 AM
  • Thanks for trying mchess. I am glad (and not terribly surprised) that this changed things... we didn't have the chance to test the integrated test host very much.

    -- Tom

    Thursday, April 15, 2010 6:01 AM