vc调试

最新推荐文章于 2021-05-20 06:47:03 发布

xiaoxixi1020

最新推荐文章于 2021-05-20 06:47:03 发布

阅读量486

点赞数

文章标签： microsoft database 工具 output numbers 编译器

难怪很多前辈说调试是一个程序员最基本的技能，其重要性甚至超过学习一门语言。不会调试的程序员就意味着他即使会一门语言，却不能编制出任何好的软件。

我以前接触的程序大多是有比较成形的思路和方法，调试起来出的问题都比较小，最近这个是我自己慢慢摸索调试，接触了很多新的调试方法，并查了很多前辈的总结，受益匪浅，总结以前的和新的收获如下：

VC调试篇

设置
为了调试一个程序，首先必须使程序中包含调试信息。一般情况下，一个从 AppWizard 创建的工程中包含的 Debug Configuration 自动包含调试信息，但是是不是 Debug 版本并不是程序包含调试信息的决定因素，程序设计者可以在任意的 Configuration 中增加调试信息，包括 Release 版本。
为了增加调试信息，可以按照下述步骤进行：

打开 Project settings 对话框（可以通过快捷键 ALT+F7 打开，也可以通过 IDE 菜单 Project/Settings 打开 )
选择 C/C++ 页， Category 中选择 general ，则出现一个 Debug Info 下拉列表框，可供选择的调试信息方式包括：

命令行	Project settings	说明
无	None	没有调试信息
/Zd	Line Numbers Only	目标文件或者可执行文件中只包含全局和导出符号以及代码行信息，不包含符号调试信息
/Z7	C 7.0- Compatible	目标文件或者可执行文件中包含行号和所有符号调试信息，包括变量名及类型，函数及原型等
/Zi	Program Database	创建一个程序库 (PDB) ，包括类型信息和符号调试信息。
/ZI	Program Database for Edit and Continue	除了前面 /Zi 的功能外，这个选项允许对代码进行调试过程中的修改和继续执行。这个选项同时使 #pragma 设置的优化功能无效

选择 Link 页，选中复选框 "Generate Debug Info" ，这个选项将使连接器把调试信息写进可执行文件和 DLL
如果 C/C++ 页中设置了 Program Database 以上的选项，则 Link incrementally 可以选择。选中这个选项，将使程序可以在上一次编译的基础上被编译（即增量编译），而不必每次都从头开始编译。

调试方法：

1 、使用 Assert （原则：尽量简单）　 assert 只在 debug 下生效， release 下不会被编译。

2 、防御性的编程

3 、使用 Trace
4 、用 GetLastError 来检测返回值，通过得到错误代码来分析错误原因
5 、把错误信息记录到文件中

位置断点（ Location Breakpoint ）
大家最常用的断点是普通的位置断点，在源程序的某一行按 F9 就设置了一个位置断点。但对于很多问题，这种朴素的断点作用有限。譬如下面这段代码：

void CForDebugDlg::OnOK()

{

for (int i = 0; i < 1000; i++) //A

{

int k = i * 10 - 2; //B

SendTo(k); //C

int tmp = DoSome(i); //D

int j = i / tmp; //E

}

   执行此函数，程序崩溃于 E 行，发现此时 tmp 为 0 ，假设 tmp 本不应该为 0 ，怎么这个时候为 0 呢？所以最好能够跟踪此次循环时 DoSome 函数是如何运行的，但由于是在循环体内，如果在 E 行设置断点，可能需要按 F5 （ GO ）许多次。这样手要不停的按，很痛苦。使用 VC6 断点修饰条件就可以轻易解决此问题。步骤如下。
  1 Ctrl+B 打开断点设置框，如下图：

Figure 1 设置高级位置断点
  2 然后选择 D 行所在的断点，然后点击 condition 按钮，在弹出对话框的最下面一个编辑框中输入一个很大数目，具体视应用而定，这里 1000 就够了。
  3 按 F5 重新运行程序，程序中断。 Ctrl+B 打开断点框，发现此断点后跟随一串说明： ...487 times remaining 。意思是还剩下 487 次没有执行，那就是说执行到 513 （ 1000 － 487 ）次时候出错的。因此，我们按步骤 2 所讲，更改此断点的 skip 次数 , 将 1000 改为 513 。
  4 再次重新运行程序，程序执行了 513 次循环，然后自动停在断点处。这时，我们就可以仔细查看 DoSome 是如何返回 0 的。这样，你就避免了手指的痛苦，节省了时间。
   再看位置断点其他修饰条件。如 Figure 1 所示，在 “Enter the expression to be evaluated:” 下面，可以输入一些条件，当这些条件满足时，断点才启动。譬如，刚才的程序，我们需要 i 为 100 时程序停下来，我们就可以输入在编辑框中输入 “i==100” 。
   另外，如果在此编辑框中如果只输入变量名称，则变量发生改变时，断点才会启动。这对检测一个变量何时被修改很方便，特别对一些大程序。
   用好位置断点的修饰条件，可以大大方便解决某些问题。

数据断点（ Data Breakpoint ）
软件调试过程中，有时会发现一些数据会莫名其妙的被修改掉（如一些数组的越界写导致覆盖了另外的变量），找出何处代码导致这块内存被更改是一件棘手的事情（如果没有调试器的帮助）。恰当运用数据断点可以快速帮你定位何时何处这个数据被修改。譬如下面一段程序：

#include "stdafx.h"

#include

int main(int argc, char* argv[])

{

char szName1[10];

char szName2[4];

strcpy(szName1,"shenzhen");

printf("%s/n", szName1); //A

strcpy(szName2, "vckbase"); //B

printf("%s/n", szName1);

printf("%s/n", szName2);

return 0;

}

这段程序的输出是

szName1: shenzhen

szName1: ase

szName2: vckbase

     szName1 何时被修改呢？因为没有明显的修改 szName1 代码。我们可以首先在 A 行设置普通断点， F5 运行程序，程序停在 A 行。然后我们再设置一个数据断点。如下图：

Figure 2 数据断点
  F5 继续运行，程序停在 B 行，说明 B 处代码修改了 szName1 。 B 处明明没有修改 szName1 呀？但调试器指明是这一行，一般不会错，所以还是静下心来看看程序，哦，你发现了： szName2 只有 4 个字节，而 strcpy 了 7 个字节，所以覆写了 szName1 。
   数据断点不只是对变量改变有效，还可以设置变量是否等于某个值。譬如，你可以将 Figure 2 中红圈处改为条件 ”szName2[0]==''''y''''“, 那么当 szName2 第一个字符为 y 时断点就会启动。
   可以看出，数据断点相对位置断点一个很大的区别是不用明确指明在哪一行代码设置断点。

其他调试手段：系统提供一系列特殊的函数或者宏来处理Debug 版本相关的信息，如下：

宏名/ 函数名	说明
TRACE	使用方法和printf 完全一致，他在output 框中输出调试信息
ASSERT	它接收一个表达式，如果这个表达式为TRUE ，则无动作，否则中断当前程序执行。对于系统中出现这个宏导致的中断，应该认为你的函数调用未能满足系统的调用此函数的前提条件。例如，对于一个还没有创建的窗口调用SetWindowText 等。
VERIFY	和ASSERT 功能类似，所不同的是，在Release 版本中，ASSERT 不计算输入的表达式的值，而VERIFY 计算表达式的值。

值
Watch
VC 支持查看变量、表达式和内存的值。所有这些观察都必须是在断点中断的情况下进行。
观看变量的值最简单，当断点到达时，把光标移动到这个变量上，停留一会就可以看到变量的值。
VC 提供一种被成为 Watch 的机制来观看变量和表达式的值。在断点状态下，在变量上单击右键，选择 Quick Watch ，就弹出一个对话框，显示这个变量的值。
单击 Debug 工具条上的 Watch 按钮，就出现一个 Watch 视图（ Watch1,Watch2,Watch3,Watch4 ），在该视图中输入变量或者表达式，就可以观察变量或者表达式的值。注意：这个表达式不能有副作用，例如 ++ 运算符绝对禁止用于这个表达式中，因为这个运算符将修改变量的值，导致软件的逻辑被破坏。
Memory
由于指针指向的数组， Watch 只能显示第一个元素的值。为了显示数组的后续内容，或者要显示一片内存的内容，可以使用 memory 功能。在 Debug 工具条上点 memory 按钮，就弹出一个对话框，在其中输入地址，就可以显示该地址指向的内存的内容。
Varibles
Debug 工具条上的 Varibles 按钮弹出一个框，显示所有当前执行上下文中可见的变量的值。特别是当前指令涉及的变量，以红色显示。
寄存器
Debug 工具条上的 Reigsters 按钮弹出一个框，显示当前的所有寄存器的值。

调试技巧 ：

1 、VC++ 中F5 进行调试运行

a) 、在output Debug 窗口中可以看到用TRACE 打印的信息

b) 、 Call Stack 窗口中能看到程序的调用堆栈

2 、当Debug 版本运行时发生崩溃，选择retry 进行调试，通过看Call Stack 分析出错的位置及原因

3 、使用映射文件调试

a) 、创建映射文件：Project settings 中link 项，选中Generate mapfile ，输出程序代码地址：/MAPINFO: LINES ，得到引出序号：/MAPINFO: EXPORTS 。

b) 、程序发布时，应该把所有模块的映射文件都存档。

c) 、查看映射文件：见” 通过崩溃地址找出源代码的出错行”文件。

4 、可以调试的Release 版本

　　Project settings 中C++ 项的Debug Info 选择为Program Database ，Link 项的Debug 中选择Debug Info 和Microsoft format 。

5 、查看API 的错误码，在watch 窗口输入@err 可以查看或者@err,hr ，其中”,hr ”表示错误码的说明。

6 、Set Next Statement ：该功能可以直接跳转到指定的代码行执行，一般用来测试异常处理的代码。

7 、调试内存变量的变化：当内存发生变化时停下来。？？？

进程控制
VC 允许被中断的程序继续运行、单步运行和运行到指定光标处，分别对应快捷键 F5 、 F10/F11 和 CTRL+F10 。各个快捷键功能如下：
　

快捷键	说明
F5	调试 / 继续运行
F10	单步，如果涉及到子函数，不进入子函数内部
F11	单步，如果涉及到子函数，进入子函数内部
CTRL+F10	运行到当前光标处。
F7	重建
F9	设置断点 / 清除断点
Ctrl+Shift+F9	清除所有断点
Shift+F5	结束调试

Call Stack
调用堆栈反映了当前断点处函数是被那些函数按照什么顺序调用的。单击 Debug 工具条上的 Call stack 就显示 Call Stack 对话框。在 CallStack 对话框中显示了一个调用系列，最上面的是当前函数，往下依次是调用函数的上级函数。单击这些函数名可以跳到对应的函数中去。

关注
一个好的程序员不应该把所有的判断交给编译器和调试器，应该在程序中自己加以程序保护和错误定位，具体措施包括：

对于所有有返回值的函数，都应该检查返回值，除非你确信这个函数调用绝对不会出错，或者不关心它是否出错。
一些函数返回错误，需要用其他函数获得错误的具体信息。例如 accept 返回 INVALID_SOCKET 表示 accept 失败，为了查明具体的失败原因，应该立刻用 WSAGetLastError 获得错误码，并针对性的解决问题。
有些函数通过异常机制抛出错误，应该用 TRY-CATCH 语句来检查错误
程序员对于能处理的错误，应该自己在底层处理，对于不能处理的，应该报告给用户让他们决定怎么处理。如果程序出了异常，却不对返回值和其他机制返回的错误信息进行判断，只能是加大了找错误的难度。

另外： VC 中要编制程序不应该一开始就写 cpp/h 文件，而应该首先创建一个合适的工程。因为只有这样， VC 才能选择合适的编译、连接选项。对于加入到工程中的 cpp 文件，应该检查是否在第一行显式的包含 stdafx.h 头文件，这是 Microsoft Visual Studio 为了加快编译速度而设置的预编译头文件。在这个 #include "stdafx.h" 行前面的所有代码将被忽略，所以其他头文件应该在这一行后面被包含。
对于 .c 文件，由于不能包含 stdafx.h ，因此可以通过 Project settings 把它的预编译头设置为 “ 不使用 ” ，方法是：