常用的调试手段
作为程序猿的我可太清楚调试的重要性了,有一句话说的很对:程序不是写出来的,是调出来的。调试的方法很多,比如朴实的日志打印,打点的计量统计(比如 golang 的 pprof 信息),还有无侵入式的单点调试。
在 c/c++ 我们最常用的是 gdb 调试,这是必备技能。在 golang 里面,我经常用的是 dlv 调试,用来分析程序的底层逻辑。奇伢的调试姿势通常有三种:
- 先 go build 编译,出二进制文件,然后用 dlv exec 来调试;
- 程序已经跑在测试环境,dlv attach 调试;
- 程序出 core 了,dlv core 调试;
个人还是挺习惯这种较为最原始的方式来调试程序。
避免依赖过重的工具?
IDE 提供了非常方便的调试功能,比如 goland 的调试功能,但 IDE 封装的过于严重,并且调试界面的实现各有不同,虽然提供了便捷,但是它对程序猿几乎相当于黑盒。一旦遇到点调试的问题,很难梳理清楚。并且当切换环境的时候经常要重新配置复杂的配置。
奇伢个人尽量强避免依赖这些 IDE 的特有的调试功能的,黑盒不透明是一个原因,第二个原因是类似 goland 这种商业付费的软件,License 经常过期,在换电脑或平台的时候,各种不同的付费策略导致这些软件使用很纠结。并且太过依赖它,却不知dlv 通用的调试技能,会导致工具的迁移成本过高。
那奇伢是一定要沉浸在终端调试的美梦中吗?
那不是,奇伢不排斥任何工具,只要你能完全掌控它即可。今天奇伢要分享一点关于 vscode 的调试姿势,个人觉得是比较适合我的预期的:
- 很透明,让用户有种掌控的感觉;
- 姿势通用,不会让你只能依赖于 vscode ,还是 dlv 的用法;
- 工具全平台可用,windows,mac,linux ,调试姿势完全一样;
vscode 只作为一个界面,还是最基本的 gdb 或者 dlv 调试,这个过程让你看得到。
奇伢的调试姿势
Go 程序用的最多的还是 dlv 调试,现在有了 vscode ,感觉是有了一个新的体验。本质上还是 dlv 调试。我们先捋一捋调试的思路,按照模式分为两大类来讲:
- 调试二进制文件:先编译,后调试,对应 launch 调试;
- 调试运行进程:调试正在运行的进程,对应 attach 调试;
如果按照代码位置再区分 local 还是 remote ,那么姿势就可以分为:
- 本地 launch 调试:vscode 在本机,代码在本地,二进制在本地;
- 本地 attach 调试:vscode 在本机,代码在本地,进程在本地;
- 远程 lanuch 调试:vscode 在本机,代码远端,二进制在远端;
- 远程 attach 调试:vscode 在本机,代码在本地,二进制在远端;
下面分别举两个最典型的栗子,远程开发 launch 调试和远程 attach 调试,来看看奇伢是怎么配置调试的吧。
1 远程开发调试 launch
演示的场景:vscode 在本地,代码在远端,二进制在远端。
这种方式本质是先编译,后调试。先编译出二进制文件,然后进行运行这个二进制文件进行调试。怎么得到这个二进制?
有两种方式:
- 让 vscode 编译出你的二进制文件,通过配置 task.json 这个文件,定义你的编译规则;
- 还有一种方式,就是纯粹靠你自己来编译出二进制,比如你写了个 Makefile 或者 go build 出你的二进制;
只要有个二进制,我们就能调试。这个对应了我常用的 dlv exec 的方式。vscode 调试首先创建一个 .vscode/launch.json 的配置文件:
{
// 自定义名字
"name": "Launch file",
// 调试的程序类型
"type": "go",
// 调试类型(调试二进制)
"request": "launch",
// 调试类型
"mode": "debug",
// 调试的程序
"program": "${file}"
}
上面的配置好后,打开你的主程序( main.go )文件,给你的文件设置个断点,点击左侧的运行调试按钮。就能让 vscode 先编译,后调试,并且停顿再断点出。
vscode 会编译出一个二进制文件 __debug_binxxx ,然后 debug 这个文件,并且 dlv dap 也会启动一个 dap server,用于和 vscode 链接
示例如图:
image.png这个太简单了,几乎没有任何障碍。
2 远程调试 attach
演示的场景:vscode 在本地,代码在本地,进程在远端。 这种场景说白了就是:我代码在本地,进程在线上。
因为奇伢是做后端开发的,平时开发的程序都是守护进程,那么 attach 这种方式是更通用的方式。往往就是进程正在运行,我们再去调试。gdb 和 dlv 都具备 attach 这种能力。这种场景,是经常在调试线上的守护程序来的。
如果是本地终端用这种方式调试:
dvl attach <pid>
假设,当前我们进程跑在线上:
- 在某台测试机器上,程序已经跑起来了,机器上没有代码;
- 我们本地有版本一致的代码,用 vscode 打开着;
你想要调试它,怎么办?
第一种方法:可以 ssh 到远端机器,然后 dlv 去调试。对比着本地的代码设置断点,进行调试。相对来讲比较麻烦。
假设,如果能用本地的代码加上远端的 dlv ,无缝联合起来,同步调试?岂不是完美。
vscode 支持这种方式! 使用的是 dlv 的 dap 功能,远端机器上用 dlv attach 到对应进程,且开一个 dap server 监听端口,本地 vscode 去连接这个端口。它们之间的通信使用 DAP 协议走网络传输,从而实现远程的 attach 调试。
下面来看一下具体演示步骤吧。
1 步骤一:远程拉起进程
这个很简单,后端开发,守护进程才是最常见的场景。
# 自己的进程自己拉。假设进程号是 7488
./hello_server```
2 **步骤二:dlv dap 服务器
**开启一个 dap 服务器,并且 dlv attach 到对应的进程上,并启动 dap 服务器;
dlv --headless -l 0.0.0.0:2345 attach 7488 --api-version 2
解释:
- 7488 是 hello_server 的进程号
- dlv 其实随便在哪个目录执行都可以
- 注意声明 --api-version 2
3 步骤三:vscode 客户端配置这个作为 dap 客户端,配置和 dlv dap 服务器的联通即可。
"configurations": [
{
// 自定义,名字,看起来有意义就行,用来给你选的;
"name": "Connect to server",
// 调试的是 go 程序
"type": "go",
// attach 进程的方式
"request": "attach",
// 远程调试
"mode": "remote",
// 注意!!非常关键,这是能否成功设置断点的关键参数。
"remotePath": "{编译的项目路径}",
// dlv server 启动的端口
"port": 2345,
// 远程主机的 IP
"host": "192.168.56.12"
}
]
强调 remotePath 这个参数,这个参数非常关键,是你能否远程断点成功的关键。它并不是进程当前的目录,也不是本地项目的代码目录,而是编译二进制的项目目录。
举个栗子:加入 hello_server 这个进程是在 /root/code/ 这个目录编译的,那么 remotePath 目录填的这个。后面 hello_server 放到其他任意目录运行都和 remotePath 没关系。
4 步骤四:运行调试设置断点,发一个请求,就可以调试了。演示效果:
image.png断点技巧
vscode 能打的断点有三种:
- 普通断点,运行到了就会停住;
- 条件断点,满足条件才会停住;
- 日志断点,运行到了只打印,不停;
1 Breakpoint
普通断点,这是最常见的断点,提前设置到代码某个位置,运行到了就会停在对应位置。
2 Conditional Breakpoint
条件断点。满足条件才会断住,这个可以更精准的调试。这个表达式是语言本身的表达式即可:比如 c++ :
tag == 2
tag 是 c++ 的一个整形变量。
3 Logpoint日志打印,不断点。很实用的技巧,只要路过就会打印一行信息。适用于不适合暂停调试的程序。比如可以输入:
result is {result.code()}
result 是 c++ 的一个 class 变量,code 是它的方法。
Debug Console
程序断点打住之后,我们还可以交互(就和 gdb,dlv 一样,手动输入命令),可以输入命令前缀 -exec
。比如,反汇编:
-exec disassemble
打印寄存器:
-exec print $rip
想知道全部命令,可以 help 一下:
-exec help
总结*
- 调试的两大类** launch 调试和 attach 调试**,开发过程 launch 模式可能占多数,但是测试过程,attach 模式可能才是多数的需求;
- 使用 dlv dap 开启一个 dap server,这样让编辑器或者 IDE 都能够通过网络介入调试;
- vscode 调试只是作为一个客户端,代码在本地,程序在远端,用 vscode 拉通起来,完美体验;
- 远程 attach 调试其实不需要远端有代码哦,这个记住了,remotePath 参数是关键;
- 除了普通断点,条件断点和日志断点真的挺有用的;
网友评论