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