Many Identical Threads found in dump of Visual Studio

[calvinhsia]

Hi
I was examining a dump of Visual Studio from a customer who was running out of memory
In the dump under WinDbg, there are 13 identical stacks
This looks suspiciously inefficient:

1cf00000 1d03a000   System_Reactive   (no symbols)           
    Loaded symbol image file: System.Reactive.dll
    Image path: C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\Common7\IDE\Extensions\Xamarin.VisualStudio\System.Reactive.dll
    Image name: System.Reactive.dll
    Browse all global symbols  functions  data
    Using CLR debugging support for all symbols
    Has CLR image header, track-debug-data flag not set
    Image was built with /Brepro flag.
    Timestamp:        87C43E2F (This is a reproducible build file hash, not a timestamp)
    CheckSum:         00140CEB
    ImageSize:        0013A000
    File version:     4.3.2.55399
    Product version:  4.3.2.0
    File flags:       0 (Mask 3F)
    File OS:          4 Unknown Win32
    File type:        2.0 Dll
    File date:        00000000.00000000
    Translations:     0000.04b0
    Information from resource tables:
        CompanyName:      .NET Foundation and Contributors
        ProductName:      System.Reactive (net46)
        InternalName:     System.Reactive.dll
        OriginalFilename: System.Reactive.dll
        ProductVersion:   4.3.2+67d891dfbf
        FileVersion:      4.3.2.55399
        FileDescription:  System.Reactive
        LegalCopyright:   Copyright (c) .NET Foundation and Contributors.
        Comments:         Reactive Extensions (Rx) for .NET
00 ntdll!NtWaitForMultipleObjects
01 KERNELBASE!WaitForMultipleObjectsEx
02 clr!WaitForMultipleObjectsEx_SO_TOLERANT
03 clr!Thread::DoAppropriateAptStateWait
04 clr!Thread::DoAppropriateWaitWorker
05 clr!Thread::DoAppropriateWait
06 clr!SOIntolerantTransitionHandler::SetNoException
07 clr!CLREventBase::WaitEx
08 clr!CLREventBase::Wait
09 clr!Thread::Wait
0a clr!Thread::Block
0b clr!SyncBlock::Wait
0c clr!ObjHeader::Wait
0d clr!Object::Wait
0e clr!ObjectNative::WaitTimeout
0f mscorlib_ni!System.Threading.Monitor.Wait(System.Object, Int32, Boolean)
10 System_Reactive!System.Reactive.ObserveOnObserverLongRunning`1[[System.__Canon, mscorlib]].Drain()
11 System_Reactive!System.Reactive.ObserveOnObserverLongRunning`1+<>c[[System.__Canon, mscorlib]].<.cctor>b__17_0(System.Reactive.ObserveOnObserverLongRunning`1<System.__Canon>, System.Reactive.Disposables.ICancelable)
12 System_Reactive!System.Reactive.Concurrency.NewThreadScheduler+<>c__DisplayClass7_0`1[[System.__Canon, mscorlib]].<ScheduleLongRunning>b__0()
13 mscorlib_ni!System.Threading.ThreadHelper.ThreadStart_Context(System.Object)
14 mscorlib_ni!System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
15 mscorlib_ni!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
16 mscorlib_ni!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
17 mscorlib_ni!System.Threading.ThreadHelper.ThreadStart()
18 clr!CallDescrWorkerInternal
19 clr!CallDescrWorkerWithHandler
1a clr!MethodDescCallSite::CallTargetWorker
1b clr!MethodDescCallSite::Call
1c clr!ThreadNative::KickOffThread_Worker
1d clr!ManagedThreadBase_DispatchInner
1e clr!ManagedThreadBase_DispatchMiddle::__l16::Cleanup::{dtor}
1f clr!ManagedThreadBase_DispatchMiddle
20 clr!ManagedThreadBase_DispatchOuter
21 clr!ManagedThreadBase_FullTransitionWithAD
22 clr!ThreadNative::KickOffThread
23 clr!Thread::intermediateThreadProc
24 kernel32!BaseThreadInitThunk
25 ntdll!__RtlUserThreadStart
26 ntdll!_RtlUserThreadStart

[bartdesmet]

If the code using Rx (Xamarin.VisualStudio?) is using NewThreadScheduler (see frame 12), this behavior is to be expected. Question is if they can use another scheduler in this particular case. Either way, it's not an Rx bug. The code asks for a new thread and gets a new thread.

[bartdesmet]

Closing as by design but linking #266 where we track potential improvements to diagnostics.