gdb 调试入门-bcc&perf-tools

调试 专栏收录该内容
16 篇文章 0 订阅

bcc&perf-tools

有空要研究一下这两个工具的使用方法

没想到Brendan Gregg这样的大牛,会写出这样一篇gdb tutorials文章:gdb Debugging Full Example (Tutorial): ncurses 。但可能正如文章开头所说,大牛对网上的gdb文章都不太满意,所以才有了这篇高质量指南,gdb入门者的福音。—— 何登成

如果你是系统管理员,但还不认识 Brendan Gregg,那网上流传甚广的 3 张 Linux 性能工具图(链接),你应该看过的。—— 伯小乐。

                                                                    brendan-gregg

( Brendan Gregg)



gdb 调试 ncurses 全过程:

发现网上的“gdb 示例”只有命令而没有对应的输出,我有点不满意。gdb 是 GNU 调试器,Linux 上的标配调试器。当我看 Greg Law 在 CppCon 2015 上的演讲《给我 15 分钟,我将改变你的对 GDB 的认知》的时候,我想起了示例输出的不足,幸运的是,这次有输出!这 15 分钟太值了。

它也启发我去分享一个完整的 gdb 调试实例,包含输出和每个步骤,甚至钻牛角尖的情况。这不是一个特别有趣或奇怪的问题,只是常规的 gdb 调试会话。但它包含了基础的东西可以勉强作为教程使用,记住 gdb 里还有很多东西我这里没用到。

我会以 root 权限运行下面的命令,因为我在调试一个工具,它需要 root 权限(目前)。需要的时候可用 sudo 获取 root 权限。你也没必要通读全篇︰ 我已列出每一步,你可以浏览它们找感兴趣的看。

1. 问题概述

BPF 工具箱里的 bcc 工具集有一个对cachetop.py 的 pull 请求,它通过程序使用 top-like display 显示 page cache 的统计。太好了 !然而,当我测试它时,遇到了段错误︰

注意它说的是“段错误”,不是“段错误(核心已转储)”。我想要一个核心转储文件用来调试。(核心转储文件是进程内存的拷贝 – 这个名字来源于磁芯存储器时代 – 可用调试器分析)

分析核心转储文件是一种方法,但不是调试这个问题的唯一方法。我可以在 gdb 中运行此程序,来检查这个问题。我也可以在段错误发生时,用外部追踪器去抓数据和栈帧。我们从核心转储文件入手。

2. 解决核心转储问题

我检查一下核心转储的设置:

ulimit -c 显示核心转储文件大小的最大值,这里是零:禁止核心转储(对于本进程和它的子进程)。

/proc/…/core_pattern 仅仅被设为 “core”,表示会在当前目录下生成一个文件名为 “core” 的 核心转储文件。目前这样就行了,但是我要演示如何把它设置为全局位置。

你可以进一步定制 core_pattern;例如,%h 为主机名,%t 为转储的时间。这些选项被写在 Linux 内核源码 Documentation/sysctl/kernel.txt中。

要使 core_pattern 保持不变,重启之后仍然有效,你可以通过设置 /etc/sysctl.conf 里的 “kernel.core_pattern” 实现。

再来一次:

好多了:我们有了自己的核心转储文件。

3. 启动 GDB

现在我要用 gdb 启动目标程序(用 shell 替换符,”`”,不过在你确定能用的情况下,也可指定完整路径),和核心转储文件:

最后两行很有趣:它告诉我们这个段错误发生在 libncursesw 库里 doupdate() 函数中。可以先在网上搜一下,以防这是个很常见的问题。我搜了一下,可是没发现一个常见的原因。

我已经猜到 libncursesw 是什么了,如果你对它很陌生,它在 “/lib” 目录下以 “.so.*” 结尾表明这是一个动态库文件,可能有 man 手册、网站、包描述等。

我是碰巧在 Ubuntu 上调试,但用什么 Linux发行版对使用 gdb 并没有影响。

4. 回溯

栈回溯显示我们是如何到达失败点的,通常足够帮助我们确定常见的问题。bt (backtrace的简写)常常是我在 gdb 中使用的第一条命令:

从下往上,按照从父函数到子函数的顺序看。有 “??” 的地方是因为符号解析失败。遍历栈 – 用来生成栈帧 — 也会失败。在这种情况下你可能会看到一个正常的栈帧,跟着一个小数值的假地址。如果符号或栈破损很严重,导致无法理解栈回溯,这里有几个常用的办法来修复:安装 debug info 包(给 gdb 提供更多的符号,让它来做基于 DWARF 的栈遍历),或者重新用源码编译(-fno-omit-frame-pointer -g)一个带帧指针和调试信息的版本。以上大多数 “??”
可以通过安装 python-dbg 包来修复。

这些栈看起来不太有用:帧 5 到 17 (左边的索引)在 Python 内部,虽然还看不到 Python 方法。帧 4 是 _curses 库,然后就到了 libncursesw。看起来调用顺序是 wgetch()->wrefresh()->doupdate()。根据函数名来看,我猜是刷新窗口。为什么会导致核心转储 呢?

5. 反汇编

我从反汇编发生段错误的函数 doupdate() 开始:

部分输出。(我也可以只输入 “disas” 它会默认反汇编 doupdate )

“=>” 指向段错误地址,此处是一条 mov 指令 mov 0x10(%rsi),%rdi:从%rsi中指向内存地址的值加偏移量 0x10 处取值,送到 %rdi 寄存器中。接下来我会检查寄存器的状态。

6. 查看寄存器

使用 i r(info registers 的简写)打印寄存器值:

哦,%rsi是零,这就是我们的问题所在!零不太可能是有效地址,并且解引用一个未初始化的指针或空指针引起的段错误是常见的软件 bug。

7. 内存映射

你可以使用 i proc m (info proc mappings 的简写)核查零是不是有效地址:

第一个有效的虚拟地址是 0x400000。任何小于它的地址都是非法的,这些地址如果被引用,就会引起段错误。

目前有几种不同的方式可做进一步分析。我先一步一步的看指令。

8. 断点

先回到反汇编:

看这四条指令:好像是从栈中取东西放到 %rax,然后解引用 %rax 到 %rsi,再将 %eax 置零( xor 是一个优化,替换掉移动 0 的动作),最后将 %rsi 解引用再加一个偏移,不过我们知道 %rsi 是零。这几条指令用来访问数据结构。 可能 %rax 会很有趣,但是它已经被前面的指令置零,所以我们在核心转储文件的寄存器里看不到它的值。

我可以在 doupdate+289 下个断点,然后逐条指令查看寄存器的值如何变化。首先,我需要启动 gdb 把程序跑起来:

现在用 b (break 的简写)来下断点:

哦。我想演示这个错误来解释为什么我们经常以在主函数设置断点作为开始,因为这时候符号可能被加载,可以设置感兴趣的断点。我直接在 doupdate 函数设断点,避开这个问题,一旦断点被触发就设置加了偏移的断点。

我们到了断点处。

如果你之前没有做这些,r (run) 命令会把参数传给我们早先在命令行指定的 gdb 目标(python)。这样的话程序会以执行 “python cachetop.py” 结束。

9. 单步调试

我跳到下一条指令(si,stepi的简写),然后检查寄存器:

又一条线索。所以我们解引用的空指针好像是一个叫 “cur_term” 的符号(p/a 是 print/a 的简写,这里 “/a” 指以地址的形式)。考虑到这是 ncurses, 是我们的环境变量 TERM 设置有问题吗?

我试过将其设置为 vt100 并运行程序,还是遇到了同样的段错误。

注意我只是在 doupdate() 第一次被调用的时候查看了寄存器,但是它可以被多次调用,所以问题可能出在后边的调用中。我可以通过执行 c( continue 的简写)一步步到达出问题的地方。如果它被调用几次的话这样做是可行的,如果它被调用几千次的话我得用别的办法。(我会在 15 节的里介绍。)

10. 回退

gdb 有一个超棒的功能叫回退,Greg Law 在他的演讲中提到过。这里有一个例子。

我再启动一个 python 会话,从头演示:

和之前一样我在 doupdate 下断点,一旦触发,我就启动 recording,然后继续运行程序直到崩溃。Recording 会增加相当大的开销,所以我不想在主函数里就将它打开。

这里我可以逐行或逐条指令的回退。它通过播放我们记录的寄存器状态来工作。我回退两条指令,然后打印寄存器值:

所以,又找到了 “cur_term” 的线索。我很想看这里的源代码,但我将从调试信息入手。

11. 调试信息

这是 libncursesw,我没有安装调试信息(Ubuntu):

我把它装上:

太好了,版本匹配。那么现在我们的段错误是什么样子呢?

栈回溯看起来不太一样:我们确实不在 doupdate() 里边,而是在 ClrBlank() 中,它内联在 ClrUpdate() 里,ClrUpdate() 又内联在 doupdate() 中。

现在我真的要看源码了。

12. 源代码

安装了调试信息之后,gdb 可以同时列出源码和汇编:

好极了!看 “=>” 和它上边的代码。所以我们的段错误发生在 “if (back_color_erase)” ?看起来不可能。

这里我检查了一下,我的调试信息版本是对的,重新在 gdb 里边运行程序直到发生段错误。错误相同。

back_color_erase 有什么特殊吗?我们现在在 ClrBlank() 中,我先列出源码:

啊,在这个函数里边没定义,难道是全局变量?

13. TUI

有必要看看这些代码在 gdb 的文本用户界面(TUI)里是什么样的,我用的不多,是看了 Greg 的演讲之后受到的启发。

你可以用 –tui 来启动:

它在抱怨没有 Python 源码。我可以搞定,但是我们是在 libncursesw 里边崩溃的。所以不管它敲回车让它完成加载,在发生错误的地方加载了 libncursesw 调试信息里的源码:

棒极了!

“>” 指向发生崩溃的那行代码。更棒的是:用 layout split 命令,我们可以在不同的窗口查看源代码和汇编代码。

Greg 演示这个的时候,和这里的顺序相反,因此你可想像同时查看源代码和汇编的情景(这里我需要一个视频来演示)。

14. 外部工具:cscope

我需要对 back_color_erase 有更多了解,我可以试试 gdb 的 搜索命令,但是我发现用一个外部工具:cscope 更快。 cscope 是一个基于文本的代码浏览器 ,诞生于80年代的贝尔实验室。如果你有喜欢的现代 IDE,可以不用它。

安装 cscope:

cscope -bqR 用来建立查找数据库。cscope -dq 用来启动 cscope。

查找 back_color_erase 的定义:

敲回车:

哦,一个宏定义。(作为宏定义的常见的形式,它们至少应该大写)

好吧,那么 CUR 是什么呢? 用 cscope 查找定义易如反掌。