作者:良知犹存 转载授权以及围观:欢迎添加微信号:Conscience_Remains 总述     今天我们介绍一下core dump文件,Core dump叫做核心转储,它是进程运行时在突然崩溃的那一刻的一个内存快照.操作系统在程序发生异常而异常在进程内部又没有被捕获的情况下,会把进程此刻内存.寄存器状态.运行堆栈等信息转储保存在一个文件里. 该文件也是二进制文件,可以使用gdb.elfdump.objdump或者windows下的windebug.solaris下的mdb进行打开分析里面的

到目前为止我们的调试手段只有一种: 根据程序执行时的出错现象假设错误原因,然后在代码中适当的位置插入printf,执行程序并分析打印结果,如果结果和预期的一样,就基本上证明了自己假设的错误原因,就可以动手修正Bug了. 如果结果和预期的不一样,就根据结果做进一步的假设和分析. 这里,我们介绍一种很强大的调试工具gdb,可以完全操控程序的运行,使得程序就像你手里的玩具一样,叫它走就走,叫它停就停,并且随时可以查看程序中所有的内部状态,比如各变量的值.传给函数的参数.当前执行的代码行等. 有了gdb

说到Lua代码调试,最常用的方法应该就是加一堆print进行打印.print大法虽好,但其缺点也是显而易见的.比如效率低下,需要修改原有函数内部代码,在每个需要的地方添加print语句,运行一次只能获取一次信息,下次换个地方又得重新添加print语句.而且有时候,事先并不知道该去哪打印.或者打印什么内容,需要通过运行中获取的信息才能确定. 当print大法无法满足我们的需求时,就需要类似断点调试这样更高级的调试功能.本文将从零开始编写一个Lua调试器,实现类似gdb的断点调试功能. 本文代码已开

1. 普通断点 根据代码行数设置断点是最常见的一种方式,在debug程序运行前就可以进行断点的配置.如: (gdb) b src/main.cpp:127 当程序执行到main.cpp文件的第127行时就会出发断点. 2. 条件断点 顾名思义,这种断点是当满足一定条件时才会触发,比较适合进行异常排查.设置方式(gdb)break line-or-function if (condition), 如: (gdb) b src/main.cpp:127 if cnt==10 3. 数据断点 就是根据

http://sourceware.org/gdb/current/onlinedocs/gdb/ 断点设置 gdb断点分类: 以设置断点的命令分类: breakpoint 可以根据行号.函数.条件生成断点. watchpoint 监测变量或者表达式的值发生变化时产生断点. catchpoint 监测信号的产生.例如c++的throw,或者加载库的时候. gdb中的变量从1开始标号,不同的断点采用变量标号同一管理,可以 用enable.disable等命令管理,同时支持断点范围的操作,比如有些命

前面已经支持了几种不同的方式添加断点,但是必须事先在代码中添加断点,在使用上不是那么灵活方便.本文将支持动态增删断点,只需要开一开始引入调试库即可,后续可以在调试过程中动态的添加和删除断点.事不宜迟,我们直接进入正题. 源码已经上传Github,欢迎watch/star. 本博客已迁移至CatBro's Blog,那是我自己搭建的个人博客,欢迎关注.本文链接 实现分析 入口断点 尽管我们目标是支持动态添加断点,但还是需要一个入口,提供用户添加初始的断点.仍然像之前一样,在用户代码中显式添加的确可

在前一篇01最小实现中,我们实现了Lua断点调试的的一个最小实现.我们编写了一个模块,提供了两个基本的接口:设置断点和删除断点. 虽然我们已经支持在断点进行变量的打印,但是需要自己指定层数以及变量索引,使用起来不是很方便.要进行upvalue打印的话,操作会更加麻烦.为了提升调试的方便性,我们决定封装一个通用的变量打印函数,可以通过变量名查找到对应变量的值进行打印.支持局部变量.upvalue以及全局的_ENV中的变量. 本文代码已开源至Github,欢迎watch/star. 本博客已迁移至C

在前面两篇01最小实现及02通用变量打印中,我们已经实现了设置断点.删除断点及通用变量打印接口. 本篇将继续新增两个辅助的调试接口:调用栈回溯打印接口.通用变量设置接口.前者打印调用栈的回溯信息,后者可以方便地修改变量的值,支持局部变量.upvalue以及全局的_ENV中的变量. 本文代码已开源至Github,欢迎watch/star. 本博客已迁移至CatBro's Blog,那里是我自己搭建的个人博客,欢迎关注. 调用栈打印函数 我们首先来实现调用栈回溯打印接口printtraceback(

在第一篇的01最小实现中,我们实现了一个断点调试的最小实现,在设置钩子函数时只加了line事件,显然这会对性能有很大的影响.而后来两篇02通用变量打印和03通用变量修改及调用栈回溯则是提供了一些辅助的调试接口,并没有对钩子函数进行修改. 我们本篇将在钩子中引入call和return事件的处理,尝试对性能进行优化. 源码已经上传Github,欢迎watch/star. 本博客已迁移至CatBro's Blog,那里是我自己搭建的个人博客,欢迎关注. 实现分析 当前的实现因为只加了line事件,执行

在上一篇04优化钩子事件处理中,我们在钩子函数中引入了call和return事件的处理,对性能进行了优化. 细心的同学可能已经发现了,我们的hook函数中call事件和line都需要对整个断点表进行遍历,这其中其实是存在着一些冗余的.因为call事件只关心函数是否有断点,而line事件则只关心本函数内有哪些断点.所以我们可以想办法优化一下断点信息的数据结构,进一步提升性能. 源码已经上传Github,欢迎watch/star. 本博客已迁移至CatBro's Blog,那里是我自己搭建的个人博客

前面两篇我们对性能做了一个优化,接下来继续来丰富调试器的特性. 我们前面提到过,函数内并不是所有行都是有效行,空行和注释行就不是有效行.我们之前在添加断点的时候,并没有对行号进行检查,任何行号都能成功添加断点.所以如果添加的断点行号是无效的,那么永远也不会断到那里.但是钩子里并不知道它是无效的,call事件仍然会以为函数有断点从而启动line事件,造成CPU的浪费. 所以本篇,我们将对断点的行号进行检查,对于不在函数范围内的行号直接添加断点失败:在函数范围内的行号则自动修正为下一个有效的行号:另

我们之前已经支持了通过函数来添加断点,并且已经支持了行号的检查和自动修正.但是通过函数来添加断点有一些限制,如果在当前的位置无法访问目标函数,那我们就无法对其添加断点. 于是,本篇我们将扩展断点设置的接口,支持通过函数名称添加断点,以突破这个限制. 源码已经上传Github,欢迎watch/star. 本博客已迁移至CatBro's Blog,那是我自己搭建的个人博客,欢迎关注.本文链接 实现分析 由于Lua是动态类型语言,变量可以是任何值.而函数在Lua语言中又是第一类值,与其他值一样使用,可

在前一篇中我们支持了通过函数名称来添加断点,我们同时也提到了在Lua中一个函数的名称的并不是确定的.准确的说,Lua中的函数并没有名称,所谓名称其实是保存这个函数值的变量的名称. 于是通过函数名称添加断点就造成了一定的不确定性,因为函数被调用时并不一定是以这个名字被调用的.另外,多个不同的函数也可能以相同的名字进行调用. 所以为了解决这个问题,本篇我们将继续扩展断点的设置接口,支持通过包名来添加断点.因为包名相对更具确定性,配合行号可以进行精确定位. 源码已经上传Github,欢迎watch/s

之前说过断点调试,但是针对的是单文件的断点调试.在实际应用中,一个项目是多目录多文件的 参考资料:gdb debugger 目录结构: $ tree .├── gdbSomeFiles.cpp├── Libs│   ├── add.cpp│   ├── add.h│   └── makefile└── makefile add.h #pragma once class CAdd { public: CAdd(void); int add(int &a, int &b); virtual ~

刚开始在linux下学编程使用gdb的同学可能会发现,每次用gdb设置断点调试程序,但下次打开的时候所有断点都没有了,很不方便.下面介绍保存和读取断点的方法. 1. 保存断点 先用info b 查看一下目前设置的断点,使用save breakpoint命令保存到指定的文件,这里我使用了和进程名字后面加bp后缀,你可以按你的喜好取名字. 我使用的是save breakpoint fig8.3.bp 2. 读取断点 注意,在gdb已经加载进程的过程中,是不能够读取断点文件的,必须在gdb加载文件的命

GDB调试 启动程序准备调试 GDB yourpram 或者 先输入GDB 然后输入 file yourpram 然后使用run或者r命令开始程序的执行,也可以使用 run parameter将参数传递给该程序 参数列表 命令 命令缩写 命令说明 list l 显示多行源代码 break b 设置断点,程序运行到断点的位置会停下来 info i 描述程序的状态 run r 开始运行程序 display disp 跟踪查看某个变量,每次停下来都显示它的值 step s 执行下一条语句,如果该语句为

程序中除了一目了然的Bug之外都需要一定的调试手段来分析到底错在哪.到目前为止我们的调试手段只有一种:根据程序执行时的出错现象假设错误原因,然后在代码中适当的位置插入 printf ,执行程序并分析打印结果,如果结果和预期的一样,就基本上证明了自己假设的错误原因,就可以动手修Bug了,如果结果和预期的不一样,就根据结果做进一步的假设和分析. 本章我们介绍一种很强大的调试工具 gdb ,可以完全操控程序的运行,使得程序就像你手里的玩具一样,叫它走就走,叫它停就停,并且随时可以查看程序中所有的内部状

本课的核心内容如下: run 命令 continue 命令 break 命令 backtrace 与 frame 命令 info break.enable.disable 和 delete 命令 list 命令 print 和 ptype 命令 为了结合实践,这里以调试 Redis 源码为例来介绍每一个命令,先介绍一些常用命令的基础用法,某些命令的高级用法会在后面讲解. Redis 源码下载与 debug 版本编译 Redis 的最新源码下载地址可以在 Redis 官网获得,使用 wget 命令

一 单步执行和跟踪函数调用 先给出一段代码,可以用下面介绍的例子. #include <stdio.h> int add_range(int low, int high) { int i, sum; for (i = low; i <= high; i++) sum = sum + i; return sum; } int main(void) { ]; result[] = add_range(, ); result[] = add_range(, ); printf(], resul

gdb thread apply all bt 如果你发现有那么几个栈停在 pthread_wait 或者类似调用上,大致就可以得出结论:就是它们几个儿女情长,耽误了整个进程. 注意gdb的版本要高于7.0,之前使用过gdb6.3调试多线程是不行的. 从上图可以看出两个线程都阻塞在wait上,而且还给出了在哪一行代码中,很容易就定位到产生死锁的位置. 有时候线程太多,想写到文件里,可以: (gdb)set logging file <文件名> (gdb)set logging on (gdb)

gdb调试命令 1>. 启动gdb gdb 可执行程序的名字 2>. 查看代码 l -- 查看当前文件 -- 默认main函数 2. 查看其它文件: l 文件名:行号, 显示指定行号的上下文 l 函数名 -- 当前文件 l 文件名:函数名 -- 指定文件 3. 查看默认显示的行数: show listsize 4. 设置: set listsize 行数 3>. 断点操作 1. 当前文件设置断点: b(break) 行号 2. 指定文件: b 文件名:行号 b 函数名 -- 当前文件的这