boundschecker有boundschecker for vs2008吗，该怎么处理

c++中有malloc必须有free么，为什么？

malloc和free必须成对出现，因为malloc开辟的内存空间在堆区，系统在程序结束时不会自动释放，如果程序员自己不手动释放的话就会造成内存泄露（就是有个指针指向一块内存，结果函数一结束，指针被删除了，而那块内存空间还在），那块内存空间就再也找不到了。

同样的道理，new开辟的空间也在堆区，你也必须用delete去释放。

microsoft windows dynamic cache service 的工具怎么样

malloc－Linux和Solaris下对C和C++程序的简单的使用内存泄漏和malloc调试库。

2. 2. ? ? Dmalloc－Debug Malloc Library. 3. 3. ? ? Electric Fence－Linux分发版中由Bruce Perens编写的malloc()调试库。

4. 4. ? ? Leaky－Linux下检测内存泄漏的程序。

5. 5. ? ? LeakTracer－Linux、Solaris和HP-UX下跟踪和分析C++程序中的内存泄漏。

6. 6. ? ? MEMWATCH－由Johan Lindh编写，是一个开放源代码C语言内存错误检测工具，主要是通过的precessor来进行。

7. 7. ? ? Valgrind－Debugging and profiling Linux programs, aiming at programs written in C and C++. 8. 8. ? ? KCachegrind－A visualization tool for the profiling data generated by Cachegrindand Calltree. 9. 9. ? ? Leak Monitor－一个Firefox扩展，能找出跟Firefox相关的泄漏类型。

10. 10. IE Leak Detector (Drip/IE Sieve)－Drip和IE Sieve leak detectors帮助网页开发员提升动态网页性能通过报告可避免的因为IE局限的内存泄漏。

11. 11. Windows Leaks Detector－探测任何Win32应用程序中的任何资源泄漏(内存，句柄等)，基于Win API调用钩子。

12. 12. SAP Memory Analyzer－是一款开源的JAVA内存分析软件，可用于辅助查找JAVA程序的内存泄漏，能容易找到大块内存并验证谁在一直占用它，它是基于Eclipse RCP(Rich Client Platform)，可以下载RCP的独立版本或者Eclipse的插件。

13. 13. DTrace－即动态跟踪Dynamic Tracing，是一款开源软件，能在Unix类似平台运行，用户能够动态检测操作系统内核和用户进程，以更精确地掌握系统的资源使用状况，提高系统性能，减少支持成本，并进行有效的调节。

14. 14. IBM Rational PurifyPlus－帮助开发人员查明C/C++、托管.NET、Java和VB6代码中的性能和可靠性错误。

PurifyPlus 将内存错误和泄漏检测、应用程序性能描述、代码覆盖分析等功能组合在一个单一、完整的工具包中。

15. 15. Parasoft Insure++－针对C/C++应用的运行时错误自动检测工具，它能够自动监测C/C++程序，发现其中存在着的内存破坏、内存泄漏、指针错误和I/O等错误。

并通过使用一系列独特的技术（SCI技术和变异测试等），彻底的检查和测试我们的代码，精确定位错误的准确位置并给出详细的诊断信息。

能作为Microsoft Visual C++的一个插件运行。

16. 16. Compuware DevPartner for Visual C++ BoundsChecker Suite－为C++开发者设计的运行错误检测和调试工具软件。

作为Microsoft Visual Studio和C++ 6.0的一个插件运行。

17. 17. Electric Software GlowCode－包括内存泄漏检查，code profiler，函数调用跟踪等功能。

给C++和.Net开发者提供完整的错误诊断，和运行时性能分析工具包。

18. 18. Compuware DevPartner Java Edition－包含Java内存检测,代码覆盖率测试,代码性能测试,线程死锁,分布式应用等几大功能模块。

19. 19. Quest JProbe－分析Java的内存泄漏。

20. 20. ej-technologies JProfiler－一个全功能的Java剖析工具，专用于分析J2SE和J2EE应用程序。

它把CPU、执行绪和内存的剖析组合在一个强大的应用中。

JProfiler可提供许多IDE整合和应用服务器整合用途。

JProfiler直觉式的GUI让你可以找到效能瓶颈、抓出内存泄漏、并解决执行绪的问题。

4.3.2注册码：A-G666#76114F-1olm9mv1i5uuly#0126 21. 21. BEA JRockit－用来诊断Java内存泄漏并指出根本原因，专门针对Intel平台并得到优化，能在Intel硬件上获得最高的性能。

22. 22. SciTech Software AB .NET Memory Profiler－找到内存泄漏并优化内存使用针对C#，VB.Net，或其它.Net程序。

23. 23. YourKit .NET & Java Profiler－业界领先的Java和.NET程序性能分析工具。

24. 24. AutomatedQA AQTime－AutomatedQA的获奖产品performance profiling和memory debugging工具集的下一代替换产品，支持Microsoft, Borland, Intel, Compaq 和 GNU编译器。

可以为.NET和Windows程序生成全面细致的报告，从而帮助您轻松隔离并排除代码中含有的性能问题和内存/资源泄露问题。

支持.Net 1.0,1.1,2.0,3.0和Windows 32/64位应用程序。

25. 25. JavaScript Memory Leak Detector－微软全球产品开发欧洲团队(Global Product Development- Europe team, GPDE) 发布的一款调试工具，用来探测JavaScript代码中的内存泄漏，运行为IE系列的一个插件。

FreeEIM 飞鸽传书怎么用？

FreeEIM 不同于传统的C/S 模式（Client/Server 结构）的软件，它采用最新的LanIPB 技术，程序可自动查找并获取其他用户的信息，同时显示到‘在线用户’列表中，因此无需配置服务器来支持，使软件的运用更简便。

FreeEIM 在使用过程中，数据输入之后，程序会先进行加密压缩，再进行传输。

对方收到消息后，程序会进行解密解压，才能获取信息。

另外，FreeEIM 与外部因特网彻底隔离，任何数据都无法通过FreeEIM 传输到局域网以外的电脑上。

使用过程中，无需担心信息的泄漏，或窃取，具有高度的信息保密性。

FreeEIM 已发布过许多版本，2.0 以前出现的Bug 已被修复。

在发布2.0之前，我们已做过严密的测试，不存在内存泄漏的问题，程序在连续运行的两个月中，一直处于稳定状态，并且通过 BoundsChecker 的测试。

减少出错，提高工作效率，为您的企业提供稳定的通讯平台。

使用 FreeEIM，你可以轻松地给一个或多个同事发送消息，并且支持多颜色显示，使文字沟通更新颖更实用；同时，当同事需要你的文件时，你可以轻轻松松把文件拖到对话框，就可以发送给他。

当你有重要的事，用文字表达不清楚的时候，你就可以启动语音对话，进行更具体，更高效的沟通（语音通讯采用无压缩，高清晰 44100Hz 取样频率，达到数字音频最完美质量)。

界面清晰，操作简便是 FreeEIM 的设计重点之一，采用Win 32 GDI 标准控件，具有系统主题的特性。

友好的界面让你使用起来更舒适，更简单。

FreeEIM 飞鸽传书： /

如何定位导致Crash的代码位置

1. 在开发环境下定位Crash错误 　　1.1 普通的crash 　　　　先来看看最普通的crash 　　　　参见图1(c01.png) 　　　　当你在debug模式下运行上面的程序就会弹出上面的框。

vc就帮你定位到了错误的位置。

是个对零指针的操作。

非常简单，不是吗。

　　1.2 较难定位的crash 　　　　较难定位的crash往往是由于内存错误(参见5.1 为什么程序crash时调用堆栈是乱的)。

例如以下代码： 代码 　　　　char *p = new char[16]; 　　　　p[10] = 0xfd; 　　　　delete[] p; 　　　　printf(p); 　　　　以上代码有两处错误，一是第2行的内存写越界，二是第4行使用被删除的指针。

　　　　但以上代码在vc的release和debug下都不会报错。

这使得这类错误很难定位。

　　　　检测这一类问题可以使用BoundsChecker工具的FinalCheck模式（BoundsChecker） 　　　　用BoundsChecker检测后可得到两个错误：Write overrun(写越界) 和 Dangling pointer(使用被删除的指针)而且都精确定位到了出错的位置。

是个不错的工具。

　　　　参见图2(c02.png) 　　　　参见图3(c03.png) 　　1.3 注意vc的输出日志 　　　　由于一些目前未知的原因（有可能是程序的错误太严重或是BoundsChecker本身的bug），BoundsChekcer有时不能正常工作。

　　　　这里vc的输出日志有时能提供一些有用的信息。

　　　　在难找的crash中，有很大一部分是引用了非法的指针。

　　　　有时在vc的输出日志里可以看到类似于这样的信息 　　　　“emule.exe 中的 0x004277b7 处最可能的异常: 0xC0000005: 读取位置 0xfeeeff62 时发生访问冲突 。

” 　　　　在缺少BoundsChecker的支持时，这是一条很重要的信息。

意思是说在“程序地址0x004277b7处”对“值为0xfeeeff62的指针”进行操作。

　　　　（怎么通过“程序地址0x004277b7”找到对应的代码行可参照 3.1，） 　　　　这条信息的重要性在于，这个操作只会触发一个警告，而不会导致crash，当crash真正发生时，很有可能不会在0x004277b7附近， 　　　　甚至调用堆栈都已经被写乱，让你无从下手。

（参见5.1 为什么程序crash时调用堆栈是乱的） 2. 定位发布在外的版本的Crash错误 　　发布在外的软件crash了，往往不好调试，所以目前很多软件都有“发送错误报告”这一功能。

　　实现这一功能一般分以下几步： 　　a. 使用SetUnhandledExceptionFilter函数 　　　　使用SetUnhandledExceptionFilter设置最高一级的异常处理函数，当程序出现任何未处理的异常，都会触发你设置的函数里。

具体使用可参照msdn和emule源码。

　　b. 使用MiniDumpWriteDump函数 　　　　在你的异常处理函数里，使用MiniDumpWriteDump把错误信息存成特定格式的文件。

具体使用可参照msdn和emule源码。

　　c. 发送错误报告 　　　　选用一种形式把第二步产生的错误报告(.dmp)文件发送给你指定的地方。

　　d. 查看错误报告 　　　　这里介绍用vc查看错误报告的方法，还可以用windows debug tools这个工具看，方法见5.2 使用windows debug tools查看.dmp文件(错误报告) 　　　　查看错误报告需要有三样东西：对应release版的代码，当时编译release版所产生的.exe和.pdb文件。

（这两个文件都在编译的输出目录里。

）所以当程序发布时，要保留下这两个文件。

　　　　把.dmp（错误报告文件）, .pdb, .exe. 代码，在同一目录下，用vc打开.dmp 文件。

　　　　按F5运行，程序即到达crash时的状态，可以对其进行相应的分析。

　　一点补充：当没有“发送错误报告”的功能，或是此功能失效，以致弹出了windows的“发送错误报告”的对话框。

这时其实也是有错误报告的，一般在C:Documents and Settings用户名Local SettingsTemp里的一个.dmp文件(一般只有一个.dmp) 3. 小技巧 　　3.1 根据程序地址找到代码位置 　　　　可按如下步骤： 　　　　a. 使程序处于停止状态。

（比如程序运行时，在vc里按Ctrl+Alt+Break，或设断点使程序停下） 　　　　b. 切换到汇编状态。

（Ctrl+F11） 　　　　c. 在地址栏输入程序地址，回车。

　　　　d. 可按Ctrl+F11切回代码模式。

　　3.2 根据消息值查看对应的windows消息 　　　　在vc的监视窗口里输入“消息值,wm”即可看到对应的消息。

　　3.3 查看GetLastError返回值 　　　　在vc的监视窗口里输入“@err,hr”，即可看到LastError及其解释。

　　3.4 在代码中暂停程序 　　　　在debug版中可以在代码中加上“AfxDebugBreak()；”以暂停程序。

release版可使用 “_asm int 3;” 4. 编程小警示 　　4.1 慎用IsBadPtr系列函数 　　　　当使用IsBadReadPtr, IsBadWritePtr, IsBadCodePtr一系列函数时要注意，这一类函数可能并不能达到你所想要的意图。

　　　　比如下面的代码，两个返回都是false。

代码 char *p = new char[10]; bool b; b = IsBadReadPtr(p+10, 1); delete[] p; char *q = new char[10]; b = IsBadReadPtr(p, 1); 　　　　所以切忌在程序中以IsBadPtr函数来判断是否可以对这个指针进行操作。

这些函数只能在调试中使用，或是你确切的知道这些函数的返回值表示的是什么意义的时候。

　　4.2 慎用catch(...) 　　　　为了防止程序crash或是解决一个不明白的crash时，大家很容易想到一个 try{}catch(...){}来解决问题。

　　　　的确大部分时间这样不会出问题了，但这个try-catch很有可能隐藏掉在try里面的错误，而当由此错误引起其他错误时，就很难追踪到这个问题了。

　　　　所以建议尽量少用catch(...)，如果知道某一块代码会抛出异常，应该用确切的写法。

比如catch(CFileException *e), catch(int e)等等。

5. 附录 　　5.1 为什么程序crash时调用堆栈是乱的 　　　　当内存被写乱时程序很有可能出现很难定位的crash，比如调用堆栈是乱的，或走到不存在的代码里。

这里举一例 代码 class CA { public: CA(){} ~CA(){} virtual f(){} }; void show() { printf("shown"); } int main() { // 对像被创建删除 CA *p = new CA; delete p; // 一些正常的操作 int *q = new int; int codeAddress = (int)show; *q = (int)&codeAddress; // 调用被删除的对像，程序有可能执行到任何地方。

p->f(); } 　　　　上面代码的结果会走到show()里显示出show（这跟编译环境有关，vc2003下测试结果是这样）。

如果你了解c++的vtable机制就明白这是怎么回事。

　　　　如果不明白也没关系，我下面说个大概。

　　　　首先CA对象被创建又被删除。

如果此时调用p->f()多半会crash。

　　　　第二块代码可视为一些正常的操作，new了一个q，然后对它进行了一些赋值。

　　　　如果你不明白vtable机制，那你只要知道，最后一行的 “p->f();”会执行变量q所指向的变量所指向的变量所标示的地址。

（这里没打错字，是两个“所指向的变量”） 　　　　这里我“心地善良”的给这个值赋上了一个合法的函数地址show。

但实际程序中q所指向的变量有可能是任意值，它再指向的变量就更是任意值了。

　　　　那程序就不知道跑哪里去了。

如果这个值过于离谱，那算你运气好，程序会立即crash，而你就知道错误位置在哪了。

但讨人厌的是，它有可能是一个合法地址，那程序就继续走下去， 　　　　但迟早会crash，并且调用堆栈面目全非（原因牵涉到“调用堆栈的推导”的问题这里就不多说了）， 　　　　到时就根本无从知道原来是调用了被删除的p对象而导致的。

　　5.2 使用Debugging tools for windows查看.dmp文件(错误报告) 　　　　a. 准备好程序对应的代码，exe文件，pdb文件（编译时在编译输出目录里） 　　　　b. 安装WinDbg 　　　　c. 在winDbg里把Symbol目录设在.pdb所在目录，Image目录设在.exe所在目录，code目录设到代码目录。

　　　　d. 打开.dmp文件 　　　　e. 输入命令.ecxr。

（此命令使环境回到崩溃时的状态） 　　　　f. 打开调用堆栈(ALT + F6)查看Crash的位置 　　　　g. 进行分析 简介 　　（FinalCheck能检测出的错误列表见附录1） 　　BoundsChecker是一个很强大的调试工具。

这里只简单介绍如何用它的FinalCheck模式定位比较难定位的错误。

FinalCheck模式简单来说就是BoundsChecker在你的代码里加一些诊断代码来检查平时比较难查出的内存越界，错误的指针使用等。

不过付出的代价就是程序跑起来会比较慢，所以在不用时最好是把FinalCheck模式关掉。

特别是发布前。

有boundschecker for vs2008吗，该怎么处理

1.你需要安装 Intel Visual Fortran 编译器，并集成到 Visual Studio 中。

后者自身不具备 Fortran 编译器。

2.文件，新建，工程。

选择 Intel Fortran 的工程。

（console或其他，根据自身需求） 3.添加 test.for 文件到新建好的工程内。

4.编译，链接。

运行