Linux下 debug手段

本文介绍了在Linux环境下进行程序调试的多种工具和技术,包括日志、strace、pstack、gdb、coredump等,并提供了具体使用场景及技巧。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

在linux下开发难免会遇到bug,但是由于没有图形IDE,导致debug也变得困难,其实只要掌握一些常用的debug工具,一些错误就能很快解决,本文就介绍一些常用的工具用以调试:

1. log

log永远是最简单快捷的调试方式,可以快速定位bug,通过设置日志级别控制日志的输出详略程度,结合一些文本分析工具awk/sed/grep可以快速在大量日志中找到错误信息。

2. strace

strace是一个用来跟踪系统调用的简易工具。

它最简单的用途就是跟踪一个程序整个生命周期里所有的系统调用,并把调用参数和返回值以文本的方式输出。Strace还可以跟踪发给进程的信号。支持attach正在运行的进程  strace -p <pid>, 当多线程环境下,需要跟踪某个线程的系统调用,可以先ps -efL | grep <Process Name> 查找出该进程下的线程,然后调用starace –p <pid>进行分析。

3. pstack

pstack 用来跟踪进程栈,比如我们发现一个服务一直处于work状态(如假死状态,好似死循环),使用这个命令就能轻松定位问题所在;可以在一段时间内,多执行几次pstack,若发现代码栈总是停在同一个位置,那个位置就需要重点关注,很可能就是出问题的地方;

4. gdb

经典的调试工具,功能很强大,

注意此时编译的时候应该使用 -g 选项,并用-Og进行优化。多线程下可以attach到进程来调试。

段错误触发时,GDB会直接告诉我们问题出现在哪一行代码,并且可以利用backtrace命令查看完整调用栈信息。此外,还可以利用其他常规调试命令来查看参数、变量、内存等数据。

注:这种方式虽然非常有效,但很多时候,问题并不是100%必现的,我们不可能一直把程序运行在GDB中,这对程序的执行性能等会有很大的影响。

这时,我们可以让程序在异常终止时生成core dump文件,然后用调试工具对它进行离线调试。

5. core dump

Core dump是Linux提供的一种非常实用的程序调试手段,在程序异常终止时,Linux会把程序的上下文信息记录在一个core文件中,然后可以利用GDB等调试工具对core文件进行离线调试。

很多系统中,根据默认配置,程序异常退出时不会产生core dump文件。可以通过下面这条命令查看:

ulimit -c

如果值是0,则默认不会产生core dump文件。可以用下面命令设置生成core dump文件的大小:

ulimit -c 10240

上面命令把core dump文件大小设置为10MB。如果存储空间不受限的话,可以直接取消大小限制:

ulimit -c unlimited

段错误(segmentation fault ):9种实用调试方法,你用过几种?

 

然后重新运行示例程序,段错误触发后,默认会在当前目录下生产一个core文件:

段错误(segmentation fault ):9种实用调试方法,你用过几种?

 

然后用GDB加载调试core文件。调试时,除了core dump文件外,GDB还需要从可执行文件中加载调试信息。

gdb segfault core

结果如下图:

段错误(segmentation fault ):9种实用调试方法,你用过几种?

与直接在GDB运行程序类似,core dump文件加载起来之后,GDB会直接显示触发问题的那一行代码,也可以使用backtrace、print等常规命令从core dump文件中获取信息。

在大多数系统中,这种core dump + GDB的手段非常有效,而且应该优先考虑使用。

但是有时候,由于某种原因,系统可能无法生存core dump文件。比如出于安全考虑,core dump功能可能是被彻底禁止的,或者在一些存储空间受限的嵌入式系统中,也无法生成core dump文件。

此时,我们就不得不考虑其它的调试手段了

 

 

6. algrind

包含很多工具:

Memcheck。这是valgrind应用最广泛的工具,一个重量级的内存检查器,能够发现开发中绝大多数内存错误使用情况,比如:使用未初始化的内存,使用已经释放了的内存,内存访问越界等。这也是本文将重点介绍的部分。

Callgrind。它主要用来检查程序中函数调用过程中出现的问题。

Cachegrind。它主要用来检查程序中缓存使用出现的问题。

Helgrind。它主要用来检查多线程程序中出现的竞争问题。

Massif。它主要用来检查程序中堆栈使用中出现的问题。

Extension。可以利用core提供的功能,自己编写特定的内存调试工具。

默认使用的就是memcheck工具,在c++中指针的使用,一不留神就会产生异常,就可以利用memcheck进行检查。个人一般用--track-origins=yes来定位未初始化变量的位置。

7. tcpdump

抓包用的,在开发网络应用的时候很给力,结合awk/sed/grep可以快速查找网络数据包。

stackoverflow

这个网站是个程序设计领域的问答网站,基本碰到的问题都能在这里面找到答案! 技术氛围很强,从中能学到很多东西。

 

参考文档:

https://www.toutiao.com/i6833639010007515659/?tt_from=weixin&utm_campaign=client_share&wxshare_count=1&timestamp=1622627837&app=news_article&utm_source=weixin&utm_medium=toutiao_android&use_new_style=1&req_id=202106021757170101351641034902A651&share_token=fddd9bdc-8b90-42ff-8c79-86380d62f3bb&group_id=6833639010007515659&wid=1622628245619

<think>好的,用户之前问过kgdb的使用方法,现在想了解Linux内核调试手段。我需要先回忆一下之前提供的kgdb相关内容,确保这次回答不重复,同时覆盖其他常用方法。用户可能是开发者或系统管理员,可能在进行内核开发或故障排查,需要全面的调试方法,包括工具、步骤和适用场景。 首先,得确定用户的基础,可能已经了解kgdb,所以需要补充其他方法。常见的调试手段包括printk、动态调试、kprobes、systemtap、ftrace、kdump、gdb/qemu调试等。每个方法的优缺点和适用场景需要明确区分,帮助用户根据情况选择。 接下来,考虑结构。用户可能需要一个清晰的分类,比如日志类、动态追踪类、崩溃分析、交互式调试、模拟调试等。每个类别下列举工具,说明使用步骤和示例,这样用户容易查找和参考。 还要注意用户可能的痛点,比如生产环境下的使用限制,需要非侵入式方法,或者需要实时追踪性能问题。例如,printk虽然简单但可能影响性能,而ftrace和perf更适合生产环境。kdump用于崩溃后的分析,而kgdb用于实时调试。 需要检查是否有遗漏的重要工具,比如drgn这个新兴的内核调试工具,或者用户可能遇到的常见问题,比如oops信息分析。此外,提醒用户注意内核配置选项,比如CONFIG_DEBUG_INFO等,这些是使用某些工具的前提。 最后,确保语言简洁,步骤明确,示例代码正确,避免使用用户可能不熟悉的术语,必要时提供命令示例和配置建议。同时,注意用户可能的应用场景,比如调试驱动模块、排查死锁或内存泄漏,针对不同场景推荐合适的工具组合。</think>#### 一、Linux内核调试核心方法概览 ```text [调试工具分类] │ ├── 日志分析类(printk/dmesg、动态调试) ├── 动态追踪类(kprobes、ftrace、perf、eBPF) ├── 崩溃分析类(kdump/crash、Oops解析) ├── 交互调试类(KGDB、QEMU+GDB) └── 模拟调试类(User-Mode Linux、QEMU虚拟化) ``` --- #### 二、关键调试手段详解 ##### 1. **基础日志调试(printk/dmesg)** ```c // 内核代码中添加(支持优先级): printk(KERN_ERR "Error at %s:%d\n", __FILE__, __LINE__); // 用户空间查看(带时间戳): $ dmesg -T --level=err,warn ``` **适用场景**:快速定位代码执行路径,需重新编译内核 ##### 2. **动态调试(Dynamic Debug)** ```bash # 启用特定文件的调试信息 echo 'file drivers/usb/* +p' > /sys/kernel/debug/dynamic_debug/control # 查看当前激活的调试点 grep " [y] " /sys/kernel/debug/dynamic_debug/control ``` **优势**:无需重新编译内核,动态启用日志 ##### 3. **kprobes 动态插桩** ```bash # 跟踪open系统调用入口(需要CONFIG_KPROBES) echo 'p:myprobe do_sys_open filename=+0(%di):string' > /sys/kernel/debug/tracing/kprobe_events echo 1 > /sys/kernel/debug/tracing/events/kprobes/myprobe/enable ``` **输出分析**: ```text bash-1287 [000] ...1 3144.248783: myprobe: (do_sys_open+0x0/0x210) filename="/etc/profile" ``` ##### 4. **ftrace 函数追踪** ```bash # 记录schedule()函数的调用栈(需CONFIG_FUNCTION_TRACER) echo function > /sys/kernel/debug/tracing/current_tracer echo schedule > /sys/kernel/debug/tracing/set_ftrace_filter echo 1 > /sys/kernel/debug/tracing/options/func_stack_trace ``` **输出示例**: ```text bash-1297 [000] d..2 3145.123456: schedule <-do_syscall_64 bash-1297 [000] d..2 3145.123457: <stack trace> => schedule => do_syscall_64 => entry_SYSCALL_64_after_hwframe ``` ##### 5. **崩溃分析(kdump/crash)** ```bash # 配置kdump(需预留内存) $ kexec -p /boot/vmlinuz-$(uname -r) --initrd=/boot/initrd.img-$(uname -r) --append="crashkernel=256M" # 分析vmcore $ crash /usr/lib/debug/boot/vmlinux-$(uname -r) vmcore crash> bt -a # 查看所有CPU的堆栈 crash> kmem -i # 显示内存使用统计 ``` ##### 6. **QEMU+GDB 内核调试** ```bash # 启动QEMU虚拟机(带调试端口) qemu-system-x86_64 -kernel bzImage -append "nokaslr kgdboc=ttyS0,115200" -s -S -nographic # GDB连接调试 (gdb) target remote :1234 (gdb) hbreak start_kernel (gdb) continue ``` --- #### 三、调试技术对比表 | **方法** | 实时性 | 侵入性 | 学习曲线 | 适用阶段 | |----------------|--------|--------|----------|----------------| | printk | 低 | 高 | ★☆☆ | 早期开发 | | KGDB | 高 | 中 | ★★★ | 深层次逻辑错误 | | ftrace | 中 | 低 | ★★☆ | 性能分析 | | kprobes | 高 | 低 | ★★☆ | 动态追踪 | | kdump | 事后分析| 低 | ★★☆ | 生产环境崩溃 | --- #### 四、典型调试场景指南 ##### 场景1:内核Oops分析 ```text [ 3263.456789] BUG: unable to handle kernel NULL pointer dereference at 0000000000000050 [ 3263.456792] IP: my_module_write+0x25/0x50 [faulty] ``` **操作步骤**: 1. 通过`dmesg`获取Oops信息 2. 使用`addr2line -e vmlinux 0xffffffffa0000025`转换地址 3. 结合`objdump -dS faulty.ko`反汇编模块 ##### 场景2:死锁检测 ```bash # 使用lockdep检测(需CONFIG_DEBUG_LOCKDEP) echo 1 > /proc/sys/kernel/lockdep # 触发死锁后查看: dmesg | grep -i 'possible recursive locking' ``` ##### 场景3:内存泄漏追踪 ```bash # 启用kmemleak(需CONFIG_DEBUG_KMEMLEAK) echo scan > /sys/kernel/debug/kmemleak # 查看泄漏报告 cat /sys/kernel/debug/kmemleak ``` --- #### 五、关键内核配置选项 ```text CONFIG_DEBUG_KERNEL=y # 开启调试主开关 CONFIG_DEBUG_INFO=y # 包含调试符号 CONFIG_MAGIC_SYSRQ=y # 启用SysRq组合键 CONFIG_KPROBES=y # 动态插桩支持 CONFIG_KALLSYMS=y # 显示所有符号信息 CONFIG_DEBUG_SLAB=y # 内存分配跟踪 ``` --- #### 六、高级调试技巧 1. **利用SysRq组合键**: ```text Alt+SysRq+t - 显示所有任务堆栈 Alt+SysRq+w - 显示阻塞任务 Alt+SysRq+m - 输出内存统计 ``` 2. **使用drgn替代crash**: ```python # 现代Python调试工具(需安装drgn) $ drgn -c vmcore >>> task = find_task(pid) >>> print(task.comm) ``` 3. **eBPF高级追踪**: ```bash # 使用bpftrace统计系统调用次数 bpftrace -e 'tracepoint:syscalls:sys_enter_* { @[probe] = count(); }' ``` --- > **重要提示**: > 1. 生产环境优先使用低侵入性工具(如ftrace、eBPF) > 2. 调试前备份关键数据,部分调试操作可能导致系统不稳定 > 3. ARM架构需注意交叉调试环境配置
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值