当你做错一切时追踪内存泄漏的策略 [英] Strategies For Tracking Down Memory Leaks When You've Done Everything Wrong

问题描述

唉，我的程序在某处发生了内存泄漏，但如果我知道它是什么，我会被诅咒的.

My program, alas, has a memory leak somewhere, but I'll be damned if I know what it is.

它的工作是读入一堆~2MB 的文件，做一些解析和字符串替换，然后以各种格式输出它们.自然，这意味着很多字符串，因此进行内存跟踪表明我有很多字符串，这正是我所期望的.程序的结构是一系列类(每个类都在自己的线程中，因为我是一个白痴)，它们作用于代表内存中每个文件的对象.(每个对象都有一个在两端使用锁的输入队列.虽然这意味着我可以并行运行这个简单的处理，但这也意味着我有多个 2MB 的对象位于内存中.)每个对象的结构由一个模式对象定义.

Its job is to read in a bunch of ~2MB files, do some parsing and string replacement, then output them in various formats. Naturally, this means a lot of strings, and so doing memory tracing shows that I have a lot of strings, which is exactly what I'd expect. The structure of the program is a series of classes (each in their own thread, because I'm an idiot) that acts on an object that represents each file in memory. (Each object has an input queue that uses a lock on both ends. While this means I get to run this simple processing in parallel, it also means I have multiple 2MB objects sitting in memory.) Each object's structure is defined by a schema object.

我的处理类在完成处理后引发事件，并传递对包含所有字符串的大对象的引用，以将其添加到下一个处理对象的队列中.用函数调用替换事件以添加到队列并不能阻止泄漏.其中一种输出格式要求我使用非托管对象.在类上实现 Dispose() 不会阻止泄漏.我已经用索引名称替换了对架构对象的所有引用.没有骰子.我不知道是什么原因造成的，也不知道去哪里看.内存跟踪无济于事，因为我看到的只是一堆正在创建的字符串，而且我没有看到引用在内存中的位置.

My processing classes raise events when they've done their processing and pass a reference to the large object that holds all my strings to add it to the next processing object's queue. Replacing the event with a function call to add to the queue does not stop the leak. One of the output formats requires me to use an unmanaged object. Implementing Dispose() on the class does not stop the leak. I've replaced all the references to the schema object with an index name. No dice. I got no idea what's causing it, and no idea where to look. The memory trace doesn't help because all I see are a bunch of strings being created, and I don't see where the references are sticking in memory.

此时我们几乎要放弃并回滚，但我有一种病态的需要，确切地知道我是如何搞砸的.我知道 Stack Overflow 不能完全梳理我的代码，但是您可以建议什么策略来跟踪此泄漏?我可能会在我自己的时间做这件事，所以任何方法都是可行的.

We're pretty much going to give up and roll back at this point, but I have a pathological need to know exactly how I messed this up. I know Stack Overflow can't exactly comb my code, but what strategies can you suggest for tracking this leak down? I'm probably going to do this in my own time, so any approach is viable.

推荐答案

我要尝试的一种技术是系统地减少演示问题所需的代码量，而不会使问题消失.这被非正式地称为分而治之"，是一种强大的调试技术.一旦你有一个小示例来演示同样的问题，你就会更容易理解.或许那个时候记忆问题会变得更清楚.

One technique I would try is to systematically reduce the amount of code you need to demonstrate the problem without making the problem go away. This is informally known as "divide and conquer" and is a powerful debugging technique. Once you have a small example that demonstrates the same problem, it will be much easier for you to understand. Perhaps the memory problem will become clearer at that point.

这篇关于当你做错一切时追踪内存泄漏的策略的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！