AbortStopDisconnect scenario leaking events

[jcondex]

The AbortStopDisconnect scenario leaks event handles.

I have uploaded the dump file here: \indigofs\commonshare\jconde\SignalR\Bugs\1717

Here is the investigation that will help you fix this:

0:203> !handle

<CUT>
Handle 00000000000025e4
  Type          Event
<CUT>

0:203> !handle 00000000000025e4 ff

Handle 00000000000025e4
  Type          Event
  Attributes    0
  GrantedAccess 0x1f0003:
         Delete,ReadControl,WriteDac,WriteOwner,Synch
         QueryState,ModifyState
  HandleCount   2
  PointerCount  524288
  Name          <none>
  No object specific information available

0:203> !dumpheap -type Event -stat

Statistics:
              MT    Count    TotalSize Class Name
<CUT>
000007f7b9ab4e70    50455      2421840 System.Threading.ManualResetEvent
Total 50524 objects
Fragmented blocks larger than 0.5 MB:
            Addr     Size      Followed by
00000006d0bb5c10    0.7MB 00000006d0c5e8d0 System.Byte[]
00000006d12bf448    1.0MB 00000006d13bac70 System.Byte[]

0:203> !dumpheap -mt 000007f7b9ab4e70

         Address               MT     Size
<CUT>
00000006c7f754d0 000007f7b9ab4e70       48
<CUT>

0:203> !gcroot 00000006c7f754d0

Thread e30:
    00000006c089e660 000007f7b9cf59c4 Microsoft.Test.Stress.StressTest.WaitForTestToComplete()
        rbp+110: 00000006c089e790
            ->  00000006c2aebad8 Microsoft.Test.Stress.StressTest
            ->  00000006c2aefcf0 Microsoft.Test.Stress.TimeoutManager
            ->  00000006c2afe078 System.Threading.Timer
            ->  00000006c2afe188 System.Threading.TimerHolder
<CUT>
            ->  00000006c2b43828 System.Threading.TimerQueueTimer
            ->  00000006c7f6f9c8 System.Threading.TimerCallback
            ->  00000006c7f5f308 Microsoft.AspNet.SignalR.Client.HeartbeatMonitor
            ->  00000006c7f5e9d0 Microsoft.AspNet.SignalR.Client.Hubs.HubConnection
            ->  00000006c7f5f280 Microsoft.AspNet.SignalR.Client.Transports.LongPollingTransport
            ->  00000006c7f754d0 System.Threading.ManualResetEvent

[jcondex]

The ExceptionsThrownEverywhere test hit this using ServerSentEvents.

0:103> !gcroot 000000e69d607e38 
Thread 17d0:
*** WARNING: Unable to verify checksum for C:\eth\68b51de0-3e56-453b-8a9f-9bb851280b85\Microsoft.Test.Stress.dll
    000000e6968ae640 000007fb80616e34 Microsoft.Test.Stress.StressTest.WaitForTestToComplete() [c:\Stress\src\Microsoft.Test.Stress\StressTest.cs @ 918]
        rbp+110: 000000e6968ae770
            ->  000000e698bfbc00 Microsoft.Test.Stress.StressTest
            ->  000000e698bffe28 Microsoft.Test.Stress.TimeoutManager
            ->  000000e698c0fab0 System.Threading.Timer
            ->  000000e698c0fbc0 System.Threading.TimerHolder
<CUT>
            ->  000000e69d1453e0 System.Threading.TimerQueueTimer
            ->  000000e69d1457b0 System.Threading.TimerQueueTimer
            ->  000000e69d145750 System.Threading.TimerCallback
            ->  000000e69d1456e8 System.Threading.Tasks.TaskCompletionSource`1[[System.Object, mscorlib]]
            ->  000000e69d145700 System.Threading.Tasks.Task`1[[System.Object, mscorlib]]
            ->  000000e69d1458b0 System.Threading.Tasks.StandardTaskContinuation
            ->  000000e69d145860 System.Threading.Tasks.ContinuationTaskFromResultTask`1[[System.Object, mscorlib]]
            ->  000000e69d145a30 System.Threading.Tasks.StandardTaskContinuation
            ->  000000e69d1459e0 System.Threading.Tasks.ContinuationTaskFromTask
            ->  000000e69d1459a0 System.Action`1[[System.Threading.Tasks.Task, mscorlib]]
            ->  000000e69d145918 Microsoft.AspNet.SignalR.TaskAsyncHelper+<>c__DisplayClass2e
            ->  000000e69d1458d8 System.Action
            ->  000000e69d129d48 Microsoft.AspNet.SignalR.Client.Transports.ServerSentEventsTransport+<>c__DisplayClassf
            ->  000000e69d0f7c78 Microsoft.AspNet.SignalR.Client.Transports.ServerSentEventsTransport
            ->  000000e69d153a08 System.Threading.ManualResetEvent

[DamianEdwards]

Does this still happen?

[jcondex]

The last run did not fail due to leaking handles, but because of a memory leak. It's likely that the leak is related to the leaking handles.

[jcondex]

This issue reproduced again in yesterdays run.