blocks|key|4173077|text|这类工具通常使用它们自己的代码来检测可执行文件。例如，它们使用自己的函数替换对malloc()和free()的每次调用，这允许它们遵循每次分配。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|4173078|在Visual+Studio中，只需使用C运行时库并使用_CrtDumpMemoryLeaks()家族中的函数即可自动完成此操作|4173079|entityMap^0|13|8|1C|6|0|S|L|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]|$9|M|A|N|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|O|8|@$9|P|A|Q|B|C]]|D|@]|E|$]]|$1|H|3|-4|5|6|7|R|8|@]|D|@]|E|$]]]|I|$]]

Such tools usually instrument the exeutable with their own code. for instance they replace every call to <code>malloc()</code> and <code>free()</code> with their own functions which allows them to follow every allocation.

In Visual Studio this can be done automatically using just the C Runtime Library using functions from the family of <code>_CrtDumpMemoryLeaks()</code>

blocks|key|796783|text|对于基本的泄漏检测，您只需挂钩到低级内存分配例程，例如，通过修补malloc/free。然后，您可以跟踪所有分配，并随后报告在适当的时间点未释放的任何分配，例如在退出之前。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|796784|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

For basic leak detection you just need to hook into low level memory allocation routines, e.g. by patching malloc/free. You then track all allocations and subsequently report any that have not been freed at an appropriate point, e.g. just prior to exit.

blocks|key|2701653|text|在实际工作中，valgrind工作得很好。它检测无效的读/写和内存泄漏。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2701654|对于业余爱好项目，您可以创建自己的内存管理模块，跟踪各种指针分配及其使用情况。如果你长时间没有看到某个内存位置被使用，那可能是一个漏洞。|2701655|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

For actual work, valgrind works quite well. It detects invalid read/write and memory leaks.

For hobby project, you can create your own memory management module which keeps track of various pointer allocation and its usage. If you don't see some mem location being used for long time, it might be a leak.

blocks|key|2708866|text|您可以在内存管理/分析工具的一些BSD实现中查找代码示例。例如http://code.google.com/p/google-perftools/wiki/GooglePerformanceTools|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2708867|entityMap|0|LINK|mutability|MUTABLE|url|http://code.google.com/p/google-perftools/wiki/GooglePerformanceTools^0|V|1X|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

You can look for some BSD implementations of memory management/profiling tools for examples of code. For instance <a href="http://code.google.com/p/google-perftools/wiki/GooglePerformanceTools" rel="nofollow noreferrer">http://code.google.com/p/google-perftools/wiki/GooglePerformanceTools</a>

blocks|key|4173118|text|我正在开发这个工具：Deleaker。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|4173119|当然，显而易见的想法是挂钩所有进行分配和释放的函数。这不仅仅是malloc和免费的，而是HeapAlloc+/+HeapFree+(如果我们谈论的是Windows平台)，因为现代的VC%2B%2B版本(VC6.0以后)只是将malloc+/+free重定向到winapi的HeapAlloc+/+HeapFree。|4173120|对于每个分配，都会保存一个堆栈和一个对象。每次释放时，对象都会被释放。乍一看，这很简单:只需存储一个已分配对象的列表，然后在取消分配钩子上删除一个对象。|4173121|但也有一些棘手的部分：|4173122|4173123|Speed|unordered-list-item|4173124|4173125|您需要维护已分配对象的列表。如果你在每个钩子函数中添加/删除一个对象，那么这个过程就会执行得很慢。这似乎是此类工具的一个常见问题。|4173126|4173127|堆栈跟踪|4173128|4173129|使用dbghelp.dll函数获取堆栈跟踪需要花费大量时间。您必须更快地获取堆栈条目:例如，通过手动读取进程内存。|4173130|4173131|假阳性|4173132|4173133|一些泄漏是由系统DLL产生的。如果你把它们全部展示出来，你就会发现大量的漏洞，但是用户不能“解决”它:他/她不能访问它的源代码，也不能阻止执行这段代码。要阻止这种泄漏是不可能的。其中一些是系统dll入口点的单一分配，所以这不是真正的泄漏(一个好问题，到底是什么泄漏？)如何识别那些必须显示的泄漏？一个好的过滤就是一个答案。|4173134|希望这能有所帮助。|4173135|entityMap|0|LINK|mutability|MUTABLE|url|http://deleaker.com/^0|A|8|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1C|8|@]|9|@$A|1D|B|1E|1|1F]]|C|$]]|$1|D|3|E|5|6|7|1G|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|1H|8|@]|9|@]|C|$]]|$1|H|3|I|5|6|7|1I|8|@]|9|@]|C|$]]|$1|J|3|-4|5|6|7|1J|8|@]|9|@]|C|$]]|$1|K|3|L|5|M|7|1K|8|@]|9|@]|C|$]]|$1|N|3|-4|5|6|7|1L|8|@]|9|@]|C|$]]|$1|O|3|P|5|6|7|1M|8|@]|9|@]|C|$]]|$1|Q|3|-4|5|6|7|1N|8|@]|9|@]|C|$]]|$1|R|3|S|5|M|7|1O|8|@]|9|@]|C|$]]|$1|T|3|-4|5|6|7|1P|8|@]|9|@]|C|$]]|$1|U|3|V|5|6|7|1Q|8|@]|9|@]|C|$]]|$1|W|3|-4|5|6|7|1R|8|@]|9|@]|C|$]]|$1|X|3|Y|5|M|7|1S|8|@]|9|@]|C|$]]|$1|Z|3|-4|5|6|7|1T|8|@]|9|@]|C|$]]|$1|10|3|11|5|6|7|1U|8|@]|9|@]|C|$]]|$1|12|3|13|5|6|7|1V|8|@]|9|@]|C|$]]|$1|14|3|-4|5|6|7|1W|8|@]|9|@]|C|$]]]|15|$16|$5|17|18|19|C|$1A|1B]]]]

I am developing this tool: <a href="http://deleaker.com" rel="nofollow">Deleaker</a>.

Sure, the obvious idea is to hook all functions that do allocations and deallocations. That's not only malloc and free, rather HeapAlloc / HeapFree (if we are talking about Windows platform) because modern VC++ versions (after VC 6.0) just redirect malloc / free to winapi's HeapAlloc / HeapFree.

For each allocation a stack is saved and an object is saved. On each deallocation the object is freed. At a first glance, it's so simple: just store a list of allocated objects and remove an object on deallocation hook.

But there are tricky parts:

<ul>
<li>Speed</li>
</ul>

You need to maintain a list of allocated objects. If you add/remove an object in each hooked function, the process is being executing toooo slooow. That seems to be a common problem of such tools.

<ul>
<li>Stack Trace</li>
</ul>

Using dbghelp.dll function to get stack trace takes a lot of time. You have to get stack entries faster: for example by manual reading of process memory.

<ul>
<li>False positives</li>
</ul>

Some leaks are produced by system DLLs. If you show all of them, you got a tons of leaks, but user can't "solve" it: he/she doesn't have access to its source code, and can't prevent executing this code. It's impossible to stop this leaks. Some of them are single allocations at a system dll's entry point, so it's not a real leak (a good question, what's the leak at all?). How to recognize those leaks that must be shown? A good filtering is an answer.

Hope this helps.

How do memory leak detection tools like purify and valgrind work?

How can I design and implement my own such tool?

Tool for detecting memory leaks

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

像purify和valgrind这样的内存泄漏检测工具是如何工作的？我如何设计和实现我自己的这样的工具？

问内存泄漏检测工具
EN

回答 5

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问内存泄漏检测工具EN

回答 5

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问内存泄漏检测工具
EN