BUG，规范，断言和调试(3)

　　不要认为职业的程序员就不会犯这类错误。举几个例子来说明这些问题。

　　在IE4.0中，MSHTML的HTMLDocument对象的IPersistStreamInit::Load假定传入的IStream流的访问指针已经定位到开头——而在IE5.0中，IPersistStreamInit::Load会自行调用IStream::Seek

　　在Visual C++ 6.0中，CHTMLView类有字符串资源未释放问题(http://support.microsoft.com/kb/241750)

　　在Visual C++.Net中，CHTMLView类有两个BUG：

　　参数传递错误：

　　HRESULT CHtmlView::ExecFormsCommand(DWORD dwCommandID, VARIANT* pVarIn,

　　VARIANT* pVarOut)

　　...{

　　HRESULT hr = E_FAIL;

　　CComPtr spDoc = (IHTMLDocument2*) GetHtmlDocument();

　　if (spDoc != NULL)

　　...{

　　CComQIPtr spCmdTarget = spDoc;

　　if (spCmdTarget != NULL)

　　hr = spCmdTarget->Exec(&CMDSETID_Forms3, dwCommandID,

　　OLECMDEXECOPT_DONTPROMPTUSER, pVarOut, pVarIn);

　　}

　　return hr;

　　}

　　COM指针未释放错误：

　　void CHtmlView::OnFilePrint()

　　...{

　　// get the HTMLDocument

　　if (m_pBrowserApp != NULL)

　　...{

　　CComPtr spDisp = GetHtmlDocument();

　　if (spDisp != NULL)

　　...{

　　// the control will handle all printing UI

　　CComQIPtr spTarget = spDisp;

　　if (spTarget != NULL)

　　spTarget->Exec(NULL, OLECMDID_PRINT, 0, NULL, NULL);

　　}

　　}

　　}

　　这些不确定的行为是很大一部分不可重复(因此也很难跟踪)的BUG的根源。举例来说，释放一块内存之后，在操作系统切换到另外一个线程之前，重新分配同一块内存，并且写入数据这个事件发生的可能性十分之小。为了解决这些问题，Visual C++编译器采取了一种保护性的措施，在调试模式下再分配和释放内存时将内存用一般不会用到的值填充，例如0xccccccc,0xdddddddd和0xfefefefe(参见编译器文档中的/RTC参数的说明)。这样你可以减少不可预料的程序行为，强迫BUG重现。如果你的编译器没有这么做，你可以自己编写一个调试模式下专用的内存管理程序进行这样的工作。为什么选择这样的值?在Intel系统中，0xcc的含义是int 3中断(参见http://blogs.msdn.com/oldnewthing/archive/2004/11/11/255800.aspx)——如果不小心执行了这块数据，那么程序会马上中断并且提示用户，其他的值则是典型的非法数据。如果你在为其他环境编写程序。你可能需要查阅一些资料来决定使用什么值来在调试模式下填充内存。

　　MFC的另一个保护措施是内存泄漏监测器——这也是在每个文件开头要加上#define new DEBUG_NEW的原因——但是这也变更了应用程序的行为。举例来说，为了检查内存泄漏，MFC总是分配比所需要多的内存，然后加入调试信息。如果你的程序有访问越界的代码，那么有可能擦除一部分额外分配的内存，可能的结果就是在调试模式下运行正常，而在发布模式下程序崩溃。当然，这是必须的。如果你的发布版本的程序依赖于这些额外字节，那么你就有麻烦了。

　　在发布模式下程序的崩溃有助于你发现问题，但是也造成定位问题的困难。你可以在发布模式下加入调试信息(没错，在工程的C++和连接选项中选中Program Database和Generate Debug Info)来生成一个中间版本;MSDN文章Generating and Deploying Debug Symbols with Microsoft Visual C++ 6.0(http://msdn.microsoft.com/library/en-us/dnvc60/html/gendepdebug.asp)甚至教你怎么怎么发布这样的版本，但是也要注意这样的版本和最终发布版本还是可能有区别的——特别是在程序中有BUG的情况下。另一个办法是在调试时将EIP寄存器修改成崩溃信息中的值，这样可以很容易在源代码中定位造成崩溃的代码的位置(参见http://www.codeproject.com/debug/XCrashReportPt1.asp)。

　　MFC开发中另一个比较有用的定位内存访问越界方法是，将数据封装成对象成员变量，尽量可能让所有类都从CObject派生，并且在代码中大量加上ASSERT_VALID。如果成员变量被越界的访问重写了，那么CObject指向AssertValid的虚函数表会被改写，而ASSERT_VALID会报告这个错误。

　　不要发布调试版本，这对用户来说并无意义。虽然这么说可能是多此一举，但是我在玩游戏的时候还真看见过断言对话框。调试信息是被设计用来发现问题的，不是用来隐藏问题的。如果你确实需要这么做(微软就定期发布核心模块的调试信息以供软件开发人员定位问题)，那么你需要让用户认识到调试版本和最终发布版本的性能差异，例如在程序开始时显示一个消息。

　　最新Windows SDK不支持Visual C++ 6.0

　　可能大部分人已经知道了，但是CSDN论坛上仍旧不断出现关于这个兼容性的提问。最新的支持Visual C++ 6.0的版本是2003年2月版，下载地址是http://www.microsoft.com/msdownload/platformsdk/sdkupdate/psdk-full.htm。

　　取消对Visual C++ 6.0的支持的原因是为了支持新的/GS参数。XP SP2和Windows Server 2003 SP 1都增加了很多安全特性，以致于新的Windows SDK中包含的编译器和库文件不再和Visual C++ 6.0兼容。

原文转自：http://www.ltesting.net