这是我在 Qt 支持论坛上的帖子的 x-post，因为我认为它很奇怪而且很有趣，你们也可以在这里帮助我。
我将尝试解释我遇到的一个问题——这是一个非常奇怪的问题，所以在我尝试解释它时请耐心等待。
让我先概述一下我的申请。它是一个在 Windows XP 上用 Qt 4.7 编写的简单的“串行数据记录器”类型的程序；它基本上接收串行端口上的通信（使用 QExtSerialPort），进行一些处理以从这些通信中提取数据，然后将这些数据推送到前端 GUI 并将其输出到日志文件。我还使用 qDebug() 在各个点将通信和数据传到应用程序输出，因此我可以监控应用程序内部的流动情况。
为清楚起见，如果您没有使用它，QExtSerialPort 只是在串行端口接收到字节时发出一个信号，并使用 QByteArray 将它们传递到连接的插槽。
所以现在我的问题是——我的应用程序最初运行良好，但大约 5 到 10 分钟后，整个事情锁定并停止工作，迫使我崩溃。
在调试器中对此进行了进一步调查后，我注意到了一件非常奇怪的事情。
通信流相当稳定，因此通过监视调试器中的“应用程序输出”窗格，我可以立即看到程序何时锁定，因为似乎没有更多通信到达。如果此时，我单击并将我的应用程序的窗口拖动到屏幕的另一部分，通信开始进入并被处理，然后它停止并再次锁定，直到我再次移动窗口，然后它将允许更多数据等等等等......我已经尝试了一段时间，每次我在屏幕上移动窗口时，它都允许程序接收通信和处理。如果我打开窗口左上角的系统菜单（使用 ALT 空格），这似乎也允许在打开时处理通信。
因此，我在这里的有限推论似乎将我引向了这样一个理论，即由于这些动作中的每一个都会阻止重新绘制窗口，那么 GUI/重新绘制动作一定会阻止我的通信进入。
此外，数据使用两个插槽推送到 GUI，更有趣的是（我认为）如果我删除与这些插槽的连接，从而不允许在我的代码中与 GUI 类进行交互，应用程序运行良好并且永远不会锁定所有进入日志文件和应用程序输出的数据。但是这些插槽非常简单，只检查某些组合框的状态来决定是否更新某些文本字段。
有没有人见过这样的东西？有人对可能发生的事情有任何想法吗？