我有一个使用测试用例产生致命错误的程序，我可以通过读取日志和致命的堆栈跟踪找到问题 - 事实证明在空指针上有一个读操作。
但是当我尝试将gdb附加到它并在可疑代码周围设置断点时，就无法观察到空指针！该程序运行顺利，没有任何错误。
这是一个单进程，单线程程序，我以前没有经历过这种事情。谁能给我一些评论？感谢。
附加：我还尝试在致命触发器代码之前调用pause（）系统调用，并期望使程序在致命点之前进入睡眠状态，然后即时将gdb附加到其上，遗憾的是，没有发生致命事件。
答案 0 :(得分：2)
没有查看代码只是猜测，但调试器有时会这样做：
我没有关于GDB的引用，但我在valgrind上有一个引用（授予两个狂野不同的东西..）
My program crashes normally, but doesn't under Valgrind, or vice versa. What's happening?
当一个程序在Valgrind下运行时， 它的环境略有不同 当它本地运行时。例如， 内存布局不同，而且 线程的安排方式是 不同。
GDB也是如此。
大部分时间这都没有 差异，但它可以，特别是 如果你的程序有问题。
因此，您的计划可能存在真正的问题。
答案 1 :(得分：1)
可能会发生一些事情..应用程序的时间可以更改，因此如果它是一个多线程应用程序，您可能首先设置就绪标志然后将数据复制到缓冲区，而无需调试器附加其他线程可能会在填充缓冲区或设置某个指针之前访问缓冲区。
某些应用程序也可能具有反调试功能。在调试器中运行时，可能永远不会触及这段代码。
分析它的一种方法是使用核心转储。您可以通过ulimit -c unlimited创建然后启动应用程序，当核心被转储时，您可以使用gdb ./application ./core将其加载到gdb中。您可以在此处找到有用的文章：http://www.ffnn.nl/pages/articles/linux/gdb-gnu-debugger-intro.php
答案 2 :(得分：0)
如果对指针的读取无效，则可能出现不可预测的行为。既然你已经知道是什么导致了这个错误，你应该尽快摆脱它。通常，在处理错误的指针操作时会出现意外情况。