用GDB调试程序(七)


改变程序的执行
———————

    一旦使用GDB挂上被调试程序,当程序运行起来后,你可以根据自己的调试思路来动态地在GDB中更改当前被调试程序的运行线路或是其变量的值,这个强大的功能能够让你更好的调试你的程序,比如,你可以在程序的一次运行中走遍程序的所有分支。
   
   
一、修改变量值

    修改被调试程序运行时的变量值,在GDB中很容易实现,使用GDB的print命令即可完成。如:
   
        (gdb) print x=4
   
    x=4这个表达式是C/C++的语法,意为把变量x的值修改为4,如果你当前调试的语言是Pascal,那么你可以使用Pascal的语法:x:=4。
   
    在某些时候,很有可能你的变量和GDB中的参数冲突,如:
   
        (gdb) whatis width
        type = double
        (gdb) p width
        $4 = 13
        (gdb) set width=47
        Invalid syntax in expression.

    因为,set width是GDB的命令,所以,出现了“Invalid syntax in expression”的设置错误,此时,你可以使用set var命令来告诉GDB,width不是你GDB的参数,而是程序的变量名,如:
   
        (gdb) set var width=47
       
    另外,还可能有些情况,GDB并不报告这种错误,所以保险起见,在你改变程序变量取值时,最好都使用set var格式的GDB命令。
   

二、跳转执行

    一般来说,被调试程序会按照程序代码的运行顺序依次执行。GDB提供了乱序执行的功能,也就是说,GDB可以修改程序的执行顺序,可以让程序执行随意跳跃。这个功能可以由GDB的jump命令来完:
   
    jump <linespec>
    指定下一条语句的运行点。<linespce>可以是文件的行号,可以是file:line格式,可以是+num这种偏移量格式。表式着下一条运行语句从哪里开始。
   
    jump <address>
    这里的<address>是代码行的内存地址。
   
    注意,jump命令不会改变当前的程序栈中的内容,所以,当你从一个函数跳到另一个函数时,当函数运行完返回时进行弹栈操作时必然会发生错误,可能结果还是非常奇怪的,甚至于产生程序Core Dump。所以最好是同一个函数中进行跳转。
   
    熟悉汇编的人都知道,程序运行时,有一个寄存器用于保存当前代码所在的内存地址。所以,jump命令也就是改变了这个寄存器中的值。于是,你可以使用“set $pc”来更改跳转执行的地址。如:
   
    set $pc = 0x485


三、产生信号量

    使用singal命令,可以产生一个信号量给被调试的程序。如:中断信号Ctrl+C。这非常方便于程序的调试,可以在程序运行的任意位置设置断点,并在该断点用GDB产生一个信号量,这种精确地在某处产生信号非常有利程序的调试。
   
    语法是:signal <singal>,UNIX的系统信号量通常从1到15。所以<singal>取值也在这个范围。
   
    single命令和shell的kill命令不同,系统的kill命令发信号给被调试程序时,是由GDB截获的,而single命令所发出一信号则是直接发给被调试程序的。
   

四、强制函数返回

    如果你的调试断点在某个函数中,并还有语句没有执行完。你可以使用return命令强制函数忽略还没有执行的语句并返回。
   
    return
    return <expression>
    使用return命令取消当前函数的执行,并立即返回,如果指定了<expression>,那么该表达式的值会被认作函数的返回值。
   
   
五、强制调用函数

    call <expr>
    表达式中可以一是函数,以此达到强制调用函数的目的。并显示函数的返回值,如果函数返回值是void,那么就不显示。
   
    另一个相似的命令也可以完成这一功能——print,print后面可以跟表达式,所以也可以用他来调用函数,print和call的不同是,如果函数返回void,call则不显示,print则显示函数返回值,并把该值存入历史数据中。

 

在不同语言中使用GDB
——————————

GDB支持下列语言:C, C++, Fortran, PASCAL, Java, Chill, assembly, 和 Modula-2。一般说来,GDB会根据你所调试的程序来确定当然的调试语言,比如:发现文件名后缀为“.c”的,GDB会认为是C程序。文件名后缀为“.C, .cc, .cp, .cpp, .cxx, .c++”的,GDB会认为是C++程序。而后缀是“.f, .F”的,GDB会认为是Fortran程序,还有,后缀为如果是“.s, .S”的会认为是汇编语言。

也就是说,GDB会根据你所调试的程序的语言,来设置自己的语言环境,并让GDB的命令跟着语言环境的改变而改变。比如一些GDB命令需要用到表达式或变量时,这些表达式或变量的语法,完全是根据当前的语言环境而改变的。例如C/C++中对指针的语法是*p,而在Modula-2中则是p^。并且,如果你当前的程序是由几种不同语言一同编译成的,那到在调试过程中,GDB也能根据不同的语言自动地切换语言环境。这种跟着语言环境而改变的功能,真是体贴开发人员的一种设计。


下面是几个相关于GDB语言环境的命令:

    show language
        查看当前的语言环境。如果GDB不能识为你所调试的编程语言,那么,C语言被认为是默认的环境。
       
    info frame
        查看当前函数的程序语言。
       
    info source
        查看当前文件的程序语言。
   
如果GDB没有检测出当前的程序语言,那么你也可以手动设置当前的程序语言。使用set language命令即可做到。

    当set language命令后什么也不跟的话,你可以查看GDB所支持的语言种类:
   
        (gdb) set language
        The currently understood settings are:
       
        local or auto    Automatic setting based on source file
        c                Use the C language
        c++              Use the C++ language
        asm              Use the Asm language
        chill            Use the Chill language
        fortran          Use the Fortran language
        java             Use the Java language
        modula-2         Use the Modula-2 language
        pascal           Use the Pascal language
        scheme           Use the Scheme language
       
    于是你可以在set language后跟上被列出来的程序语言名,来设置当前的语言环境。
   
   

后记
——

    GDB是一个强大的命令行调试工具。大家知道命令行的强大就是在于,其可以形成执行序列,形成脚本。UNIX下的软件全是命令行的,这给程序开发提代供了极大的便利,命令行软件的优势在于,它们可以非常容易的集成在一起,使用几个简单的已有工具的命令,就可以做出一个非常强大的功能。
   
    于是UNIX下的软件比Windows下的软件更能有机地结合,各自发挥各自的长处,组合成更为强劲的功能。而Windows下的图形软件基本上是各自为营,互相不能调用,很不利于各种软件的相互集成。在这里并不是要和Windows做个什么比较,所谓“寸有所长,尺有所短”,图形化工具还是有不如命令行的地方。(看到这句话时,希望各位千万再也不要认为我就是“鄙视图形界面”,和我抬杠了 )
   
    我是根据版本为5.1.1的GDB所写的这篇文章,所以可能有些功能已被修改,或是又有更为强劲的功能。而且,我写得非常仓促,写得比较简略,并且,其中我已经看到有许多错别字了(我用五笔,所以错字让你看不懂),所以,我在这里对我文中的差错表示万分的歉意。
   
    文中所罗列的GDB的功能时,我只是罗列了一些带用的GDB的命令和使用方法,其实,我这里只讲述的功能大约只占GDB所有功能的60%吧,详细的文档,还是请查看GDB的帮助和使用手册吧,或许,过段时间,如果我有空,我再写一篇GDB的高级使用。
   
    我个人非常喜欢GDB的自动调试的功能,这个功能真的很强大,试想,我在UNIX下写个脚本,让脚本自动编译我的程序,被自动调试,并把结果报告出来,调试成功,自动checkin源码库。一个命令,编译带着调试带着checkin,多爽啊。只是GDB对自动化调试目前支持还不是很成熟,只能实现半自动化,真心期望着GDB的自动化调试功能的成熟。
   
    如果各位对GDB或是别的技术问题有兴趣的话,欢迎和我讨论交流。本人目前主要在UNIX下做产品软件的开发,所以,对UNIX下的软件开发比较熟悉,当然,不单单是技术,对软件工程实施,软件设计,系统分析,项目管理我也略有心得。欢迎大家找我交流,(QQ是:753640,MSN是:haoel@hotmail.com)

<-上一页 

(版权所有,转载时请注明作者和出处)

<think>好的,用户想了解如何用GDB调试程序卡死的问题。首先,我需要回忆一下GDB的基本用法和相关的调试技巧。用户提到的几个引用里提到了一些方法,比如附加到进程、检查线程堆栈、使用非侵入式attach方式,还有修改系统设置如yama.ptrace_scope。这些都是关键点。 首先,用户可能需要知道如何启动GDB并附加到正在运行的进程。这涉及到使用gdb -p <pid>或者attach命令。但要注意,有些系统可能需要调整ptrace_scope的设置,比如设置为0,否则权限可能不够。这点在引用[1]里有提到,所以需要提醒用户检查系统配置。 接下来,附加到进程后,如何查看各个线程的状态。程序卡死通常是因为某个线程阻塞在了某个系统调用或死锁。使用info threads可以列出所有线程,然后切换线程查看堆栈。引用[2]和[3]中提到了使用bt(backtrace)来检查堆栈,定位卡住的位置。这时候需要告诉用户如何切换线程,检查每个线程的堆栈,找出可能阻塞的地方。 另外,非侵入式调试方法也很重要,比如gdb -p <pid>后先用c继续运行,再中断。这样可以不干扰程序运行,适合不能复现的情况,引用[3]提到了这种情况。可能需要详细说明这个过程。 还有,如果程序卡在IO操作或死锁,使用strace或pstack可能会有帮助,但用户主要问的是GDB,所以可能需要简要提及这些工具作为补充,但重点在GDB的操作步骤。 用户的问题可能还包括如何处理多线程中的死锁,这时候需要检查互斥锁的状态,看是否有线程在等待锁。GDB中可以观察锁的信息,或者检查堆栈中的锁函数调用,如pthread_mutex_lock。 此外,引用[4]提到Qt Creator调试时断点导致卡死,可能涉及前端工具的问题,但用户的问题更偏向于使用GDB直接调试,所以可能不需要深入讨论Qt Creator的设置,但可以提醒如果前端工具有问题,可以尝试直接使用GDB命令行。 总结步骤应该是:准备阶段调整系统设置,附加到进程,检查线程堆栈,分析可能阻塞的位置,结合其他工具如strace。同时,要给出具体的命令示例,方便用户跟随操作。另外,常见原因如死锁、阻塞IO、无限循环需要分别说明如何识别和处理。 可能还需要注意,在附加进程后,如何正确detach以避免影响程序运行,引用[1]提到这一点。此外,处理完卡死后如何继续调试其他部分,或者收集信息后退出。 最后,生成相关问题时要围绕GDB调试卡死的扩展,比如性能影响、核心转储分析、死锁检测方法等。</think>### 如何用GDB调试分析和解决程序卡死问题 #### 一、调试前的系统配置准备 1. **修改`ptrace_scope`权限**(Linux系统默认可能限制进程调试权限) ```bash echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope ``` 或永久生效需修改`/etc/sysctl.d/10-ptrace.conf`,添加`kernel.yama.ptrace_scope = 0`[^1]。 #### 二、GDB调试步骤 1. **附加到目标进程** ```bash gdb -p <进程PID> # 或先启动gdb后输入 `attach <PID>` ``` 附加后输入`continue`让程序继续运行,避免卡在初始断点。 2. **检查线程状态** ```gdb info threads # 查看所有线程状态 thread <线程ID> # 切换到卡死的线程 bt # 查看该线程的堆栈调用(关键步骤,定位阻塞点)[^3] ``` - 若发现堆栈停留在`pthread_join`、`epoll_wait`或`futex`等系统调用,可能涉及**锁竞争**或**IO阻塞**。 - 若堆栈显示在用户代码函数(如循环或条件判断),需检查逻辑是否陷入**死循环**。 3. **非侵入式调试(保留现场)** ```bash gdb -p <PID> -ex "set pagination off" -ex "thread apply all bt" -ex "detach" -ex "quit" ``` 此命令直接输出所有线程堆栈后退出,避免交互式操作影响程序状态。 #### 三、常见卡死场景分析 1. **死锁问题** - 检查线程堆栈中是否存在多个线程互相等待锁: ```gdb info registers # 查看寄存器中的锁地址 p *(pthread_mutex_t*)<锁地址> # 检查锁状态 ``` - 使用`deadlock.py`等GDB插件自动检测死锁。 2. **阻塞系统调用** - 若卡在`read`/`write`等系统调用,结合`strace`观察具体参数: ```bash strace -p <PID> -s 1024 -f # 跟踪系统调用及参数 ``` 3. **无限循环** - 通过`disassemble`反汇编当前函数,结合源码检查循环条件变量是否异常。 #### 四、调试后操作 - 输入`detach`退出GDB并让程序继续运行。 - 若需终止进程,使用`kill`命令。 --- ### 示例调试流程 假设程序卡死在`do_work()`函数: ```gdb (gdb) bt #0 0x00005555555551a9 in do_work () at main.c:10 #1 0x00005555555551e2 in main () at main.c:15 ``` 检查变量值: ```gdb (gdb) p flag_variable $1 = 0 # 发现循环条件变量未更新 ``` ---
评论 20
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值