目录

问题描述

已有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定位问题原因

小结

        随机性问题，问题一旦发生，保存现场十分重要，不知道何时才会复现，要基于当前的设备状态，尽可能的去追溯本次的问题，这样才能有效的解决问题。