文章目录
- 1. 什么是 bug
- 2. 什么是调试(debug)
- 3. Debug和 Release
- 4.VS调试快捷键
- 4.1 环境准备
- 4.2 调试快捷键
- 5. 监视和内存观察
- 5.1 监视
- 5.2 内存
- 6. 调试举例1
- 7. 调试举例2
- 9. 编程常见错误归类
- 9. 1 编译型错误
- 9.2 链接型错误
- 9. 3 运行时错误
本文章以VS2022为例讲解调试功能,不同的编译器可能会有所差异,但殊途同归,对其他编译器的使用也有一定的借鉴价值。
1. 什么是 bug
bug本意是“昆虫”或“虫子”,现在一般是指在电脑系统或程序中,隐藏着的一些未被发现的缺陷或问题,简称程序漏洞。
“Bug”的创始人格蕾丝·赫柏(GraceMurrayHopper),她是一位为美国海军工作的电脑专家,1947年9月9日,格蕾丝·赫柏对HarvardMarkl设置好17000个继电器进行编程后,技术人员正在进行整机运行时,它突然停止了工作。于是他们爬上去找原因,发现这台巨大的计算机内部一组继电器的触点之间有一只飞蛾,这显然是由于飞蛾受光和热的吸引,飞到了触点上,然后被高电压击死。所以在报告中,赫柏用胶条贴上飞蛾,并把“bug”来表示“一个在电脑程序里的错误,“Bug”这个说法一直沿用到今天。
(来自网络)
历史上第一个“Bug”。
2. 什么是调试(debug)
当我们发现程序中存在的问题的时候,那下一步就是找到问题,并修复问题。
这个找问题的过程叫称为调试,英文叫debug(消灭bug)的意思。
调试一个程序,首先是承认出现了问题,然后通过各种手段去定位问题的位置,可能是逐过程的调试,也可能是隔离和屏蔽代码的方式,找到问题所的位置,然后确定错误产生的原因,再修复代码重新测试。
3. Debug和 Release
在VS上编写代码的时候,就能看到有 debug
和 release
两个选项,分别是什么意思呢?
Debug
通常称为调试版本,它包含调试信息,并且不作任何优化,便于程序员调试程序。
程序员在写代码的时候,需要经常性的调试代码,就将这里设置为 debug
,这样编译产生的是debug
版本的可执行程序,其中包含调试信息,是可以直接调试的。
Release
称为发布版本,它往往是进行了各种优化,使得程序在代码大小和运行速度上都是最优的,以便用户很好地使用。当程序员写完代码,测试再对程序进行测试,直到程序的质量符合交付给用户使用的标准,这个时候就会设置为 release
,编译产生的就是 release
版本的可执行程序,这个版本是用户使用的,无需包含调试信息等。
对比可以看到从同一段代码,编译生成的可执行文件的大小,release
版本明显要小,而debug
版本明显大。
4.VS调试快捷键
那程序员怎么调试代码呢?
4.1 环境准备
首先是环境的准备,需要一个支持调试的开发环境,我们一般使用VS,应该把VS上设置为Debug
。
4.2 调试快捷键
调试最常使用的几个快捷键:
- F9:创建断点和取消断点
断点的作用是可以在程序的任意位置设置断点,打上断点就可以使得程序执行到想要的位置暂停执行,接下来我们就可以使用F10,F11这些快捷键,观察代码的执行细节。
断点也可以点击VS编辑取最左侧创建或取消。
条件断点:满足这个条件,才触发断点。
条件断点创建方法:
右键断点就可以创建条件断点,条件断点一般用于循环中,可以观察特定的某一次循环时代码的运行情况,节省时间。
- F5:启动调试,经常用来直接跳到下一个断点处,一般和F9配合使用。
F10:逐过程,通常用来处理一个过程,一个过程可以是一次函数调用,或者是一条语句。
F11:逐语句,就是每次都执行一条语句,但是这个快捷键可以使我们的执行逻辑进入函数内部。在函数调用的地方,想进入函数观察细节,必须使用F11,如果使用F10,直接完成函数调用。
(实际上F10和F11的区别只有是否能进入函数内部)
CTRL+F5:开始执行不调试,如果你想让程序直接运行起来而不调试就可以直接使用。
5. 监视和内存观察
在调试的过程中我们,如果要观察代码执行过程中,上下文环境中的变量的值,有哪些方法呢?
这些观察的前提条件一定是开始调试后观察,比如:
#include <stdio.h>
int main()
{
int arr[10] = { 0 };
int num = 100;
char c = 'w';
int i = 0;
for (i = 0; i < 10; i++)
arr[i] = i;
return 0;
}
5.1 监视
开始调试后,在菜单栏中【调试】->【窗口】->【监视】,打开任意一个监视窗口,输入想要观察的对象就行。
打开监视窗口:
(注意这里选择哪一个调试窗口都是一样的)
另外,如果你发现监视窗口中的文字特别小,可以按照这个步骤进行修改:
- 【工具】->【选项】
- 【环境】->【字体和颜色】->【显示其设置】->【监视窗口】->【调整大小】->【重启VS生效】
在监视窗口中观察:
提示:如果想要观察一个数组,如果此时数组名还可以指整个数组的话,可以直接输入数组名进行观察,如果不能(比如函数传参的数组或是动态开辟的数组),可以使用例如arr,10
的形式来观察arr及它之后10个相同元素的值。
另外,监视窗口还可以用来计算,例如5 + 7
或是i * j
,十分灵活。
此外,监视窗口可以显示数据的类型,不仅可以观察变量的,也可以观察函数的,例如:
int add(int a, int b)
{
return a + b;
}
#include <stdio.h>
int main()
{
int a = 10;
int b = 12;
int c = add(a, b);
printf("%d ", c);
return 0;
}
我们想知道 add
函数指针的类型(如果你不知道什么是函数指针,欢迎阅读我的C语言指针系列),就可以使用监视窗口直接观察:
5.2 内存
如果监视窗口看的不够仔细,也是可以观察变量在内存中的存储情况,调试起来后,在【调试】->【窗口】->【内存】打开内存窗口。
打开内存窗口:
在内存窗口中,观察数据:
在打开内存窗口后,在地址栏输入:arr
,&num
,&c
,这类地址,就能观察到该地址处的数据。
除此之外,在调试的窗口中还有:自动窗口,局部变量,反汇编、寄存器等窗口,可以自行使用一下,这里只介绍最常用的两个。
6. 调试举例1
求 1!+2!+3!+4!+...10!
的和,请看下面的代码:
//求出每个数的阶乘,再求和就好了
#include<stdio.h>
int main()
{
int sum = 0;
int ret = 1;
for (int n = 1; n <= 10; n++)
{
for (int i = 1; i <= n; i++)
ret *= i;
sum += ret;
}
printf("%d\n", sum);
return 0;
}
这个代码正确吗?我们运行一下看看结果:
就算你不知道正确答案是多少,也一定能一眼看出这个答案肯定是错的,那错在哪里了呢?干瞪眼很难找出bug所在,我们不妨调试起来看一看。
当n=2
并结束循环时,sum
中存储的是1!+2!
,结果是3,截至目前还是正确的,所以我们要继续调试。
这里就开始有问题了,可以看到,此时是n=3
也就是在求3!
,i=2
,所以现在ret
中存储的就是2!
,可以发现结果是错误的,所以说就是上一步出现了问题,我们重新开始调试,在这一步之前观察各个变量的值。
可能有些人会发现这个箭头指向了正在执行的语句,并且这个箭头可以拖动,但是请注意:拖动箭头只会改变下一步执行的语句,但代码的运行并不会执行或退回到箭头所指向的位置,所以,最好的办法是打一个(条件)断点,然后重新开始调试。
另外补充一点,箭头指向的语句是还没有执行的。
此时就是刚才我们发现ret
的错误的上一步,也就是在求3!
中即将求1!
的这一步,可以看到,按照我们的预想,ret
应该从1开始,但是现在竟然是2,问题出在哪里?
有了这个明确的方向,我们再来看代码,可以发现ret=1
这一步是写在了循环的外面,这就导致了每次循环开始时,ret
都是上一次阶乘求出的值,这也就是监视中ret=2
的由来,那么就可以进行debug了:
#include<stdio.h>
int main()
{
int sum = 0;
int ret = 1;
for (int n = 1; n <= 10; n++)
{
ret = 1;
for (int i = 1; i <= n; i++)
ret *= i;
sum += ret;
}
printf("%d\n", sum);
return 0;
}
这样修改之后,得到的答案就是正确的了:
这样就完成了一次完整的debug过程,当然,这个bug是在一个非常简单的代码中的一个简单的bug,所以可能你不需要经过这些步骤就能很快地定位到问题所在,但如果是一个很庞大的项目中出现的bug,标准的debug流程就显得十分重要了!
7. 调试举例2
在VS2022、X86、Debug 的环境下,编译器不做任何优化的话,下面代码执行的结果是什么?
#include <stdio.h>
int main()
{
int i = 0;
int arr[10] = { 1,2,3,4,5,6,7,8,9,10 };
for (i = 0; i <= 12; i++)
{
arr[i] = 0;
printf("hehe\n");
}
return 0;
}
很容易发现这个代码数组遍历越界了,正常情况下应该是程序崩溃,但结果真的如此吗?
我们运行起来看一看:
通过右边的很小的滑动条你应该就能发现:这个代码死循环了。
可是,为什么呢?
我们调试起来看一看:
调试到这一步,不知道你注意没有,此时i
和arr[i]
,也就是arr[12]
的地址竟然是一样的,那死循环就很好理解了,arr[12] = 0
,这一步将i
也赋值为0,循环无法达到结束条件,也就无法停止了。
可是,为什么i
会和arr[12]
重合呢?
我们知道局部变量是存储在栈区的,
- 栈区内存的使用习惯是从高地址向低地址使用的,所以变量
i
的地址是较大的。arr
数组的地址整体小于i
的地址。 - 数组在内存中的存放是:随着下标的增长,地址是由低到高变化的。
如图:
所以根据代码,就能理解为什么是上图的代码布局了。
如果是上图的内存布局,那随着数组下标i
的增长,往后越界就有可能覆盖到i
,这样就可能造成死循环的。
这里你可能还有疑问:为什么i
和arr
数组之间恰好空出来2个整型的空间呢?
这里确实是巧合,在不同的编译器下可能中间的空出的空间大小是不一样的,代码中这些变量内存的分配和地址分配是编译器指定的,所以的不同的编译器之间就有差异了。所以这个题目是和环境相关的,如果换一个环境,可能代码就不会死循环而是报错了。
从这个理解我们能够体会到调试的重要性,只有调试才能观察到程序内部执行的细节,就像医生给病人做B超,CT一样。
注意:栈区的默认的使用习惯是先使用高地址,再使用低地址的空间,但是这个具体还是要编译器的实现,
比如:在VS上切换到X64,这个使用的顺序就是相反的,在Release版本的程序中,这个使用的顺序也是相反的。
调试过程中,要做到心中有数,也就是程序员自己心里要清晰的知道希望代码怎么执行,然后再去看代码有没有按照我们预定的路线在执行。
调试是需要反复去动手练习的,调试是可以增加程序员对代码的理解和掌控的,掌握了调试的能力,就能看到本质,就像能给程序做B超一样,对程序内部一览无余。
9. 编程常见错误归类
9. 1 编译型错误
编译型错误一般都是语法错误,这类错误一般看错误信息就能找到一些蛛丝马迹的,双击错误信息也能初步的跳转到代码错误的地方或者附近。编译错误随着语言的熟练掌握,会越来越少,也容易解决。
9.2 链接型错误
看错误提示信息,主要在代码中找到错误信息中的标识符,然后定位问题所在。一般是因为:
标识符名不存在
拼写错误
头文件没包含
引用的库不存在
9. 3 运行时错误
也就是逻辑错误。
运行时错误,是千变万化的,需要借助调试,逐步定位问题,调试解决的是运行时错误。
谢谢你的阅读,喜欢的话来个点赞收藏评论关注吧!
我会持续更新更多优质文章