目录
问题描述
已有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定位问题原因
小结
随机性问题，问题一旦发生，保存现场十分重要，不知道何时才会复现，要基于当前的设备状态，尽可能的去追溯本次的问题，这样才能有效的解决问题。
