2

关于如何破解这个错误，我已经没有好主意了。我有 1000 行代码，每运行 2 或 3 次就会崩溃。它目前是一个用 C 编写的原型命令行应用程序。一个问题是它是专有的，我不能给你源代码，但我很乐意将调试编译的可执行文件发送给 Debian Squeeze x86_64 机器上的任何勇敢的灵魂。

这是我到目前为止得到的：

  1. 当我在 GDB 中运行它时，它总是成功完成。

  2. 当我在 Valgrind 中运行它时，它总是成功完成。

  3. 这个问题似乎源于一个非常基本的递归函数调用。为了找出这个递归函数中的错误，我在一个单独的应用程序中编写了相同的函数。它总是成功完成。

  4. 我构建了自己的 gcc 4.7.1 编译器，用它编译了我的代码，但我仍然得到相同的行为。

  5. 将我的应用程序转移到另一台机器上以消除硬件问题的风险，我仍然得到相同的行为。

  6. 将我的源代码 FT 转移到另一台机器上，以消除构建环境损坏的风险，但我仍然得到相同的行为。

该应用程序是单线程的，并且不进行可能导致竞争条件的信号处理。我memset(,0,)都是大物件

没有外来依赖，ldd 如下。

ldd 给了我这个：

ldd tst 
    linux-vdso.so.1 =>  (0x00007fff08bf0000)
    libpthread.so.0 => /lib/libpthread.so.0 (0x00007fe8c65cd000)
    libm.so.6 => /lib/libm.so.6 (0x00007fe8c634b000)
    libc.so.6 => /lib/libc.so.6 (0x00007fe8c5fe8000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fe8c67fc000)

有什么工具可以帮助我吗？如果你处于我的位置，你的下一步是什么？

谢谢！

这就是让我朝着正确方向前进的原因 - Wextra 我已经使用过 -Wall。

谢谢！！！这真的让我发疯了。

4

2 回答 2

3

我在评论中建议：

  • 编译-Wall -Wextra 和改进源代码，直到没有给出警告；
  • 同时编译-g和-O; 这有助于检查转储的核心文件（您可能希望使用内置的 bashgdb设置足够大的 coredump 大小限制）ulimit
  • 向同事展示您的代码并解释问题？
  • 使用ltrace 或strace

显然-Wextra是有帮助的。很高兴了解为什么以及如何。

顺便说一句，对于较大的程序，您甚至可以通过使用MELT扩展它来向 GCC 添加自己的警告；这可能需要几天时间，而且主要在大型项目中是值得的。

于 2012-07-29T15:05:41.703 回答
0

在这种情况下，我认为您有一些内存问题（仔细查看 valgrind 的输出），导致 GDB 和 valgrind 通过添加一些内存跟踪功能来更改原始程序（因此您的原始地址被更改）。您可以使用选项编译-ggdb并设置 coredump ( ulimit -c unlimited)，然后尝试分析发生了什么。此链接可以帮助您：

http://en.wikipedia.org/wiki/Unusual_software_bug

问候。

于 2012-07-29T14:28:52.070 回答