Linux debug : addr2line追踪出错地址

调试zSeries上的Linux应用程序类似于调试其他体系结构上的Linux应用程序。对于有经验的Linux开发人员，最大的挑战是理解新的系统体系结构。对于刚接触Linux的大型机开发人员，掌握新的调试工具似乎是一项令人畏惧的任务。不要害怕。本文将提供一些有用的提示来帮助您入门。 学问来自实践，但是对于调试工具，在没有出现问题而迫使您去修复它们之前，“实践”是不会发生的。考虑到这点，下面将提供让您入门的“速成”指南。 User Debug 日志记录 调试一个崩溃的程序的第一步是弄清哪里出了错。zSeries 上的Linux内核具有这样一个内置特性，它在用户进程崩溃时记录一些基本的调试信息。要启用这个特性，请以 root 用户身份执行如下命令： echo 1 >> /proc/sys/kernel/userprocess_debug 当某个进程崩溃时，日志文件（/var/log/messages）中就会给出附加的信息，包括程序终止原因、故障地址，以及包含程序状态字（PSW）、通用寄存器和访问寄存器的简要寄存器转储。 Mar 31 11:34:28 l02 kernel: User process fault: interruption code 0x10 Mar 31 11:34:28 l02 kernel: failing address: 0 Mar 31 11:34:28 l02 kernel: CPU: 1 Mar 31 11:34:28 l02 kernel: Process simple (pid: 30122, stackpage=05889000) Mar 31 11:34:28 l02 kernel: Mar 31 11:34:28 l02 kernel: User PSW: 070dc000 c00ab738 Mar 31 11:34:28 l02 kernel: task: 05888000 ksp: 05889f08 pt_regs: 05889f68 Mar 31 11:34:28 l02 kernel: User GPRS: Mar 31 11:34:28 l02 kernel: 00000000 004019a0 004019a0 00000000 Mar 31 11:34:28 l02 kernel: 00000003 c00ab732 004008f8 00400338 Mar 31 11:34:28 l02 kernel: 40018ffc 0040061c 40018e34 7ffff800 Mar 31 11:34:28 l02 kernel: 00400434 80400624 8040066e 7ffff800 Mar 31 11:34:28 l02 kernel: User ACRS: Mar 31 11:34:28 l02 kernel: 00000000 00000000 00000000 00000000 Mar 31 11:34:28 l02 kernel: 00000001 00000000 00000000 00000000 Mar 31 11:34:28 l02 kernel: 00000000 00000000 00000000 00000000 Mar 31 11:34:28 l02 kernel: 00000000 00000000 00000000 00000000 Mar 31 11:34:28 l02 kernel: User Code: Mar 31 11:34:28 l02 kernel: 44 40 50 00 07 fe a7 4a 00 01 18 54 18 43 18 35 a8 24 00 00 程序（名为“simple”）以一个程序中断代码 0x10 终止（操作系统原理表明这是一个段转换错误），而故障地址为 0。毫无疑问，有人使用了空指针。现在我们知道发生了什么，下面需要弄清它发生在何处。 基本的诊断 User Debug日志条目所提供的信息可用于确定程序的崩溃位置。一些可用的工具可帮助解决您可能会遇到的各种程序终止问题。我们将在本文中逐步介绍那些工具。 首先，让我们检查一下该日志条目中的用户 PSW。该 PSW 包含指令地址、状态码以及关于机器状态的其他信息。眼下，我们仅关心指令地址（第33至第63位）。为简化起见，让我们假设用户PSW是 070dc000 80400618。记住，我们是在考察一个 ESA/390（31 位寻址）PSW。第32位不是指令地址的一部分，它是指示 31 位寻址模式的标志，但是在研究 PSW 值时必须处理它。为了获得实际的指令指针，可把PSW的第二个字减去 0x80000000。结果是一个指令地址 0x400618。为了定位代码，您需要可执行文件中的一些信息。首先使用readelf来打印一些程序头信息。 Elf file type is EXEC (Executable file) Entry point 0x400474 There are 6 program headers, starting at offset 52 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align PHDR 0x000034 0x00400034 0x00400034 0x000c0 0x000c0 R E 0x4 INTERP 0x0000f4 0x004000f4 0x004000f4 0x0000d 0x0000d R 0x1 [Requesting program interpreter: /lib/ld.so.1] LOAD 0x000000 0x00400000 0x00400000 0x00990 0x00990 R E 0x1000 LOAD 0x000990 0x00401990 0x00401990 0x000fc 0x00114 RW 0x1000 DYNAMIC 0x0009ac 0x004019ac 0x004019ac 0x000a0 0x000a0 RW 0x4 NOTE 0x000104 0x00400104 0x00400104 0x00020 0x00020 R 0x4 Section to Segment mapping: Segment Sections... 00 01 .interp 02 .interp .note.ABI-tag .hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.got .rela.plt .init .plt .text .fini .rodata 03 .data .eh_frame .dynamic .ctors .dtors .got .bss 04 .dynamic 05 .note.ABI-tag readelf -l simple的结果（记住“simple”是我们的测试程序的名称）。在Program Headers部分，第一个 LOAD 行提供了关于程序从哪里加载的信息。在 Flg 列，该段被标记为 R(read)E(executable)。VirtAddr是程序开始加载的地址。MemSiz是正在被加载到这个段中的代码长度。把它加到VirtAddr上，这个程序的基本地址范围就是0x400000-0x400990。程序发生崩溃的指令地址为0x400618，在程序的加载范围之内。现在我们知道了问题直接发生在代码中。 如果可执行文件包括调试符号，那么确定哪一行代码导致了问题是可以做到的。对该地址和可执行文件使用addr2line 程序，如下所示： addr2line -e simple 0x400618 将返回： /home/devuser/simple.c:34 要研究该问题，可以检查第 34 行。 对于图1中原始的程序崩溃，PSW 为070dc000 c00ab738。要获得指令地址，可减去0x80000000。结果为0x400ab738。这个地址并不准确地落在我们的小程序之内。那么，它是什么呢？是来自共享库的代码。如果对可执行文件运行ldd 命令（ldd simple），将会返回程序运行所需的共享对象的列表，以及该库在那里可用的地址。 libc.so.6 => /lib/libc.so.6 (0x40021000) /lib/ld.so.1 => /lib/ld.so.1 (0x40000000) 该指令地址对应于加载libc.so.6的地址。在我们的简单测试案例中，只需要两个共享对象。其他应用程序可能需要更多共享对象，这使得ldd的输出更加复杂。我们将以perl作为例子。 输入： ldd /usr/bin/perl 将得到： libnsl.so.1 => /lib/libnsl.so.1 (0x40021000) libdl.so.2 => /lib/libdl.so.2 (0x40039000) libm.so.6 => /lib/libm.so.6 (0x4003d000) libc.so.6 => /lib/libc.so.6 (0x40064000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x4018f000) /lib/ld.so.1 => /lib/ld.so.1 (0x40000000) 所需要的一切都在那里了，但是我发现对于这个进程，下面的内容读起来更快一点： ldd /usr/bin/perl | awk ‘{print? $4 “ “ $3 }’ | sort (0x40000000) /lib/ld.so.1 (0x40021000) /lib/libnsl.so.1 (0x40039000) /lib/libdl.so.2 (0x4003d000) /lib/libm.so.6 (0x40064000) /lib/libc.so.6 (0x4018f000) /lib/libcrypt.so.1 现在我们来确定崩溃发生在libc中的何处。假设libc.so.6的加载地址是0x40021000，从指令地址 0x400ab738减去它，结果为0x8a738。这是进入libc.so.6 的偏移。使用nm命令，从libc.so.6转储符号，然后尝试确定该地址位于哪个函数中。对于libc.so.6，nm将生成7,000多行输出。通过对计算得出的偏移部分执行 grep（正则表达式查找程序）可以削减必须检查的数据量。输入： nm /lib/libc.so.6 | sort | grep 0008a 将返回 66 行，在该输出的中间，我们会发现： 0008a6fc T memcpy 0008a754 t _wordcopy_fwd_aligned 该偏移落在memcpy中的某个位置。在此例中，一个空指针被当作目标地址传递给了memcpy。我们在何处调用的memcpy呢？问得好。我们可以通过检查输出在日志文件中的寄存器转储来确定目标区域。寄存器14包含执行某个函数调用时的返回地址。根据图1，R14是0x8040066e，它在截去高位之后产生一个地址 0x40066e。这个地址落在我们的程序范围之内，因此可以运行addr2line来确定该地址在何处。输入： addr2line -e simple 0x40066e 将返回： /home/devuser/simple.c:36 这是我们调用memcpy之后的那一行。关于addr2line的一点补充：如果可执行文件中没有包括调试符号，您将获得??:0 作为响应。 ---------------------------------------------------------------------------------------------------------------------------------------------- 用addr2line可以将函数地址解析为函数名，在Linux下用C/C++的程序，可以使用addr2line根据地址获取到对应的代码行。 这是一个示例程序，func函数返回参数a除以参数b的结果。这里使用0作为除数，结果就是程序因为除以0导致错误，直接中断了。 #include <stdio.h> int func(int a, int b) { return a / b; } int main() { int x = 10; int y = 0; printf("%d / %d = %d\n", x, y, func(x, y)); return 0; } 使用 $ gcc -g -o test1 -g test1.c 编译程序，test1.c是程序文件名。执行程序，结果程序异常中断。查看系统dmesg信息，发现系统日志的错误信息： [54106.016179] test1[8352] trap divide error ip:400506 sp:7fff2add87e0 error:0 in test1[400000+1000] 这条信息里的ip字段后面的数字就是test1程序出错时所程序执行的位置。使用addr2line就可以将400506转换成出错程序的位置： $ addr2line -e test1 400506 /home/hanfoo/code/test/addr2line/test1.c:5 这里的test1.c:5指的就是test1.c的第5行 return a / b;   也正是这里出现的错误。addr2line帮助我们解决了问题。 addr2line如何找到的这一行呢。在可执行程序中都包含有调试信息，其中很重要的一份数据就是程序源程序的行号和编译后的机器代码之间的对应关系Line Number Table。DWARF格式的Line  Number Table是一种高度压缩的数据，存储的是表格前后两行的差值，在解析调试信息时，需要按照规则在内存里重建Line Number  Table才能使用。 Line Number Table存储在可执行程序的.debug_line域，使用命令 $ readelf -w test1 可以输出DWARF的调试信息，其中有两行 Special opcode 146: advance Address by 10 to 0x4004fe and Line by 1 to 5   Special opcode 160: advance Address by 11 to 0x400509 and Line by 1 to 6   这里说明机器二进制编码的0x4004fe位置开始，对应于源码中的第5行，0x400509开始就对应与源码的第6行了，所以400506这个地址对应的是源码第5行位置。 addr2line通过分析调试信息中的Line Number Table自动就能把源码中的出错位置找出来， 二、backtrace()、backtrace_symbol() API 通过API获取程序奔溃时的函数调用栈信息 #include <stdlib.h> #include <stdio.h> #include <stddef.h> #include <signal.h> #include <execinfo.h> // 0: GENERATE COREDUMP FILE // 1: PRINT STACK BY SELF int g_iTestFlag = 1; #define ADDR_MAX_NUM 100 void CallbackSignal (int iSignalNo) { printf ("CALLBACK: SIGNAL:\n", iSignalNo); void *pBuf[ADDR_MAX_NUM] = {0}; int iAddrNum = backtrace(pBuf, ADDR_MAX_NUM); printf("BACKTRACE: NUMBER OF ADDRESSES IS:%d\n\n", iAddrNum); char ** strSymbols = backtrace_symbols(pBuf, iAddrNum); if (strSymbols == NULL) { printf("BACKTRACE: CANNOT GET BACKTRACE SYMBOLS\n"); return; } int ii = 0; for (ii = 0; ii < iAddrNum; ii++) { printf("%03d %s\n", iAddrNum-ii, strSymbols[ii]); } printf("\n"); free(strSymbols); strSymbols = NULL; exit(1); // QUIT PROCESS. IF NOT, MAYBE ENDLESS LOOP. } void FuncBadBoy() { void* pBadThing = malloc(1024*1024*256); free (pBadThing); free (pBadThing); } void FuncBadFather() { FuncBadBoy(); } int main(int argc, char **argv){ if (g_iTestFlag) { signal(SIGSEGV, CallbackSignal); } FuncBadFather(); return 0; } gcc -g test.c -o test ./test CALLBACK: SIGNAL: BACKTRACE: NUMBER OF ADDRESSES IS:8 008 ./test_backtrace_addr2line.elf(CallbackSignal+0x5a) [0x400a0e] 007 /lib64/libc.so.6() [0x3f2c4326a0] 006 /lib64/libc.so.6(cfree+0x1c) [0x3f2c47b93c] 005 ./test_backtrace_addr2line.elf(FuncBadBoy+0x2e) [0x400afa] 004 ./test_backtrace_addr2line.elf(FuncBadFather+0xe) [0x400b0a] 003 ./test_backtrace_addr2line.elf(main+0x49) [0x400b55] 002 /lib64/libc.so.6(__libc_start_main+0xfd) [0x3f2c41ed5d] 001 ./test_backtrace_addr2line.elf() [0x4008f9] 对于函数栈每个函数所在的源代码文件名、行号的信息，可以使用 addr2line 工具获取。对上述函数栈尾部的[0xHHHHHHHH]，分别执行 addr2line -Cif -e test_backtrace_addr2line.elf 0xHHHHHHHH 即可获得具体的源文件名、行号。 addr2line -Cif -e test 0x400afa    FuncBadBoy /root/prog/src/test2/test.c:36 addr2line -Cif -e test 0x400b0a FuncBadFather /root/prog/src/test2/test.c:40 addr2line -Cif -e test 0x400b55 main