不使用调试工具的调试技术

Question

我发现自己处于一个艰难的境地，不得不在几乎没有任何调试工具的情况下调试Qt应用程序:应用程序似乎开始使用越来越多的CPU，因为它一次又一次地运行相同的操作；过了几个小时，CPU完全饱和。

该应用程序在ARM Linux嵌入式设备上运行，其中gdb似乎不能工作，可能是所提供的工具链难以发现的问题。strace似乎只报告计时器活动(这是一个OpenGL应用程序，所以这是预期的)。ltrace是不可用的，编译它会导致一项困难的任务，也许是无用的。这个应用程序不是我写的，但是源代码是可用的。

在消耗这么多资源时，我还能做些什么来发现应用程序在忙什么呢？有没有办法让我跟踪应用程序执行的所有方法调用？有没有其他的技巧可以让我试着去猜测问题或者把注意力集中在哪里呢？

编辑:这是gdb：Only question marks in backtrace reported by gdb on ARM的问题之一。即使是编写一个模拟段错误的十行应用程序，也会导致这种情况。

Answer 1

你能在机器上启用核心转储吗？然后，当它运行时，您可以向它发送一个SIGABRT，并将核心转储复制到您的开发机器上，然后使用交叉调试器检查它，并提供源代码和未剥离的可执行文件。

为下一次吸取惨痛的教训也很重要，不要使用如此糟糕的工具链。

如果可以，如果不支持gdb，您可以尝试另一个至少支持gdbserver的工具链。我对CodeSourcery ARM Lite工具链非常满意。

编辑:针对您的情况的gdb有两种风格：

• 是在开发主机上运行的跨地理数据库
• 是在目标

上运行的本机地理数据库

gdbserver允许您在开发主机上运行跨gdb，并连接到目标来远程调试在其上运行的内容。因此，核心转储或gdbserver是使用跨gdb检查目标上的某些内容的两种方法，但单独使用gdbserver不会对您有太大帮助。

如果您的交叉编译器类似于arm-none-linux-gnueabi-gcc，请查看您的开发主机上是否有可用的arm-none-linux-gnueabi-gdb。

Answer 2

您可以尝试在应用程序中放置一些调试代码。

选择一些信号，比如SIGINT。为此信号添加信号处理程序。在此处理程序中，打印堆栈跟踪或至少打印指令指针值。然后启动应用程序并多次发送SIGINT，以查看您的应用程序正在做什么。

Answer 3

尝试记录不同函数的执行时间。首先，记录最有可能的候选函数的执行时间，如果您已经排除了它们，则继续使用程序中其他不太可能的函数。

记录消息的最简单方法是使用std::cout (或printf)并将输出重定向到一个文件，以便以后可以看到日志。