AppDomain.MonitoringSurvivedMemorySize incorrect in .NET 5.0 #45446

timcassell · 2020-12-01T23:30:18Z

While trying to add a new feature to BDN to measure survived memory (dotnet/BenchmarkDotNet#1596), I found that .NET Core 3.1 and .NET 5.0 were reporting unexpected values. I made a separate application to test whether the measurements I'm making are even accurate separate from all other BDN code. I found that it seems to be accurate in .NET Core 3.1, but it's off in .NET 5.0.

Console prints:

Survived bytes: 0
Survived bytes: 24
Survived bytes: 24

With this code:

using System;
using System.Runtime.CompilerServices;

namespace MemoryTest
{
    class Program
    {
        static int n;

        static void Main(string[] args)
        {
            n = 1_000_000;
            Measure(); // Run once for GC monitor to make its allocations.
            Console.WriteLine($"Survived bytes: {Measure()}");
            Console.WriteLine($"Survived bytes: {Measure()}");
            Console.WriteLine($"Survived bytes: {Measure()}");
        }

        static long Measure()
        {
            long beforeBytes = GetTotalBytes();
            NonAllocatingMethod();
            long afterBytes = GetTotalBytes();
            return afterBytes - beforeBytes;
        }


        [MethodImpl(MethodImplOptions.NoInlining)]
        static void NonAllocatingMethod()
        {
            for (int i = 0; i < n; i++) { }
        }

        static long GetTotalBytes()
        {
            AppDomain.MonitoringIsEnabled = true;

            // Enforce GC.Collect here to make sure we get accurate results.
            GC.Collect();
            GC.WaitForPendingFinalizers();
            GC.Collect();
            return AppDomain.CurrentDomain.MonitoringSurvivedMemorySize;
        }
    }
}

[Edit] This was ran with Visual Studio 16.8.2 on Windows 7 SP1 on AMD Phenom II x6.

Also, the results above were from running in DEBUG mode directly in Visual Studio. After building in RELEASE configuration and running it separately, I got these results (different, but still wrong):

Survived bytes: 0
Survived bytes: 24
Survived bytes: 0

The text was updated successfully, but these errors were encountered:

Dotnet-GitSync-Bot · 2020-12-01T23:30:21Z

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

ghost · 2020-12-01T23:58:29Z

Tagging subscribers to this area: @dotnet/gc
See info in area-owners.md if you want to be subscribed.

Issue Details

While trying to add a new feature to BDN to measure survived memory (dotnet/BenchmarkDotNet#1596), I found that .NET Core 3.1 and .NET 5.0 were reporting unexpected values. I made a separate application to test whether the measurements I'm making are even accurate separate from all other BDN code. I found that it seems to be accurate in .NET Core 3.1, but it's off in .NET 5.0.

Console prints:

Survived bytes: 0
Survived bytes: 24
Survived bytes: 24

With this code:

using System;
using System.Runtime.CompilerServices;

namespace MemoryTest
{
    class Program
    {
        static int n;

        static void Main(string[] args)
        {
            n = 1_000_000;
            Measure(); // Run once for GC monitor to make its allocations.
            Console.WriteLine($"Survived bytes: {Measure()}");
            Console.WriteLine($"Survived bytes: {Measure()}");
            Console.WriteLine($"Survived bytes: {Measure()}");
        }

        static long Measure()
        {
            long beforeBytes = GetTotalBytes();
            NonAllocatingMethod();
            long afterBytes = GetTotalBytes();
            return afterBytes - beforeBytes;
        }


        [MethodImpl(MethodImplOptions.NoInlining)]
        static void NonAllocatingMethod()
        {
            for (int i = 0; i < n; i++) { }
        }

        static long GetTotalBytes()
        {
            AppDomain.MonitoringIsEnabled = true;

            // Enforce GC.Collect here to make sure we get accurate results.
            GC.Collect();
            GC.WaitForPendingFinalizers();
            GC.Collect();
            return AppDomain.CurrentDomain.MonitoringSurvivedMemorySize;
        }
    }
}

[Edit] This was ran with Visual Studio 16.8.2 on Windows 7 SP1 on AMD Phenom II x6.

Also, the results above were from running in DEBUG mode directly in Visual Studio. After building in RELEASE configuration and running it separately, I got these results (different, but still wrong):

Survived bytes: 0
Survived bytes: 24
Survived bytes: 0

Author:	timcassell
Assignees:	-
Labels:	`area-GC-coreclr`, `untriaged`
Milestone:	-

timcassell · 2020-12-02T07:03:19Z

I actually tried running that test again, and kept getting different results. So I rewrote the code to do many iterations to try to find any anomalies, and I ran it in different runtimes.
.NET 5.0 finds lots of anomalies sometimes (300+), sometimes only a few (4 or 5).
.NET Core 3.1 finds a few anomalies (3 or 4).
.NET Framework 4.7.2 finds no anomalies.

using System;
using System.Collections.Generic;
using System.Runtime.CompilerServices;

namespace MemoryTest
{
    class Program
    {
        static void Main(string[] args)
        {
            Measure(); // Run once for GC monitor to make its allocations.

            int abnormalCount = 0;

            const int iterations = 10_000;
            Console.WriteLine($"Searching for abnormal survived memory...");
            for (int i = 0; i < iterations; ++i)
            {
                long bytes = Measure();
                if (bytes != 0)
                {
                    ++abnormalCount;
                    Console.WriteLine($"Iteration {i}, survived bytes: {bytes}");
                }
            }

            Console.WriteLine($"Abnormal survived memory found in {abnormalCount} out of {iterations} iterations.");
        }

        static long Measure()
        {
            long beforeBytes = GetTotalBytes();
            NonAllocatingMethod();
            long afterBytes = GetTotalBytes();
            return afterBytes - beforeBytes;
        }


        [MethodImpl(MethodImplOptions.NoInlining)]
        static void NonAllocatingMethod() { }

        static long GetTotalBytes()
        {
            AppDomain.MonitoringIsEnabled = true;

            // Enforce GC.Collect here to make sure we get accurate results.
            GC.Collect();
            GC.WaitForPendingFinalizers();
            GC.Collect();
            return AppDomain.CurrentDomain.MonitoringSurvivedMemorySize;
        }
    }
}

timcassell · 2020-12-03T08:34:23Z

Interestingly, I found similar issues with regards to measuring allocations in both Core 3.1 and 5.0. See dotnet/BenchmarkDotNet#1543
I am unsure if the issue with allocations and total memory are related. @adamsitnik mentioned in that other issue that he tracked that issue down to the jitter running in a separate thread. It seems to be completely random when it occurs (for both measurements).

Searching for abnormal allocated memory...
Iteration 730, allocated bytes: 40
Iteration 1503, allocated bytes: 40
Abnormal allocated memory found in 2 out of 10000 iterations.

using System;
using System.Runtime.CompilerServices;

namespace MemoryTest
{
    class Program
    {
        static void Main(string[] args)
        {
            Measure(); // Run once for GC monitor to make its allocations.

            int abnormalCount = 0;

            const int iterations = 10_000;
            Console.WriteLine($"Searching for abnormal allocated memory...");
            for (int i = 0; i < iterations; ++i)
            {
                long bytes = Measure();
                if (bytes != 0)
                {
                    ++abnormalCount;
                    Console.WriteLine($"Iteration {i}, survived bytes: {bytes}");
                }
            }

            Console.WriteLine($"Abnormal allocated memory found in {abnormalCount} out of {iterations} iterations.");
            Console.ReadKey();
        }

        static long Measure()
        {
            long beforeBytes = GetAllocatedBytes();
            NonAllocatingMethod();
            long afterBytes = GetAllocatedBytes();
            return afterBytes - beforeBytes;
        }


        [MethodImpl(MethodImplOptions.NoInlining)]
        static void NonAllocatingMethod() { }

        static long GetAllocatedBytes()
        {
            AppDomain.MonitoringIsEnabled = true;

            // Enforce GC.Collect here to make sure we get accurate results.
            GC.Collect();
            GC.WaitForPendingFinalizers();
            GC.Collect();
            return AppDomain.CurrentDomain.MonitoringTotalAllocatedMemorySize;
        }
    }
}

ivdiazsa · 2021-07-24T02:34:37Z

Closing since by .NET 6.0 Preview 6, this issue doesn't reproduce anymore.

timcassell · 2021-07-24T08:03:11Z

@ivdiazsa I just tried this code again running on 6.0.100-preview.6.21355.2, and I'm still getting unexpected results:

Searching for abnormal survived memory...
Iteration 231, survived bytes: 40
Iteration 232, survived bytes: 80
Iteration 527, survived bytes: 40
Iteration 529, survived bytes: 40
Iteration 530, survived bytes: 40
Abnormal survived memory found in 5 out of 10000 iterations.

[Edit] It looks like the allocated memory was fixed, but the survived memory is still broken.

timcassell · 2021-08-12T22:55:26Z

@ivdiazsa I'm still seeing this in 6.0.100-preview.7.21379.14, please re-open this issue until it is resolved.

ivdiazsa · 2021-08-12T23:31:01Z

It would help if you provided more specifications from your current environment. It does not reproduce on our side anymore.

timcassell · 2021-08-13T00:14:00Z

Visual Studio: 16.11.0
OS: Windows 7 SP1, 64-bit
CPU: AMD Phenom II x6 1055T @ 2.8GHz
RAM: 8GB DDR3 @ 1333

Any other info you need?

mangod9 · 2021-09-15T15:41:02Z

Moving to .net 7, since this appears to be on win7 only? @timcassell are you able to repro this on win10?

timcassell · 2021-09-15T16:08:17Z

Hi @mangod9, yes I am repro'ing on win10.

.Net 6.0.100-rc.1.21458.32
Visual Studio: 16.11.3
CPU: AMD Ryzen 7 3700X 8-Core Processor 3.59 GHz
RAM: 32GB

Also for clarity, I am running the code in this comment for measuring survived memory (not allocated).

I also tried with Visual Studio 2022 (17.0.0 Preview 4.0), and saw even more unexpected survived measurements, some even negative (though the negatives haven't shown when running standalone exe, only when run in VS)!

Searching for abnormal survived memory...
Iteration 2, survived bytes: 8
Iteration 4, survived bytes: -24
Iteration 7, survived bytes: 40
Iteration 9, survived bytes: 488
Iteration 10, survived bytes: 56
Iteration 11, survived bytes: 120
Iteration 12, survived bytes: 80
Iteration 14, survived bytes: 48
Iteration 15, survived bytes: 152
Iteration 18, survived bytes: 96
Iteration 19, survived bytes: 232
Iteration 22, survived bytes: 240
Iteration 23, survived bytes: -48
Iteration 24, survived bytes: -64
Iteration 25, survived bytes: 128
Iteration 26, survived bytes: 8
Iteration 28, survived bytes: 48
Iteration 29, survived bytes: 32
Iteration 30, survived bytes: 232
Iteration 31, survived bytes: 168
Iteration 35, survived bytes: 7664
Iteration 40, survived bytes: 40
Iteration 42, survived bytes: 392
Iteration 45, survived bytes: 168
Iteration 52, survived bytes: 104
Iteration 54, survived bytes: -184
Iteration 55, survived bytes: 72
Iteration 57, survived bytes: 72
Iteration 59, survived bytes: 96
Iteration 61, survived bytes: 240
Iteration 63, survived bytes: 112
Iteration 65, survived bytes: 112
Iteration 66, survived bytes: 112
Iteration 69, survived bytes: 240
Iteration 70, survived bytes: -16
Iteration 71, survived bytes: 32
Iteration 73, survived bytes: 32
Iteration 75, survived bytes: 96
Iteration 76, survived bytes: 24
Iteration 78, survived bytes: 8
Iteration 82, survived bytes: 56
Iteration 84, survived bytes: 40
Iteration 85, survived bytes: 40
Iteration 86, survived bytes: 264
Iteration 87, survived bytes: 48
Iteration 89, survived bytes: 488
Iteration 91, survived bytes: -80
Iteration 92, survived bytes: 32
Iteration 93, survived bytes: -32
Iteration 94, survived bytes: 32
Iteration 99, survived bytes: 136
Iteration 101, survived bytes: 320
Iteration 104, survived bytes: 88
Iteration 344, survived bytes: 48
Iteration 346, survived bytes: 40
Iteration 347, survived bytes: 40
Iteration 351, survived bytes: 1120
Iteration 353, survived bytes: 48
Iteration 366, survived bytes: 8
Iteration 367, survived bytes: 40
Iteration 370, survived bytes: 40
Iteration 551, survived bytes: 8
Iteration 552, survived bytes: 8
Iteration 555, survived bytes: 80
Iteration 558, survived bytes: 48
Abnormal survived memory found in 65 out of 10000 iterations.

Maoni0 · 2021-09-15T22:23:37Z

I've been running this for 15 mins and could not repro at all.

@cshung could you please see if you can repro this? I used the test from @timcassell's latest iteration. the test is very straightforward so it's puzzling why the results can be so volatile.

Maoni0 · 2021-09-15T22:26:05Z

I should mention that I ran this with corerun, not in VS. running in VS may not make it so straightforward...

timcassell · 2021-09-15T22:41:44Z

I tried build from command line dotnet build ConsoleApp1.sln -c Release and run the exe, and I consistently get results like this (though iteration numbers and abnormality count differ each run):

Searching for abnormal survived memory...
Iteration 3135, survived bytes: 40
Iteration 3136, survived bytes: 40
Iteration 5879, survived bytes: 40
Iteration 5884, survived bytes: 40
Iteration 5889, survived bytes: 40
Iteration 5895, survived bytes: 328
Iteration 5903, survived bytes: 8
Iteration 5905, survived bytes: 80
Iteration 5906, survived bytes: 40
Iteration 5920, survived bytes: 40
Iteration 7284, survived bytes: 8
Iteration 7289, survived bytes: 8
Iteration 7290, survived bytes: 48
Iteration 7293, survived bytes: 8
Iteration 7299, survived bytes: 40
Iteration 7302, survived bytes: 8
Abnormal survived memory found in 16 out of 10000 iterations.

Maoni0 · 2021-09-16T01:42:16Z

okie...I'm not sure if @cshung got a chance to look at this. I just took a brief look. I can repro this (I only ever see the 40 bytes difference but the way to debug this would be the same). what I did was I just turned on the gc internal logging (dprintf's) that logged the current SOH and UOH allocated bytes in GCHeap::GetTotalAllocatedBytes -

dprintf (5555, ("%Id:%Id", pGenGCHeap->total_alloc_bytes_soh, pGenGCHeap->total_alloc_bytes_uoh));

then I have the test break into the debugger when it ever detects a difference between before and after. so when it broke I saw that there's a 40 byte difference in SOH alloc bytes so I looked at the last object that got allocated at the end of the ephemeral seg and found the root of it -

0:000> !eeheap -gc
Number of GC Heaps: 1
generation 0 starts at 0x0000021D149BEC30
generation 1 starts at 0x0000021D149BEBD8
generation 2 starts at 0x0000021D149B1000
ephemeral segment allocation context: none
         segment             begin         allocated         committed    allocated size    committed size
0000021D149B0000  0000021D149B1000  0000021D149C1FE8  0000021D149C2000  0x10fe8(69608)  0x11000(69632)
Large object heap starts at 0x0000021D249B1000
         segment             begin         allocated         committed    allocated size    committed size
0000021D249B0000  0000021D249B1000  0000021D249B1018  0000021D249B2000  0x18(24)  0x1000(4096)
Pinned object heap starts at 0x0000021D2C9B1000
0000021D2C9B0000  0000021D2C9B1000  0000021D2C9B5420  0000021D2C9C2000  0x4420(17440)  0x11000(69632)
Total Allocated Size:              Size: 0x15420 (87072) bytes.
Total Committed Size:              Size: 0x12000 (73728) bytes.
------------------------------
GC Allocated Heap Size:    Size: 0x15420 (87072) bytes.
GC Committed Heap Size:    Size: 0x12000 (73728) bytes.
0:000> !lno 0000021D149C1FE0
Before:  0000021d149c0cc0           40 (0x28)	System.SByte[]
After:  couldn't find any object between 0000021D149C1FE0 and 0000021D149C1FE8
Heap local consistency not confirmed.
0:000> !gcroot 0000021d149c0cc0 
HandleTable:
    0000021D12CB13D0 (strong handle)
    -> 0000021D149B10C8 System.Runtime.CompilerServices.GCHeapHash
    -> 0000021D149BACB0 System.Object[]
    -> 0000021D149C0CC0 System.SByte[]

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

this looks like something that gets allocated by the loader allocator stuff.

Maoni0 · 2021-09-16T01:48:02Z

(of course you don't need to use dprintf... could just look at the last object(s) allocated)

cshung · 2021-09-17T02:24:50Z

By implementing a ICorProfiler implementation and subscribe to the ICorProfilerCallback::ObjectAllocated event, I am able to confirm that many allocations did happen after printing Searching for abnormal allocated memory... and before the process ends.

First, note that the implementation of AppDomain.MonitoringSurvivedMemorySize itself allocates, so we are making at least 10k allocations in that loop. Sometimes it could be a tiered compilation kicking in. I also observe sometimes a gen2 callback performs some allocations.

There are just so many stacks that I have a hard time believing these are all the cases, I need to come up with a way to summarize these stacks.

Suffice to say that we did allocate, and therefore we observe the survived bytes changes.

Maoni0 · 2022-07-08T00:06:00Z

I'm closing this as we established that there was survived bytes. please let me know if you disagree.

timcassell · 2022-07-08T06:38:18Z

@Maoni0 Huh? Of course I disagree. The API is useless if I can't rely on it to tell me the accurate survived bytes of user code, and even more so if it potentially changes every time it's called when nothing else has changed in user code. The contract is broken.

cshung · 2022-07-09T22:40:48Z

I am writing this to do these three things:

(1) Correct my previous mistake
(2) Summarize the allocation and survival patterns within the second repro running on both .NET 6 and 7, and
(3) Conclude that we are fine

(1) Earlier, when I said this

Suffice to say that we did allocate, and therefore we observe the survived bytes changes.

This is not entirely accurate, allocations does not necessarily mean survival. I need to make sure the allocation did survive before I conclude earlier.

(2) Between the time we printed "Searching for abnormal survived memory..." and "Abnormal survived memory found in {abnormalCount} out of {iterations} iterations.", we did a lot of allocations.

Here is a call stack for the important allocations that does survive only on .NET 6 or below:

coreclr!AllocateSzArray+0x304  
coreclr!AllocatePrimitiveArray+0x36a  
coreclr!NoRemoveDefaultCrossLoaderAllocatorHashTraits<MethodDesc *,MethodDesc *>::AddToValuesInHeapMemory+0x147  
coreclr!CrossLoaderAllocatorHash<InliningInfoTrackerHashTraits>::Add+0x221  
coreclr!JITInlineTrackingMap::AddInliningDontTakeLock+0x5e8  
coreclr!JITInlineTrackingMap::AddInlining+0x9ec  
coreclr!Module::AddInlining+0xa09  
coreclr!CEEInfo::reportInliningDecision+0x115c  
clrjit!InlineResult::Report+0x89  
clrjit!InlineResult::{dtor}+0xa  
clrjit!Compiler::fgInline+0x2cf  
clrjit!Phase::Run+0x1e  
clrjit!DoPhase+0x50  
clrjit!Compiler::compCompile+0x3d8  
clrjit!Compiler::compCompileHelper+0x291  
clrjit!Compiler::compCompile+0x24a  
clrjit!jitNativeCode+0x262  
clrjit!CILJit::compileMethod+0x83  
coreclr!invokeCompileMethodHelper+0x86  
coreclr!invokeCompileMethod+0xc5  
coreclr!UnsafeJitFunction+0x7f1  
coreclr!MethodDesc::JitCompileCodeLocked+0x1f1  
coreclr!MethodDesc::JitCompileCodeLockedEventWrapper+0x466  
coreclr!MethodDesc::JitCompileCode+0x2a9  
coreclr!MethodDesc::PrepareILBasedCode+0x66  
coreclr!MethodDesc::PrepareCode+0x10  
coreclr!TieredCompilationManager::CompileCodeVersion+0xce  
coreclr!TieredCompilationManager::OptimizeMethod+0x22  
coreclr!TieredCompilationManager::DoBackgroundWork+0x125  
coreclr!TieredCompilationManager::BackgroundWorkerStart+0xc8  
coreclr!TieredCompilationManager::BackgroundWorkerBootstrapper1+0x5c  
coreclr!ManagedThreadBase_DispatchInner+0xd  
coreclr!ManagedThreadBase_DispatchMiddle+0x85  
coreclr!ManagedThreadBase_DispatchOuter+0xae  
coreclr!ManagedThreadBase_FullTransition+0x24  
coreclr!ManagedThreadBase::KickOff+0x24  
coreclr!TieredCompilationManager::BackgroundWorkerBootstrapper0+0x3a  
KERNEL32!BaseThreadInitThunk+0x10  
ntdll!RtlUserThreadStart+0x2b

I understand the stack is cryptic, so here is a hopefully simple explanation of what is going on. At the bottom of the stack, TieredCompilationManager is working on a thread trying to optimize some methods. When the compilation happens, the JIT decided that it is a good idea to perform some inlining. In order for the profiler to be able to rewrite the IL for a particular method, it needs to know that the IL for a certain method is embedded in the compilation of some other methods so that it can invalidate the compiled code. As an implementation detail, that data is recorded as some objects on the GC heap - thus you see the allocation and survival.

In .NET 7, #67160 changed the JIT inlining tracking map so that the tracking data is no longer allocated on the GC heap, so this allocation on the GC heap is not happening anymore.

There are some other unimportant allocations too, see (*) at the end of the message for reference.

(3)

The contract of the method AppDomain.MonitoringSurvivedMemorySize has always been this according to the documentation.

Gets the number of bytes that survived the last collection and that are known to be referenced by the current application domain.

It says nothing about whether or not the bytes are allocated by the user code or not. So there isn't a contract violation per se.

That being said, I understand it can be inconvenient for benchmark.net to consume this API. Fortunately, the survival is gone in .NET 7. So I would recommend using this API for .NET 7+. @timcassell, if you observe the value still changes after #67160, feel free to let us know and we will deal with that on a case-by-case basis depending on what else is allocated on the GC heap.

(*)

For the record, here are some unimportant allocations that does not survive.

MonitoringSurvivedMemorySize is calling MonitoringSurvivedProcessMemorySize is calling
GetGCMemoryInfo, in which we need to allocate the object for output.

Printing out the interpolated string leads to some allocation due to DefaultInterpolatedStringHandler and its use for ArrayPool.

When we perform a GC.Collect, the ArrayPool wants to trim itself on the finalizer thread and iterates over a ConditionalWeakTable. The iteration requires the construction of an Enumerator which is also an allocation.

Since none of these survives, so they are fine and does not contribute to the abnormalCount value. It is included here just so we know we need to ignore them if we ever want to reproduce the debugging.

timcassell · 2022-07-10T00:02:00Z

@cshung Thank you for the detailed information. I have tested again on the latest .Net 7 preview and can confirm I no longer see abnormal survived bytes.

Dotnet-GitSync-Bot added the untriaged New issue has not been triaged by the area owner label Dec 1, 2020

timcassell mentioned this issue Dec 1, 2020

Survived Memory dotnet/BenchmarkDotNet#1596

Open

jkotas added the area-GC-coreclr label Dec 1, 2020

mangod9 removed the untriaged New issue has not been triaged by the area owner label Dec 2, 2020

mangod9 added this to the 6.0.0 milestone Dec 2, 2020

mangod9 assigned ivdiazsa Dec 2, 2020

This was referenced Dec 2, 2020

Unexpected allocations reported in CPU-bound code dotnet/BenchmarkDotNet#1542

Open

Memory diagnoser fix for Tiered Compilation dotnet/BenchmarkDotNet#1543

Closed

timcassell mentioned this issue Dec 6, 2020

[MemoryDiagnoser] inaccurate and influenced by [GlobalSetup] work dotnet/BenchmarkDotNet#1599

Closed

ivdiazsa closed this as completed Jul 24, 2021

ivdiazsa removed their assignment Aug 12, 2021

ivdiazsa reopened this Aug 12, 2021

ivdiazsa self-assigned this Aug 12, 2021

mangod9 modified the milestones: 6.0.0, 7.0.0 Sep 15, 2021

Maoni0 closed this as completed Jul 8, 2022

ghost locked as resolved and limited conversation to collaborators Aug 9, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

AppDomain.MonitoringSurvivedMemorySize incorrect in .NET 5.0 #45446

AppDomain.MonitoringSurvivedMemorySize incorrect in .NET 5.0 #45446

timcassell commented Dec 1, 2020 •

edited

Loading

Dotnet-GitSync-Bot commented Dec 1, 2020

ghost commented Dec 1, 2020

timcassell commented Dec 2, 2020 •

edited

Loading

timcassell commented Dec 3, 2020 •

edited

Loading

ivdiazsa commented Jul 24, 2021

timcassell commented Jul 24, 2021 •

edited

Loading

timcassell commented Aug 12, 2021

ivdiazsa commented Aug 12, 2021

timcassell commented Aug 13, 2021 •

edited

Loading

mangod9 commented Sep 15, 2021

timcassell commented Sep 15, 2021 •

edited

Loading

Maoni0 commented Sep 15, 2021

Maoni0 commented Sep 15, 2021

timcassell commented Sep 15, 2021 •

edited

Loading

Maoni0 commented Sep 16, 2021

Maoni0 commented Sep 16, 2021

cshung commented Sep 17, 2021 •

edited

Loading

Maoni0 commented Jul 8, 2022

timcassell commented Jul 8, 2022 •

edited

Loading

cshung commented Jul 9, 2022

timcassell commented Jul 10, 2022

AppDomain.MonitoringSurvivedMemorySize incorrect in .NET 5.0 #45446

AppDomain.MonitoringSurvivedMemorySize incorrect in .NET 5.0 #45446

Comments

timcassell commented Dec 1, 2020 • edited Loading

Dotnet-GitSync-Bot commented Dec 1, 2020

ghost commented Dec 1, 2020

timcassell commented Dec 2, 2020 • edited Loading

timcassell commented Dec 3, 2020 • edited Loading

ivdiazsa commented Jul 24, 2021

timcassell commented Jul 24, 2021 • edited Loading

timcassell commented Aug 12, 2021

ivdiazsa commented Aug 12, 2021

timcassell commented Aug 13, 2021 • edited Loading

mangod9 commented Sep 15, 2021

timcassell commented Sep 15, 2021 • edited Loading

Maoni0 commented Sep 15, 2021

Maoni0 commented Sep 15, 2021

timcassell commented Sep 15, 2021 • edited Loading

Maoni0 commented Sep 16, 2021

Maoni0 commented Sep 16, 2021

cshung commented Sep 17, 2021 • edited Loading

Maoni0 commented Jul 8, 2022

timcassell commented Jul 8, 2022 • edited Loading

cshung commented Jul 9, 2022

timcassell commented Jul 10, 2022

timcassell commented Dec 1, 2020 •

edited

Loading

timcassell commented Dec 2, 2020 •

edited

Loading

timcassell commented Dec 3, 2020 •

edited

Loading

timcassell commented Jul 24, 2021 •

edited

Loading

timcassell commented Aug 13, 2021 •

edited

Loading

timcassell commented Sep 15, 2021 •

edited

Loading

timcassell commented Sep 15, 2021 •

edited

Loading

cshung commented Sep 17, 2021 •

edited

Loading

timcassell commented Jul 8, 2022 •

edited

Loading