你能启动和停止DevPartner吗？

Question

我正在尝试使用boundschecker来分析一个相当复杂的程序。使用boundschecker运行程序几乎太慢了，它没有任何用处，因为我几乎花了一天的时间来运行程序，直到我怀疑问题存在的代码中的点。有没有人能给我一些建议，告诉我如何在Visual Studio2005中使用边界检查器(DevPartner)只检查软件的某些部分？

提前感谢您的帮助！

Answer 1

我上一次使用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围绕现有泄漏的泄漏转储中。不断添加/移动您的泄漏语句，并重新运行程序以缩小搜索范围，直到您找到确切的位置。然后修复漏洞，移除您的调试漏洞，您就都准备好了！

Answer 2

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

这是(许多)原因之一，为什么事情是缓慢的。

如果BC连接到应用程序较晚，它将不会建立任何这些数据，并且将不得不(1)一次将其全部挖掘出来，或者(2)开始猜测事物。这两种解决方案都不太实用。

Answer 3

减轻BoundsChecker负担的一种方法是，除了您感兴趣的几个模块之外，将所有模块排除在检测之外。我知道这不是很好，因为如果你知道泄漏在哪里，你就不需要BoundsChecker了。我通常建议您首先使用BC的活动检查模式，只有内存跟踪可用。你错过了API验证，但你可以单独重新运行它。在运行Active Check并获得有关哪些模块可能有问题的线索后，才能为感兴趣的一个或多个模块及其依赖项启用插装。我们知道Final Check非常慢，但正如Mistiano正确指出的那样，Final Check不仅保存了所有已分配块的图形，还保存了指向它们的所有指针和上下文。这就是Final Check如何在发生时发现泄漏和损坏，而不仅仅是应用程序关闭或故障的魔力所在。不知羞耻的插头:我在DevPartner团队工作。我们将于2011年2月4日发布支持BC的x64应用程序的DPS10.5。与相对古老且销售不佳的安腾BC64仅提供主动检查不同，DPS10.5为x64应用程序提供了完整的最终检查支持，包括纯C++和在.NET进程中运行的本机模块。详情请参考MF Developer下的microfocus.com。