【 tulaoshi.com - 编程语言 】
一、 为什么写这篇东西 自己在使用 BCB5 写一些程序时需要检查很多东西，例如内存泄漏、资源是否有释放等等，在使用了很多工具后，发觉 BCB5 本身自带的工具—— CodeGuard ，非常不错，使用也挺方便的，但是摸索了很久（以及翻查了一些资料，包括 HELP ）才算是会用了。写这篇文章的目的希望有这方面的问题的朋友可以借鉴一下，大家互相学习，共同进步。我的联系方法： Email ：
szbug@szbug.com ，希望志同道合的朋友来信互相交流。以下这篇文章算是拼凑出来的一篇文章，一些资料是在书上找的，一些是在 HELP 上看到了。 二、 什么是 CodeGuard CodeGuard 是在是 C++Builder5 才出现的一个工具。 CodeGuard 是 C++Builder 中一个程序在运行时期的检查器，用于检查内存或者资源的使用，以及函数调用的验证。 CodeGuard 可以检测到以下的程序运行期错误： l 非法的内存释放。 l 无效的句柄或者文件流。 l 非法指针。 l 使用已被释放的指针。 l 内存泄漏。 l 分配但最后没有释放的内存变量。 l 传递给函数的不正确的参数（包括 VCL 以及 Win32 函数）。 l 函数返回值的错误。（包括 VCL 以及 Win32 函数）。 例如：在应用程序中试图多次释放相同的资源（或者已经释放了的资源）、试图访问已经被释放的内存。 三、 在 BCB5 中怎样使用 CodeGuard ——配置 CodeGuard 假如要使用 CodeGuard 的话，必须有些代码编译进你的应用程序，所以在改变以下这些设置后。必须全部重新编译（切记切记！！！）。第一、打开应用程序的工程选项的 CodeGuard 页框，把 CodeGuard Validation 前面打勾 工程选项里，还有其他三个选项。第一个选项答应 CodeGuard 检查指向局部、全局和静态变量的无效指针和数据溢出。第二个选项答应 CodeGuard 检测对非法的（无效的、已删除的）对象的方法的调用。第三个选项答应 CodeGuard 验证内嵌指针的访问（在某些资料上说，开启这个选项会造成程序执行速度变得很慢，我测试过了，假如工程不是很大的话不是很明显，可以接受。）一般的调试是开打所有的选项（默认选择也是全部打开）。 通过 CodeGuard 的配置工具，可以配置 CodeGuard 的一些选项，在命令行方式执行 CGCONFIG.EXE 。可以见到一个对话框 Preferences 标签页用于设置 CodeGuard 这个工具的全局选项。 Enable 选项可以在应用程序不重新编译的情况下使用或者不使用 CodeGuard ，一般来说是都是启用她。假如使用 CodeGuard 的话，建议设置工程选项来禁止或者使用 CodeGuard 。 Stack fill frequency 填充栈频率是检测对运行期栈的无效访问。 Report 和 Error Message Box 选项是设置 CodeGuard 报告错误的方式。在 Report 里， Stiatistics 选项打开 CodeGuard 输出分配和释放内存的统计表、被使用的 Win32API 的调用、资源的使用情况，并在日志文件中加上一个模块列表，以便检查错误。 Resource Leaks 选项是告诉 CodeGuard 在应用程序结束后报告资源泄漏的情况。选定了 Error Message Box 选项后，当应用程序不在 IDE 里运行时，假如 CodeGuard 检测到错误信息，那么将采用一个对话框的方式告诉使用者。其他选项一般不常用，可以参见 C++Builder 的联机 HELP 。 CodeGuard 配置工具中的 Resource Options 和 Function Options 页框答应用户对应用程序的资源、文件和函数调用设置各种跟踪选项。除非非凡的原因需要改变默认的配置，否则使用缺省的设定就行了。 Function Options 页上有一个比较常用的选项就是记录一个特定函数的每次调用情况。 Ignored Modules 页框答应你告诉 CodeGuard ，当检测的时候可以忽略一些运行期的错误（一般是指某些 DLL 或者包）。这个选项一般不常用。 四、 使用 CodeGuard 使用 CodeGuard 其实很简单，只要像之前那样配置了 CodeGuard ，然后运行你的应用程序，无论你的应用程序是否在 IDE 中运行， CodeGuard 都将会按照 CodeGuard 配置的选项监视你的应用程序。同时，他还会向一个日志文件里输出所有的信息（文件存放在你的工程所在目录中，文件名和工程名一样，扩展名为 .cgl ）。例如你的工程名为 C:WordTest.prg ，那么 CodeGuard 的日志文件为 C:WordTest.cgl ，它是一个文本文件，可以用任何的文本编辑器来编辑它。 在 IDE 中，可以通过 菜单 View-Debug Window-CodeGuard Log 来查看 CodeGuard 的日志文件（或者用快捷键 Ctrl+Atl+O ）。 假如你的程序在运行是出现属于 CodeGuard 监视的错误的时候， CodeGuard 会把它输出到 CodeGuard Log 中。并将错误信息用一颗“树”的方式显示（使用很方便，就像使用 Windows 的资源治理器一样简单）。每个错误都可以展开，以显示某种错误类型所特有的一些信息。例如：一个资源那个地方使用了、分配以及释放；发生错误时的栈信息；并且指出了出错的代码行。这样就可以很快的找到错误的根源！ CodeGuard Log 窗口上有两个按钮 Stop 和 Clear 。当 Stop 选中的时候，假如这个时候程序碰到了错误， CodeGuard 将停止应用程序。假如未选中，那么程序就算碰到了错误也会继续，这样可以运行一次记录很多错误信息。当 Clear 选中的时候，应用程序每次重新运行将清空日志中的信息。 在 CodeGuard Log 窗口中，双击单个错误的节点的时候，假如存在源代码的话， IDE 窗口会自动跳到那一行代码上。假如不存在源代码的话，则显示 CPU 窗口。图三中，出现的错误是资源泄漏。当你的鼠标双击 Tform1 ： Button1Click 这一行的时候，会自动跳到源代码中出现错误的那一行。
当 CodeGuard 检测到一个错误的时候，并找到出现问题的源代码时，剩下的工作就是假如改正你的代码。这个过程可以配合监视和数据断点来实现，效果更加好！ 五、 CodeGuard 中的错误以及原因 CodeGuard 可以检测到很多运行期的错误！通常很轻易就可以从 CodeGuard 的含义找出错误的根源。对于大多数的错误， CodeGuard 一般会显示的包括：发生错误的地方、资源分配、资源释放、资源被分配以及被访问字节数。 1. Access In Freed Memory 假如内存被释放了，在后面还继续访问，就会发生这个错误。在 C/C++ 中，通常使用 new 或者 malloc 分配内存，用 delete 和 free 释放。以下是一个访问了被释放的内存的例子： void foo() { TMyClass *MyClass = new TMyClass(); delete MyClass; MyClass-xxxx = 10; //MyClass 已经被释放了 } CodeGuard 会报告已被释放的内存在何处被访问，内存原来被分配的地方以及内存在哪里被释放的。 2. Method Called On Freed Object 这个错误跟前一个错误类似。起因是由于调用了已被释放的对象的方法而不是访问已被释放的内存！ void foo() { TMyClass *MyClass = new TMyClass(); delete MyClass; MyClass-xxxx (10); } CodeGuard 将显示在何处调用了已释放对象的方法，对象被创建的地方以及对象被释放的地方。 3. Reference To Freed Resource 在程序中试图多次（两次以上）释放同一个资源， CodeGuard 将检测到这个错误，有好几种方法都会产生这个错误！例如： void foo() { TMyClass *MyClass = new TMyClass(); delete MyClass; delete MyClass; } CodeGuard 将报告资源在何处第二次被释放，从而引起这个错误的。还会报告资源在何处分配，在何处首次释放。 4. Method Called On Illegally Casted Object 假如在程序中对有效的内存范围之外的方法的调用将会引起这个错误。 void foo() { TMyClass *MyClass = new TMyClass[5]; MyClass[5].xxxx(); //No sUCh MyClass[5] delete []MyClass; } CodeGuard 将报告对象调用的方法定义的地方，以及这个方法被调用的地方以及对象或者内存被分配地方。 5. Resource Type Mismatch 假如在程序中释放资源和定义（分配）时候不一致，会出现这个错误。 void foo() { TMyClass *MyClass = new TMyClass[2]; delete MyClass; //Code1 TMyClass *MyClass = new TMyClass(); delete []MyClass; //Code2 } 在 Code1 以及 Code2 都会引发 Resource Type Mismatch 错误， CodeGuard 将会报告资源在何处以不一致的方式被释放，以及资源是在哪里被分配的地方。 QQ病毒腾讯QQ空间代码专题PPT教程专题ADSL应用面面俱到 Fireworks教程专题计算机和网络技术基础知识校园网专题网吧技术专题6. Access Overrun 当访问非法内存区域的内存时会造成这个错误（所访问的内存在合法内存区域之后），通常情况下是数组下标引用超出原来定义的。 void foo() { TMyClass *MyClass = new TMyClass[2];
MyClass[2].abc = 10; //No such MyClass[2] delete [] MyClass; char *ch = new char[5]; strcpy(ch, “123456”); //Error delete []ch; } CodeGuard 报告出错的地方，资源在哪里分配的。 7. Access Underrun 当访问非法内存区域的内存时会造成这个错误（所访问的内存在合法内存区域之前）。 void foo() { TMyClass *MyClass = new TMyClass[2]; MyClass[-1].abc = 10; //No such MyClass[2] delete [] MyClass; } CodeGuard 报告出错的地方，资源在哪里分配的。 8. Uninitialized Stack Accessing 访问栈中为被初始化的区域将会造成这个错误。 void foo1(int **Ptr) { int Var; *Ptr = &Var; } void foo() { int *Ptr; foo1(&Ptr); *Ptr = 100; } CodeGuard 将会报告何处访问还没有被初始化的栈。 9. Access In Invalid Stack 当在程序中尝试访问栈底部的内存的时候出现这个错误！ void foo() { char str[20]; strcpy(&str[-1], “szbug”); } CodeGuard 报告发生错误的地方。 10. Bad Parameter 这个错误通常是出现无效的文件或者其他资源句柄作为参数传递给 VCL 或者 Win32API 函数时发生的。 Void foo() { FILE *Stream; fclose(Stream); } CodeGuard 将报告使用了不正确参数的函数在何处被调用。 11. Function Failure 这个错误是 CodeGuard 在捕捉 VCL 以及 Win32API 函数的返回值假如出现错误时引发的。 viod foo() { CopyFile(“c:abcabc.txt”, “d:abcacb.txt”, true); // 假如这个函数由于某种原因失败了， // 那么 CodeGuard 将会捕捉并报告 Function Failure 错误！ } 12. Resource Leak 假如在程序中资源（包括 Winwos 资源，内存资源等等），分配了，在程序的最后没有释放！将引发 Resource Leak 错误。 Void foo() { char *ch = new char[10]; } CodeGuard 将报告资源创建的地方，以及所泄漏的字节数。 六 运行后会生产同名的CGL文件,里面包括函数的调用次数和使用到的DLL.假如有泄露的话,会指出在来!!!! Functions called:
delete (35 times)
SysReallocMem (26 times)
SysFreeMem (464 times)
SysGetMem (472 times)
realloc (1 times)
memcpy (1 times)
delete[] (2 times)
free (26 times)
new[] (14 times)
new (40 times)
calloc (5 times)
malloc (20 times)
Resource types used:
object array (14 allocs, 13 max)
object (40 allocs, 28 max)
Modules used:
00400000 02/07/2003 09:56:24 D:Project1.exe
01190000 02/01/2002 22:00:00 C:Program
FilesBorlandDelphi7BinBORLNDMM.DLL
0CD00000 02/01/2002 22:00:00 C:PROGRA~1BorlandCBUILD~1BinCG32.DLL
10000000 03/09/2001 18:42:32 C:WINNTmuifallback
