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