Arm+linux+qt 应用调试技巧

本文简单说明调试arm+linux上层应用一般化技巧

抛开逻辑错误不谈，计算机上层软件开发中碰到的问题主要是段错误、内存泄露、cpu占用，本文对段错误的问题的处理做些简单经验介绍。

对于入行新人调试段错误也颇有难度，这里主要介绍一些段错误处理的简单技巧。

Linux平台最常用且强大的调试工具主要还是gdb，当我们的开发板比如arm的应用崩溃该当如何？可做如下对待：

1.运行前通过如下指令解放系统对core文件限制

ulimit -c unlimited

ulimit -d unlimited

2.当程序崩溃收集系统给出的core，其中包含充分的程序崩溃时信息。

3.运行arm-linux-gdbxxxx/app xxxx/core

其中xxxx代表app及core所在路径。

4.在gdb字符界面输入setsysroot xxxx，指定交叉环境的参考系统以便调试器能定位到程序需要的动态库，参考系统中的库通常是带调试信息的。当然，这里也可以直接通过set solib-search-path xxxx 指定具体的库路径，其中xxxx分别表示参考系统或具体库的路径。

5.通过info share命令查看库是否加载成功，列出信息中若Syms Read列都为Yes则加载成功。

6.在gdb字符界面通过bt命令打印出来崩溃线程的调用堆栈。

 

 

通常在这里我们会发现调用堆栈中最后的调用不一定是我们的代码，有可能是某些第三方库或者标准库中的代码，我们沿着栈往外层调用追查到自己代码，若审查确定自己代码查不出问题可以考虑查看库中源码，每一层栈都会打印出程序在代码中执行的位置及内层的入口代码片段，具体到文件名：行，我们可以在参考系统中通过find函数搜索相应源文件，如果有则进入查看，以便确认问题来自依赖库。

 

 

可以通过infothread子命令查看程序崩溃时刻的所有线程，并可以通过

thread id(这里的id不是线程id，而是gdb对线程的编号，可以在info thread中看到)命令切换到相应线程调用栈。

在某个具体调用栈中可通过up/down命令在调用栈框之间移动，通过

Info local命令查看当前栈框中的栈上变量，但是这里只能查看到c语言中基本类型内容，在qt中会经常用到QString类型表示字符串，这里给出查看QString内容的方法。

在gdb中可以自定义一些函数来扩充gdb能力，可以通过在$HOME/.gdbinit文件实现，该文件位置对PC本地GDB及交叉环境GDB同样适用。

文件内容如下:

define printqstring

   printf "(QString)0x%x(length=%i): \"",&$arg0,$arg0.d->size

   set $i=0

   while $i <$arg0.d->size

       set$c=$arg0.d->data[$i++]

       if $c < 32 || $c> 127

           printf"\\u0x%04x", $c

       else

           printf"%c", (char)$c

       end

   end

   printf"\"\n"

end

 

 

使用中在gdb某个栈框下输入

Info local //查看本栈框栈变量

printqstring var查看var内容，其中var是QString类型变量。