我使用CrtDumpMemoryLeaks来识别软件中的内存泄漏。我们在多线程应用程序中使用第三方库。这个库确实存在内存泄漏,因此在我们的测试中,我们希望识别那些我们的库,并丢弃那些我们没有任何控制权的库。
我们使用持续集成,因此新的函数/算法/bug修复总是被添加。
所以问题是-是否有一个安全的方法来识别那些泄漏是我们的和那些是第三方图书馆。我们考虑使用分配号码,但这安全吗?
发布于 2014-08-06 10:07:01
您可能希望使用微软提供的DebugDiag工具。有关该工具的完整信息,我们可以参考:http://www.microsoft.com/en-sg/download/details.aspx?id=40336
DebugDiag可用于识别各种问题。我们可以按照以下步骤跟踪泄漏(我们的和第三方模块):
一旦分析完成,DebugDiag将自动生成报告,并向您提供可能发生泄漏的模块/DLL信息(可能性)。在此之后,我们从DebugDiag工具中获得了有关模块的信息,我们可以通过进行静态代码分析来集中精力于特定的模块。如果模块属于第三方DLL,则可以将DebugDiag报表共享给它们。此外,如果您使用适当的PDB文件运行/附加您的应用程序,DebugDiag还在可能发生内存泄漏的地方提供调用堆栈。
在基于windows的应用程序上调试内存泄漏时,这些信息在过去非常有用。希望上面的信息是有用的。
发布于 2014-08-03 10:55:33
在一个大型应用程序中,我负责全局new和delete操作符被覆盖(例如。参见如何正确替换全局新操作符和删除操作符)和使用的私有堆(例如。HeapCreate。第三方库将使用进程堆,因此分配将被清楚地分开。
坦率地说,我认为你在分配数字方面做得不太好。为应用程序/库使用显式的单独堆(甚至在您自己的应用程序中有单独的每个组件堆)将是更容易管理的。考虑一下,您可以将自己的应用程序特定的头添加到每个分配的块中,从而启用非常漂亮的内存跟踪。例如,捕获整个调用堆栈的分配是可能的,以便进行调试。启用每个组成部分的会计。等。
发布于 2014-08-11 16:15:05
您可以使用Mirosoft的堆调试库来完成此操作,而无需使用任何第三方解决方案。根据我从前面的一个问题中学到的内容,您应该确保代码中分配的所有内存都是通过调用dbg来分配的,其中第二个参数设置为_CLIENT_BLOCK。然后可以使用CrtSetDumpClient设置回调函数,该回调将只接收有关已分配的客户端块的信息,而不接收其他块的信息。
您可以很容易地使用预处理器将所有对malloc和free的调用转换为实际调用它们的调试版本(例如_malloc_dbg);只需看看它是如何在Visual附带的crtdbg.h中完成的。
对我来说,棘手的部分是弄清楚如何覆盖new和delete操作符来调用_malloc_dbg之类的调试函数。如果您自己的代码中只有new和delete受到影响,而不是在第三方库中,则很难找到解决方案。
https://stackoverflow.com/questions/25103724
复制相似问题