GDB调试实践二（gdb找不到动态库，对运行中的进程生成core文件）

最近使用GDB调试程序的一点经验之谈：

1、程序运行中生成一个Core文件便于保护现场，调试程序，gcore可以满足这种需求：

gcore：对正在运行的进程生成一个内存转储文件，方便保护现场。例如：

–     gcore -s -c test.core pid

–     用-s选项使进程在转储过程中处于停止状态，可以保证转储文件的一致性。若不用-c选项指定转储文件名，则会使用默认的core.pid形式的文件名。

 

2、我的linux虚拟机中调试程序时，发现直接run程序没问题，但gdb调试的时候就提示找不到某个动态库

原因如下：

1）我的虚拟机里同一个用户下由于要编译测试多个不同版本的代码，而每个版本都有不同的运行环境（如：PATH、LD_LIBRARY_PATH等环境变量设置）

2）我目前使用csh，为了快速切换不同的编译环境，我把运行环境所需的环境变量写到不同的.cshrc脚本中，需要切换时运行source .cshrc_XXX

3) GDB调试程序时会启一个新的shell，而且新shell启动时使用默认的.cshrc脚本，从而导致上述的问题，从本质上来说GDB使用的shell的环境非我们要调试程序所需的shell环境设置

 

解决方法：

1）最简单：将所有动态库的查找位置都设置到默认.cshrc中的LD_LIBRARY_PATH的环境变量中

2）其他方法有待探索

 

下面转载一篇不错的gdb总结

gdb基本用法

•         调用方式：gdb program [corefile|pid]

•         基本命令：

–     r(un) [shell args]：开始运行程序。后面可跟传给被调试程序的命令行参数。

–     s(tep) [N]：单步运行程序，进入函数调用。

–     n(ext) [N]：单步运行程序，不进入函数调用。

–     b(reak) [LOCATION]：设置断点。断点位置可以用如下形式表示：

•         LINENUM     位置为当前源码文件的特定行号

•         FILE:LINENUM    位置为指定源码文件的特定行号

•         FUNCTION   位置为特定函数入口

•         FILE:FUNCTION 位置为指定源码文件中的特定函数入口。主要用于存在多个同名的静态函数的情况下。

•         *ADDRESS   位置为指定的地址

–     c(ontinue) [N]：从之前中断的位置继续运行程序。

–     sta(rt) [shell args]：同run命令类似，但自动停止在main函数入口处，比break+run更方便。

–     l(ist) [LOC1[,[LOC2]]：显示源码文件内容。例如：

•         l func,main

•         l 10,*0x40107d

•         l main,

•         l ,func

–     d(elete) [bpno1 [bpno2 […]]]：删除指定编号的断点，若不指定断点编号则删除所有断点。

–     disp(lay) [/FMT] [EXP]：设置每当程序中断时要显示的表达式。

–     p(rint) [/FMT] [EXP]：显示指定的表达式内容。

–     h(elp)：帮助命令，救命用的！

 

gdb高级用法

•         fin(ish)：持续运行至当前堆栈帧结束，并显示返回值。

•         adv(ance) [LOC]：持续运行至指定的位置。例如：

–     adv func

–     adv *0x40107b

•         att(ach) pid：将gdb附加到指定的进程上并中断在该进程当前执行位置处。

•         det(ach)：使gdb不再附加在当前进程上并恢复被调试进程的运行。

•         info addr <symbol>：查找指定符号对应的地址。

•         info sym <addr>：查找指定地址对应的符号。

•         当符号自动补全的范围太大时可以用单引号开头强制前缀匹配，这样来补全C++类成员很方便。

•         bt [full]：查看所有堆栈帧，若加上full选项则还会显示每个堆栈帧内的局部变量值。

•         f(rame) [FRAMENO]：选择或显示当前堆栈帧。

•         up/down：将向上/向下一层的堆栈帧作为当前选择的帧。

 

常用辅助调试工具

•         gcore：对正在运行的进程生成一个内存转储文件，方便保护现场。例如：

–     gcore -s -c test.core pid

–     用-s选项使进程在转储过程中处于停止状态，可以保证转储文件的一致性。若不用-c选项指定转储文件名，则会使用默认的core.pid形式的文件名。

•         pstack：查看转储文件/正在运行的进程中的完整堆栈帧。例如：

–     pstack -t -O pid/corefile

–     用-t选项可以显示提取堆栈帧时进程被pstack暂停的时间；用-O选项可以显示堆栈帧中每个函数所处目标文件的完整路径。

–     默认情况下，为了保证结果的一致性，pstack在提取堆栈帧时会暂停对应进程的活动，但在进程逻辑对时间很敏感时这样可能导致逻辑混乱引起进程崩溃；此时可以使用-n选项强制pstack不暂停要查看的进程，不过相应地取得的堆栈帧数据就有可能出现问题。

•         truss：仅用于FreeBSD，跟踪命令行或已运行进程的系统调用序列和信号。例如：

–     跟踪命令行：truss /bin/echo hello

–     跟踪已运行的进程：truss -p 1377

•         strace：可用于FreeBSD/Linux，功能同truss相近，输出结果详细一些，包含了系统调用的具体参数。一般用法同truss。

•         ltrace：可用于FreeBSD/Linux，跟踪命令行或已运行进程的运行库调用序列。一般用法同truss。

•         ktrace/kdump：它们是FreeBSD提供的内核级进程跟踪工具，会监控进程的系统调用、文件系统节点转换、信号处理等各种内核级操作。用法：

–     跟踪命令行并记录在ktrace.out中：ktrace command

–     跟踪活动进程并记录在ktrace.out中：ktrace -p pid

–     关闭所有跟踪活动：ktrace -C

–     显示ktrace.out中的跟踪结果：kdump

•         valgrind：x86硬件虚拟机，其中的memcheck模块可用来检测程序是否存在内存泄漏：

–     valgrind -v --num-callers=20 --leak-check=yes --leak-resolution=high--show-reachable=yes command

–     结果中的LEAK SUMMARY总结了内存泄漏情况，其中需要注意的是definitely lost和possibly lost两部分。

 

调试建议

•         产品程序在编译时留下尽可能多的调试符号信息（用-g3选项编译），这些信息不会减慢运行速度，但在出现问题时对调试工作很有帮助。

•         调试用程序不使用优化，并关闭STL的存储池分配方式，这样可以避免valgrind错误地报告内存泄漏，选项为-O0 -g3 –DGLIBCXX_FORCE_NEW