1

我正在尝试使用 boundschecker 来分析一个相当复杂的程序。使用 boundschecker 运行程序几乎太慢了，无法使用，因为我需要将近一天的时间才能将程序运行到代码中我怀疑存在问题的位置。谁能给我一些关于如何在 Visual Studio 2005 中使用 boundschecker (DevPartner) 检查我的软件的某些部分的想法？

提前感谢您的所有帮助！

4

3 回答 3

2

几年前我最后一次使用 BoundsChecker，并且遇到了同样的问题。对于大型项目，它会使一切运行得如此缓慢以至于毫无用处。我们最终放弃了它。

但是，我们仍然需要它的一些功能，但像您一样，不需要整个程序。所以我们必须自己做。

在我们的案例中，我们主要使用它来尝试追踪内存泄漏。如果这也是您的目标，那么还有其他选择。

  1. 当程序退出时，Visual Studio 可以很好地告诉您有关内存泄漏的信息
  2. 它按照创建的顺序报告泄漏
  3. 如果你的源文件在顶部有这个，它会告诉你泄漏的内存是在哪里创建的

#ifdef _DEBUG
#undef THIS_FILE
static char THIS_FILE[]=__FILE__;
#define new DEBUG_NEW
#endif

这些帮助很大，但通常还不够。在任何地方添加该片段并不总是可行的。如果您使用工厂类，那么知道分配内存的位置根本没有帮助。因此，当所有其他方法都失败时，我们会利用 #2。

添加如下内容：

#define LEAK(str) {char *s = (char*)malloc(100); strcpy(s, str);}

然后，用 "LEAK("leak1");" 给你的代码添点色彩 管他呢。运行程序，然后退出。您的新泄漏字符串将显示在 Visual Studio 的泄漏转储中，围绕现有泄漏。继续添加/移动您的 LEAK 语句并重新运行程序以缩小搜索范围，直到您确定确切的位置。然后修复泄漏，删除调试泄漏，一切就绪！

于 2009-01-23T15:27:27.700 回答
0

BoundsChecker 非常详细地跟踪所有内存分配和释放。例如，它知道这样那样的内存分配是从 C 运行时堆中完成的，而后者又是从 Win32 堆中获取的，而 Win32 堆又开始作为由 VirtualAlloc 分配的内存。如果应用程序被检测（FinalCheck），它还具有有关哪些指针引用内存的详细信息。

这是事情缓慢的（许多）原​​因之一。

如果 BC 延迟连接到应用程序，它将不会构建任何这些数据，并且会 (1) 立即将其全部挖掘出来，或者 (2) 开始猜测事情。这两种解决方案都不是很实用。

于 2010-08-14T23:39:46.093 回答
0

减轻 BoundsChecker 的一种方法是从检测中排除除您感兴趣的少数模块之外的所有模块。我知道这不是很好，因为如果您知道泄漏在哪里，您就不需要 BoundsChecker。我通常建议您首先使用 BC 的 Active Check 模式，只有 Memory Tracking 可用。你错过了 API 验证，但你总是可以单独重新运行它。在您运行 Active Check 并获得有关哪些模块容易出现问题的线索后，您才可以为感兴趣的一个或多个模块及其依赖项启用检测。我们知道 Final Check 非常慢，但正如 Mistiano 正确指出的那样，使用 Final Check 不仅可以保存所有已分配块的图表，还可以保存所有指向它们的指针和上下文。Final Check 的神奇之处就在于如何在发生时发现泄漏和损坏，而不仅仅是在应用程序关闭或故障时。无耻的插件：我在 DevPartner 团队工作。我们将于 2011 年 2 月 4 日发布 DPS 10.5，在 BC 中支持 x64 应用程序。与仅提供 Active Check 的 Itanium 相对古老且销量较低的 BC64 不同，DPS 10.5 为 x64 应用程序提供完整的 Final Check 支持，包括纯 C++ 和在 .NET 进程中运行的本机模块。有关详细信息，请参阅 MF Developer 下的 microfocus.com。5 为 x64 应用程序提供完整的最终检查支持，包括纯 C++ 和在 .NET 进程中运行的本机模块。有关详细信息，请参阅 MF Developer 下的 microfocus.com。5 为 x64 应用程序提供完整的最终检查支持，包括纯 C++ 和在 .NET 进程中运行的本机模块。有关详细信息，请参阅 MF Developer 下的 microfocus.com。

于 2011-01-29T14:58:33.250 回答