Why int64 array is so big in TimerThread

54 Views Asked by At

I'm investigating OutOfMemoryException in 32bit process, the following stats has drawn my attention (large int64 array):

!dumpheap -stat
........
707b251c        3       692500 System.Int64[]
6fa6b038    72151      2020228 System.Diagnostics.ProcessModule
6fa9b1a0    72151      2308832 System.Diagnostics.ModuleInfo
707fdd04     2404      3223807 System.Byte[]
707faea4    11990      5780152 System.Object[]
707fb37c     9847     16162530 System.Char[]
00c16a88    41026     19281740      Free
707fac04   183726     21698276 System.String
Total 758006 objects
0:000> !DumpHeap /d -mt 707b251c
 Address       MT     Size
02f5b9ec 707b251c       76     
02f7c198 707b251c       60     
03f40000 707b251c   692364     

Statistics:
      MT    Count    TotalSize Class Name
707b251c        3       692500 System.Int64[]
Total 3 objects
0:000> !gcroot 03f40000
Thread 4320:
*** WARNING: Unable to verify checksum for System.ni.dll
    1238ea6c 6fbedbd0 System.Net.TimerThread.ThreadProc() [f:\dd\NDP\fx\src\net\System\Net\_TimerThread.cs @ 707]
        edi:  (interior)
            ->  03dc3670 System.Object[]
            ->  03f40000 System.Int64[]

Found 1 unique roots (run '!GCRoot -all' to see all roots).

.Net Framework 4.8 is used. Why TimerThread needs such big array?

The dump was made out of "simplified" of app, the initial version has more drastic figures (with more threads(229 vs 32), with app domains(~180 vs 0) loading):

!dumpheap -stat
..........
707b251c      387    105384412 System.Int64[]
1

There are 1 best solutions below

2
user3791838 On

Finally found it, not sure whether TimeThread callstack that is shown by WinDbg is reflecting the reality, but the simplest way to reproduce it is to run such Console App with main method:

var procs = System.Diagnostics.Process.GetProcessesByName("GetProcessesByName");
     Console.ReadKey();

And later get the dump, which shows in my case

!dumpheap -stat
....
6fa595d0     7361       264996 System.Diagnostics.ThreadInfo
6fa595a4     7361       529992 
System.Diagnostics.NtProcessInfoHelper+SystemThreadInformation
7061251c        2      1003800 System.Int64[]
Total 19595 objects

So it seems that strange behavior is related to Process.GetProcessesByName. However Process.GetCurrentProcess() doesn't produce any int64[] footprint in memory.