c++ - 臭名昭著的 printf 修复

Question

根据我的经验，我在使用 printf(或任何其他标准输出日志记录)进行调试时遇到了一些奇怪的行为。

行为 1:

一个常见的情况是，当在多线程应用程序中使用 printf 以查找某些错误发生的原因时，使用 printf 突然“修复”了错误(在积极调用的地方使用 printfs，导致巨大的输出).

在这种情况下，我认为 printf 增加了一些延迟，因此可能有一些低优先级线程无法获得 CPU，所以我开始朝那个方向看。

我关注奇迹 printf 修复的另一个方向是同步，因为我推测对 printf 的调用虽然是多线程的，但在系统后面是同步的，因此使用 printf 的不同线程通过等待彼此来同步完成写入 I/O 缓冲区。

Q1:关于第一种情况，我的两个假设是否正确？

Q2:发生这种情况时，我是否应该考虑其他方向？

行为 2:

这种情况很少发生，但遇到这种情况时，即使是高级开发人员也会质疑自己，我真的很感激对此的解释。

它是这样的:

• 代码不工作...(清理、编译、运行)
• 代码仍然无法运行，因此您添加一个 printf 以查看原因(清理、编译、运行)
• 代码开始正常工作....您删除之前添加的 printf(清理、编译、运行)
• 代码现在可以正常工作了!!!!!!!!!!! (挠头，难以置信地瞪着眼睛)。

在实践中，我多次使用这种方法，这种修复 CPU 的方法可能会在它发生时多次使用这种方法:Android "cpu may be pegged" bug .

它实际上非常有效，以至于它成为了一个众所周知的“修复”(如果第一次尝试不起作用，您只需重复该过程，直到它消失)。

请注意，代码已正确清理，这绝不是与旧编译对象链接的问题。

最流行的猜测之一是编译后的代码是不同的，原因不明(编译器是否根据特定文件的行有一些随机性，包括空格？)。

问题 3:这种行为的原因可能是什么(我也愿意接受猜测)？即使代码相同，编译器能否生成不同的程序集？

请注意，我正在谈论的项目非常大，有多个静态库，因此这些行为无法在小代码片段上复制(尽管我听说过场景 2 发生在单文件程序上好吧)。

Answer 1

问题 1:您可以简单地通过查找来自两个不同 printf 的交错字符来判断 printf 是否在幕后同步。如果没有交错，那么 printf 就是同步的。我希望这比 CPU 占用更有可能解决问题。

问题 2:我会寻找没有适当互斥保护的共享资源。

Q3:编译器可能会在优化过程中使用随机数。例如，如果编译器有 32 个变量和 8 个寄存器要放入，它可能会“掷骰子”来决定将哪些变量放入寄存器。您可以通过禁用优化来测试这个理论。没有优化，输出应该是一致的。您可以通过比较双星来检验那个理论。