1. 知记首页
  2. 编程

GDB与Chrome DevTools实战调试指南：程序员必学的BUG定位技巧

• 编程 • 阅读 4

GDB：C/C++代码的“BUG显微镜”

作为C/C++程序员的调试利器，GDB的核心价值是精准定位代码执行过程中的状态变化。先从基础配置说起——很多人忽略了~/.gdbinit文件，它能让你的GDB用起来更顺手：

GDB与Chrome DevTools实战调试指南：程序员必学的BUG定位技巧

# ~/.gdbinit 常用配置（直接复制到你的家目录下）
set line-number on         # 显示行号
set pagination off         # 禁用分页（避免按回车翻页）
set print pretty on        # 格式化打印结构体（比如链表、树节点更易读）
set print array on         # 打印数组时显示索引
set auto-load safe-path /  # 允许加载系统库的调试信息

常用命令：从启动到断点的核心流程

GDB的命令看似多，其实高频用的就10个左右，咱们按调试流程列出来：

  1. 启动与附加：
  2. 直接运行程序：gdb ./your_program（替换为你的可执行文件）

  3. 附加到正在运行的进程：gdb -p 1234（1234是进程ID，用ps -ef | grep your_program找）

  4. 设置断点：

  5. 按行号：break main.c:100（main.c第100行）
  6. 按函数名：break calculate_sum（calculate_sum函数入口）

  7. 条件断点（最实用！）：break main.c:50 if i == 10（当i等于10时才断）
    比如你有个循环for(int i=0; i<20; i++)，想看看i=10时的变量状态，用条件断点直接跳过前面9次，省时间！

  8. 运行与单步调试：

  9. 启动程序：run（如果是附加进程，用continue）
  10. 单步进入函数：step（缩写s）
  11. 单步跳过函数：next（缩写n）

  12. 继续执行到下一个断点：continue（缩写c）

  13. 查看变量与内存：

  14. 打印变量：print i（缩写p i）
  15. 打印指针指向的内容：print *ptr（比如ptr是int*，会显示它的值）
  16. 监视变量（变化时断点）：watch total（total变量改变时立刻停住）
  17. 查看内存：x/10xw 0x7fffffffde80（从地址0x7fffffffde80开始，显示10个4字节的十六进制值）

核心Dump分析：解决程序崩溃的终极武器

程序突然崩溃并生成core文件？别慌，GDB能帮你还原现场：
1. 先确认系统允许生成core文件：ulimit -c unlimited（临时生效，重启后需要重新设置）
2. 用GDB打开core文件：gdb ./your_program core
3. 查看调用栈：backtrace（缩写bt）——直接告诉你程序崩溃在哪个函数、哪一行！
比如下面的结果，立刻知道是divide函数里除数为0导致的崩溃：

(gdb) bt
#0  divide (a=5, b=0) at test.c:5
#1  0x000055555555475c in main () at test.c:12

再用frame 0切换到崩溃的栈帧，print b就能看到b的值是0——问题根源找到了！

Chrome DevTools：前端问题的“全能诊断仪”

前端调试的痛点是什么？样式乱了、JS不执行、页面加载慢、接口报错……Chrome DevTools的5个核心面板（Elements、Console、Sources、Network、Performance）能覆盖90%的问题。

Elements：实时修改样式与DOM

你是不是经常改了CSS又刷新页面？Elements面板能实时生效，省掉重复刷新的时间：
– 点击左边的元素（比如<div class="header">），右边的Styles面板会显示它的所有CSS规则；
– 直接修改数值：比如把font-size: 16px改成20px，页面立刻变大；
– 新增样式：点击Styles面板的+号，输入color: red，元素立刻变红；
– 复制CSS：右键元素→Copy→Copy CSS Path，直接拿到这个元素的CSS选择器（比如.header .logo）。

Console：JS的“调试控制台”

Console不止是打印日志，还有很多隐藏技巧：
1. 打印复杂对象：用console.dir(obj)（比console.log(obj)更详细，能展开对象的所有属性）；
2. 占位符：console.log("用户ID：%d，名称：%s", 123, "张三")（%d是数字，%s是字符串）；
3. 执行JS代码：直接输入document.title = "新标题"，页面标题立刻变（不用改代码再刷新）；
4. 查找日志：按Ctrl+F搜索关键词（比如找“error”日志）。

Sources：JS代码的“断点实验室”

前端调试JS的核心面板，重点讲2个实用技巧：
– 条件断点：找到你要调试的JS文件（比如app.js），点击行号左边的空白处设置断点，然后右键断点→Edit breakpoint，输入条件（比如i > 5）——当条件满足时才断；
– Watch表达式：在Sources面板右边的Watch栏点+，输入你要监视的变量（比如totalPrice）——断点时会自动显示它的值，不用每次都打console.log；
– 暂停在异常处：点击Sources面板右上角的Pause on exceptions（暂停按钮旁边的感叹号），JS抛出异常时会自动断点——比如你的代码throw new Error("参数错误")，刷新页面就会停在这一行，直接看错误原因。

Network：网络请求的“侦探”

页面加载慢？接口报错？用Network面板一查就知道：
– Preserve log：勾选左上角的Preserve log（保留日志）——页面跳转时不会清空请求记录，方便查看跳转前的接口；
– Throttling：模拟慢网络（比如选择Slow 3G）——看看你的页面在慢网下的加载情况，比如图片太大导致加载慢，立刻就能发现；
– 查看响应体：点击一个请求→Response标签——比如接口返回{"code":400,"msg":"参数错误"}，直接看哪里错了；
– 过滤请求：用顶部的Filter输入关键词（比如api）——只显示包含api的请求，排除静态资源（比如CSS、JS）。

Performance：页面性能的“体检报告”

页面卡顿？用Performance面板找原因：
1. 点击Record（红色圆点）→ 刷新页面 → 点击Stop；
2. 看Main线程的任务条：红色的长任务（超过50ms）就是卡顿的原因——比如一个JS函数执行了100ms，会阻塞页面渲染；
3. 展开任务条：点击红色任务条→Bottom-Up标签——能看到这个任务的具体函数（比如renderList），直接定位到耗时的代码。

最后想说：调试的核心是“找差异”

不管用GDB还是Chrome DevTools，调试的本质都是对比“预期状态”和“实际状态”的差异——比如你以为i=10时变量total是50，但实际是0，那就要看i=10时的计算过程；比如你以为按钮点击后会发接口，但实际没发，就要看点击事件的回调函数有没有执行。

多练几次这些技巧，你会发现：以前要花1小时找的BUG，现在10分钟就能搞定——这就是调试工具的威力！

原创文章，作者：，如若转载，请注明出处：https://zube.cn/archives/293

赞 (0)
0