程序调试技巧之调用堆栈

调试技巧之调用堆栈

在计算机科学中，Callstack是指存放某个程序的正在运行的函数的信息的栈。Call stack由stack frames组成，每个stack frame对应于一个未完成运行的函数。

在当今流行的计算机体系架构中，大部分计算机的参数传递，局部变量的分配和释放都是通过操纵程序栈来实现的。栈用来传递函数参数，存储返回值信息，保存寄存器以供恢复调用前处理机状态。每次调用一个函数，都要为该次调用的函数实例分配栈空间。为单个函数分配的那部分栈空间就叫做stack frame，也就是说，stack frame这个说法主要是为了描述函数调用关系的。

Stackframe组织方式的重要性和作用体现在两个方面：第一，它使调用者和被调用者达成某种约定。这个约定定义了函数调用时函数参数的传递方式，函数返回值的返回方式，寄存器如何在调用者和被调用者之间进行共享；第二，它定义了被调用者如何使用它自己的stack frame来完成局部变量的存储和使用。

简单介绍

调试是程序开发者必备技巧。如果不会调试，自己写的程序一旦出问题，往往无从下手。本人总结10年使用VC经验，对调试技巧做一个粗浅的介绍。希望对大家有所帮助。

今天简单的介绍介绍调用堆栈。调用堆栈在我的专栏的文章VC调试入门提了一下，但是没有详细介绍。

首先介绍一下什么叫调用堆栈：假设我们有几个函数，分别是function1,function2,function3,funtion4，且function1调用function2，function2调用function3，function3调用function4。在function4运行过程中，我们可以从线程当前堆栈中了解到调用他的那几个函数分别是谁。把函数的顺序关系看，function4、function3、function2、function1呈现出一种“堆栈”的特征，最后被调用的函数出现在最上方。因此称呼这种关系为调用堆栈(callstack)。

当故障发生时，如果程序被中断，我们基本上只可以看到最后出错的函数。利用call stack，我们可以知道当出错函数被谁调用的时候出错。这样一层层的看上去，有时可以猜测出错误的原因。常见的这种中断时ASSERT宏导致的中断。

在程序被中断时，debug工具条的右侧倒数第二个按钮一般是callstack按钮，这个按钮被按下后，你就可以看到当前的调用堆栈。

实例一：介绍

我们首先演示一下调用堆栈。首先我们创建一个名为Debug的对话框工程。工程创建好以后，双击OK按钮创建消息映射函数，并添加如下代码：

void CDebugDlg::OnOK()

{

//TODO:Add extravalidation here

ASSERT(FALSE);

}

我们按F5开始调试程序。程序运行后，点击OK按钮，程序就会被中断。这时查看call stack窗口，就会发现内容如下：

CDebugDlg::OnOK()line176+34bytes

_AfxDispatchCmdMsg(CCmdTarget*0x0012fe74{CDebugDlg},unsigned int1,int0, void(void)*0x5f402a00`vcall'(void),void*0x00000000,unsigned int12, AFX_CMDHANDLERINFO*0x00000000)line88

CCmdTarget::OnCmdMsg(unsigned int1,int0,void*0x00000000, AFX_CMDHANDLERINFO*0x00000000)line302+39bytes

CDialog::OnCmdMsg(unsignedint1,int0,void*0x00000000,AFX_CMDHANDLERINFO *0x00000000)line97+24bytes

CWnd::OnCommand(unsignedint1,long656988)line2088

CWnd::OnWndMsg(unsignedint273,unsigned int1,long656988,long*0x0012f83c) line1597+28bytes

CWnd::WindowProc(unsignedint273,unsigned int1,long656988)line1585+30 bytes

AfxCallWndProc(CWnd*0x0012fe74{CDebugDlg hWnd=???},HWND__*0x001204b0, unsigned int273,unsigned int1,long656988)line215+26bytes AfxWndProc(HWND__*0x001204b0,unsigned int273,unsigned int1,long656988) line368

AfxWndProcBase(HWND__*0x001204b0,unsigned int273,unsigned int1,long

656988)line220+21bytes

USER32!77d48709()

USER32!77d487eb()

USER32!77d4b368()

USER32!77d4b3b4()

NTDLL!7c90eae3()

USER32!77d4b7ab()

USER32!77d7fc9d()

USER32!77d76530()

USER32!77d58386()

USER32!77d5887a()

USER32!77d48709()

USER32!77d487eb()

USER32!77d489a5()

USER32!77d489e8()

USER32!77d6e819()

USER32!77d65ce2()

CWnd::IsDialogMessageA(tagMSG*0x004167d8{msg=0x00000202wp=0x00000000 lp=0x000f001c})line182

CWnd::PreTranslateInput(tagMSG*0x004167d8{msg=0x00000202wp=0x00000000 lp=0x000f001c})line3424

CDialog::PreTranslateMessage(tagMSG*0x004167d8{msg=0x00000202 wp=0x00000000lp=0x000f001c})line92

CWnd::WalkPreTranslateTree(HWND__*0x001204b0,tagMSG*0x004167d8 {msg=0x00000202wp=0x00000000lp=0x000f001c})line2667+18bytes CWinThread::PreTranslateMessage(tagMSG*0x004167d8{msg=0x00000202 wp=0x00000000lp=0x000f001c})line665+18bytes

CWinThread::PumpMessage()line841+30bytes

CWnd::RunModalLoop(unsignedlong4)line3478+19bytes

CDialog::DoModal()line536+12bytes

CDebugApp::InitInstance()line59+8bytes

AfxWinMain(HINSTANCE__*0x00400000,HINSTANCE__*0x00000000,char* 0x00141f00,int1)line39+11bytes

WinMain(HINSTANCE__*0x00400000,HINSTANCE__*0x00000000,char*0x00141f00, int1)line30

WinMainCRTStartup()line330+54bytes

KERNEL32!7c816d4f()

这里，CDebugDialog::OnOK作为整个调用链中最后被调用的函数出现在callstack的最上方，而内核中程序的启动函数Kernel32!7c816d4f()则作为栈底出现在最下方。

实例二：学习处理方法

微软提供了MDI/SDI模型提供文档处理的建议结构。有些时候，大家希望控制某个环节。例如，我们希望弹出自己的打开文件对话框，但是并不想自己实现整个文档的打开过程，而更愿意MFC完成其他部分的工作。可是，我们并不清楚MFC是怎么处理文档的，也不清楚如何插入自定义代码。

幸运的是，我们知道当一个文档被打开以后，系统会调用CDocument派生类的Serialize 函数，我们可以利用这一点来跟踪MFC的处理过程。

我们首先创建一个缺省的SDI工程Test1，并在CTest1Doc::Serialize函数的开头增加一个断点，运行程序，并打开一个文件。这时，我们可以看到调用堆栈是(我只截取了感兴趣的一段)：

CTest1Doc::Serialize(CArchive&{...})line66

CDocument::OnOpenDocument(constchar*0x0012f54c)line714

CSingleDocTemplate::OpenDocumentFile(constchar*0x0012f54c,int1)line168 +15bytes

CDocManager::OpenDocumentFile(constchar*0x0042241c)line953

CWinApp::OpenDocumentFile(constchar*0x0042241c)line93

CDocManager::OnFileOpen()line841

CWinApp::OnFileOpen()line37

_AfxDispatchCmdMsg(CCmdTarget*0x004177f0class CTest1App theApp,unsigned int 57601,int0,void(void)*0x00402898CWinApp::OnFileOpen,void*0x00000000, unsigned int12,AFX_CMDHANDLERINFO*0x00000000)line88

CCmdTarget::OnCmdMsg(unsignedint57601,int0,void*0x00000000, AFX_CMDHANDLERINFO*0x00000000)line302+39bytes

CFrameWnd::OnCmdMsg(unsignedint57601,int0,void*0x00000000, AFX_CMDHANDLERINFO*0x00000000)line899+33bytes

CWnd::OnCommand(unsignedint57601,long132158)line2088

CFrameWnd::OnCommand(unsignedint57601,long132158)line317

从上面的调用堆栈看，这个过程由一个WM_COMMAND消息触发（因为我们用菜单打开文件)，由CWinApp::OnFileOpen最先开始实际处理过程，这个函数调用CDocManager::OnFileOpen打开文档。

我们首先双击CWinApp::OnFileOpen()line37打开CWinApp::OnFileOpen，它的处理过程是：

ASSERT(m_pDocManager!=NULL);

m_pDocManager->OnFileOpen();

m_pDocManager是一个CDocManager类的实例指针，我们双击CDocManager::OnFileOpen 行，看该函数的实现：

voidCDocManager::OnFileOpen()

{

//prompt the user(with all documenttemplates)

CString newName;

if(!DoPromptFileName(newName,AFX_IDS_OPENFILE,

OFN_HIDEREADONLY|OFN_FILEMUSTEXIST,TRUE,NULL))

return;//open cancelled

AfxGetApp()->OpenDocumentFile(newName);

//if returns NULL,the user has already beenalerted

}

很显然，该函数首先调用DoPromptFileName函数来获得一个文件名，然后在继续后续的打开过程。

顺这这个线索下去，我们一定能找到插入我们文件打开对话框的位置。由于这不是我们研究的重点，后续的分析我就不再详述。

实例三：内存访问越界

在Debug版本的VC程序中，程序会给每块new出来的内存，预留几个字节作为越界检测之用。在释放内存时，系统会检查这几个字节，判断是否有内存访问越界的可能。

我们借用前一个实例程序，在CTest1App::InitInstance的开头添加以下几行代码：char*p=new char[10];

memset(p,0,100);

delete[]p;

return FALSE;

很显然，这段代码申请了10字节内存，但是使用了100字节。我们在memset(p,0,100);这行加一个断点，然后执行程序，断点到达后，我们观察p指向的内存的值(利用Debug工具条的Memory功能)，可以发现它的值是：

CD CD CD CD CD CD CD CD

CD CD FD FD FD FD FD FD

0000000000000000

......

根据经验，p实际被分配了16个字节，后6个字节用于保护。我们按F5全速执行程序，会发现如下的错误信息被弹出：

Debug Error!

Program:c:\temp\test1\Debug\test1.exe

DAMAGE:after normal block(#55)at0x00421AB0

该信息提示，在正常内存块0x00421AB0后的内存被破坏（内存访问越界），我们点击Retry进入调试状态，发现调用堆栈是：

_free_dbg_lk(void*0x00421ab0,int1)line1033+60bytes

_free_dbg(void*0x00421ab0,int1)line970+13bytes

operator delete(void*0x00421ab0)line351+12bytes

CTest1App::InitInstance()line54+15bytes

很显然，这个错误是在调用delete时遇到的，出现在CTest1App::InitInstance()line 54+15bytes之处。我们很容易根据这个信息找到，是在释放哪块内存时出现问题，之后，我们只需要根据这个内存的访问过程确定哪儿出错，这将大大降低调试的难度。

实例四：子类化

子类化是我们修改一个现有控件实现新功能的常用方法，我们借用实例一中的Debug 对话框工程来演示我过去学习子类化的一个故事。我们创建一个缺省的名为Debug的对话框工程，并按照下列步骤进行实例化：

在对话框资源中增加一个Edit控件

用class wizard为CEdit派生一个类CMyEdit（由于今天不关心子类化的具体细节，因此这个类不作任何修改）

为Edit控件，增加一个控件类型变量m_edit，其类型为CMyEdit

在OnInitDialog中增加如下语句：

m_edit.SubclassDlgItem(IDC_EDIT1,this);

我们运行这个程序，会遇到这样的错误：

Debug AssertionFailed!

Application:C:\temp\Debug\Debug\Debug.exe

File:Wincore.cpp

Line:311

For information on howyour program can cause an assertion failure,see Visual C++documentation onasserts.

点击Retry进入调试状态，我们可以看到调用堆栈为：

CWnd::Attach(HWND__*0x000205a8)line311+28bytes

CWnd::SubclassWindow(HWND__*0x000205a8)line3845+12bytes

CWnd::SubclassDlgItem(unsignedint1000,CWnd*0x0012fe34{CDebugDlg hWnd=0x001d058a})line3883+12bytes

CDebugDlg::OnInitDialog()line120

可以看出在Attach句柄时出现问题，出问题行的代码为：

ASSERT(m_hWnd==NULL);

这说明我们在子类化时不应该绑定控件，我们删除CDebugDialog::DoDataExchange中的下面一行：

DDX_Control(pDX,IDC_EDIT1,m_edit);

问题就得到解决

总结

简而言之，call stack是调试中必须掌握的一个技术，但是程序员需要丰富的经验才能很好的掌握和使用它。你不仅仅需要熟知C++语法，还需要对相关的平台、软件设计思路有一定的了解。我的文章只能算一个粗浅的介绍，毕竟我在这方面也不算高手。希望对新进有一定的帮助。

调试之编程准备

对于一个程序员而言，学习一种语言和一种算法是非常容易的（不包括那些上学花很多时间玩，上班说学习没时间的人）。但是，任何程序都可能是有瑕疵的，尤其有过团队协作编程经验的人，对这个感触尤为深刻。

在我前面的述及调试的文章里，我侧重于VC集成环境中的一些设置信息和调试所需要的一些基本技巧。但是，仅仅知道这些是不够的。一个成功的调试的开端是编程中的准备。

分离错误

很多程序员喜欢写下面这样的式子：

CLeftView*pView=

((CFrameWnd*)AfxGetApp()->m_pMainWnd)->m_wndSplitterWnd.GetPane(0,0);

如果一切顺利，这样的式子当然是没什么问题。但是作为一个程序员，你应该时刻记得任何一个调用在某些特殊的情况下都可能失败，一旦上面某个式子失败，那么整个级联式就会出问题，而你很难弄清楚到底哪儿出错了。这样的式子的结果往往是：省了2分钟编码的时间，多了几星期的调试时间。

对于上面的式子，应该尽可能的把式子分解成独立的函数调用，这样我们可以随时确定是哪个函数调用出问题，进口缩小需要检查的范围。

检查返回值

检查返回值对于许多编程者来说似乎是一个很麻烦的事情。但是如果你能在每个可能出错的函数调用处都检查返回值，就可以立刻知道出错的函数。

有些人已经意识到检查返回值的重要性，但是要记住，只检查函数是否失败是不够的，我们需要知道函数失败的确切原因。例如下面的代码：

if(connect(sock,(const sockaddr*)&addr,sizeof(addr))==SOCKET_ERROR)

{

AfxMessageBox("connect failed");

}

尽管这里已经检查了返回值，实际上没有多少帮助。正如很多在vckbase上提问的人一样，大概这时候只能喊“为什么连接失败啊？”。这种情况下，其实只能猜测失败的原因，即使高手，也无法准确说出失败的原因。

增加诊断信息

在知道错误的情况下，应该尽可能的告诉测试、使用者更多的信息，这样才能了解导致失败的原因。如果程序员能提供如下错误信息，对于诊断错误是非常有帮助的：出错的文件：我们可以借助宏THIS_FILE和__FILE__。注意THIS_FILE是在cpp文件手工定义的，而__FILE__是编译器定义的。当记录错误的函数定义在.h中时，有时候用THIS_FILE更好，因为他能说明在哪个cpp中调用并导致失败的。

出错的行：我们可以借助宏__LINE__

出错的函数：如果设计的好，有以上两项已经足够。当然我们可以直接打印出出错的函数或者表达式，这样在大堆代码中搜索（尤其是不支持go to line的编辑器中）还是很有用的。

出错的原因：出错的原因很多只能由程序自己给出。如果出错只会问别人，那么你永远不可能成为一个合格的程序设计人员。很多函数失败时都会设置errno。我们可以用GetLastError获得错误码，并通过FormatMessage打印出具体错误的文字描述。