如何破解这个bug，我已经没有什么好想法了。 我有1000行代码每2或3次崩溃崩溃。 它目前是用C编写的原型命令行应用程序。问题是它是专有的，我不能给你源码，但我很乐意将一个debugging编译的可执行文件发送给Debian Squeeze x86_64机器上的任何勇敢的灵魂。
这是我到目前为止：
当我在GDB中运行它时，它总是成功完成。
当我在Valgrind中运行它时，它总是成功完成。
这个问题似乎来自非常基本的recursion函数调用。 为了在这个recursion函数中指出错误，我在单独的应用程序中编写了相同的函数。 它总是成功地完成。
我build立了我自己的gcc 4.7.1编译器，编译了我的代码，而且我仍然得到相同的行为。
将我的应用程序转移到另一台机器，以消除硬件问题的风险，我仍然得到相同的行为。
将我的源代码转换到另一台机器，以消除损坏的构build环境的风险，我仍然得到相同的行为。
该应用程序是单线程的，没有信号处理，可能会导致竞争条件。 我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)
有没有可以帮助我的工具？ 如果你是我的职位，你会怎么做？
谢谢！
这正是让我走向正确的方向 – 我已经使用过的超市 – 墙。
谢谢！！！ 这真的让我发疯
我在评论中建议：
-Wall -Wextra编译并改进源代码直到不给出警告; -g和-O编译; 这有助于使用gdb检查转储的核心文件（您可能希望设置足够大的coredump大小限制，例如ulimit bash内建） ltrace或strace 显然， -Wextra很有帮助。 这将是很好的理解为什么和如何。
顺便说一句，对于较大的程序，你甚至可以添加自己的警告，海湾合作委员会扩大与MELT ; 这可能需要几天时间，而且大部分项目都是值得的。
在这种情况下，我认为你有一些内存问题（仔细看valgrind的输出），导致GDB和valgrind通过添加一些内存跟踪功能（所以你的原始地址被改变）来改变原来的程序。 你可以用-ggdb选项编译并设置coredump（ ulimit -c unlimited ），然后试着分析一下是怎么回事。 这个链接可能会帮助你：
http://en.wikipedia.org/wiki/Unusual_software_bug
问候。