你能重现这个64位.NET 4 GC错误吗？ [英] Can you repro this 64-bit .NET 4 GC bug?

问题描述

更新：微软现在已经重现了这个错误并正在努力解决问题。

$ b 在评估.NET平台的可行性的同时，低延迟的软件开发，我们发现.NET 4并发工作站垃圾收集器中存在一个严重的错误，它可能导致应用程序一次挂起几分钟。

在我们的三台机器中，以下简单的C＃程序会导致GC泄漏内存，直到没有剩余内存，并且一个庞大的GC循环开始运行，程序停止几分钟（！），同时11Gb的堆被回收：

  static void Main（string [] args）
 {
 var q = new System.Collections.Generic.Queue< System。对象>（）; 
 while（true）
 {
 q.Enqueue（0）; 
 if（q.Count> 1000000）
 q.Dequeue（）; 
 
 
 
 
 
 $ b 
 你需要为x64编译一个使用.NET 4的64位Windows操作系统，并使用默认（交互式）延迟设置与默认（并发工作站）GC一起运行。     任务管理器看起来像在这台机器上运行这个程序时：
 
 
 
  
 
 
 
请注意，当这个程序需要不超过100Mb的内存时，11Gb的堆已经被泄露。
 
 
 
现在我们已经累积了大约十多个用F＃和C＃编写的bug的repros，并且它似乎与gen0中大部分存活的GC写入屏障中的错误有关。但是，微软还没有能够重现它。你可以吗？如果是这样，您能否请尽可能准确地描述您的设置，以便我们可以尝试精确缩小该错误所需的条件。
解决方案
 
 
运行linqpad中的代码确实会导致巨大的内存消耗，如果运行64位;运行的32位工作正常。
 
 
 
我有一个Windows 7 x64终极安装（像往常一样修补）与8GB的主内存; VS.NET和其他开发工具的安装，可能会有一些奇怪的调试器挂钩，这是不存在于其他空白的机器。
 
 
 
奇怪，他们没有repro 'd it。你确定这里没有一些通信故障吗？哦，并且使用新对象（）而不是盒装值类型导致同样的问题（不出所料），所以您可能需要从您的repro案例中删除混淆因素。
 
Update: Microsoft have now reproduced the bug and are working on a fix.

Whilst evaluating the viability of the .NET platform for low latency software development, we have discovered a serious bug in the .NET 4 concurrent workstation garbage collector that can cause applications to hang for up to several minutes at a time.

On three of our machines the following simple C# program causes the GC to leak memory until none remains and a single mammoth GC cycle kicks in, stalling the program for several minutes (!) while 11Gb of heap is recycled:
    static void Main(string[] args)
    {
        var q = new System.Collections.Generic.Queue<System.Object>();
        while (true)
        {
            q.Enqueue(0);
            if (q.Count > 1000000)
                q.Dequeue();
        }
    }
You need to compile for x64 on a 64-bit Windows OS with .NET 4 and run with the default (concurrent workstation) GC using the default (interactive) latency setting.

Here's what the Task Manager looks like when running this program on this machine:



Note that 11Gb of heap have been leaked here when this program requires no more than 100Mb of memory.

We have now accumulated around a dozen repros of this bug, written in F# as well as C#, and it appears to be related to a bug in the GC write barrier when most of gen0 survives. However, Microsoft have not yet been able to reproduce it. Can you? If so, can you please describe your setup as accurately as possible so we can try to narrow down exactly what conditions are required for this bug to manifest.
解决方案
Running the code in linqpad indeed causes huge memory consumption if running as 64-bit; running as 32-bit works fine.

I've got a windows 7 x64 ultimate install (patched as usual) with 8GB of main memory; VS.NET and other dev tools are installed so there might be some weird debugger hooks which aren't present on an otherwise blank machine.

Odd that they haven't repro'd it.  Are you sure there's not some communication breakdown there?

Oh, and using "new object()" rather than a boxed value type causes the same issue (unsurprisingly), so you might want to remove the confounding factor of boxing from your repro case.

                        
这篇关于你能重现这个64位.NET 4 GC错误吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！