目录
问题描述
已有coredump
没有coredump
小结
问题描述
Linux本机调试使用GDB非常方便,但嵌入式Linux设备资源有限,通常并没有交叉编译工具,那嵌入式设备上的应用发生问题如何查找问题?通常IDE有远程DEBUG功能,这种能快速定位固定且容易复现的错误。那么不定期发生,且位置不固定的Bug可能就要用到GDB了。
已有coredump
这种情况是app发生了crash,大多原因是非法访问内存,这个时候很容易能查到设备发生崩溃时,最后调用的堆栈,然后沿着前后调用查找问题即可,首先要开启linux设备的coredump功能:
- 是否需要根据应用程序不同的pid生成不同的coredump文件,0为不需要,主要考虑是空间问题。
echo 0 > /proc/sys/kernel/core_uses_pid
- 将生成的coredump文件重定向到自己的文件夹,方便查找。
echo home/app/log/coredump > /proc/sys/kernel/core_pattern
- 崩溃时生成无限制大小的coredump文件。
ulimit -c unlimited
- 接下来将发生问题的app和coredump文件放入linux环境中。
- 找到对应的交叉编译工具链,使用其进行调试。
sudo ./usr/local/oecore-x86_64/sysroots/x86_64-angstromsdk-linux/usr/bin/arm-angstrom-linux-gnueabi/arm-angstrom-linux-gnueabi-gdb app coredump
最终定位到问题所在。
没有coredump
个别情况下,并没有发生crash,但是程序卡死或者无响应,这个时候并不会生成coredump文件,那么就需要进行远程在线调试。
- 首先在设备端开启gdbserver服务
- 填入虚拟机Linux的IP和监听的端口
- 填入正在发生问题的应用进程,比如此处的561
gdbserver --attach 192.168.22.149:21 561
- 虚拟机linux端,则先打开gdb调试器:
sudo ./arm-angstrom-linux-gnueabi-gdb
- 然后在调试器命令行输入:
target remote 192.168.22.1:21
- gdb会读取当前进程的所有调用,并显示出卡死位置
- 最后使用指令bt full定位问题原因
小结
随机性问题,问题一旦发生,保存现场十分重要,不知道何时才会复现,要基于当前的设备状态,尽可能的去追溯本次的问题,这样才能有效的解决问题。