问题背景 #

在单元测试场景中，我们需要为每个测试用例独立创建QCoreApplication对象。运行时发现：

• 带命令行参数启动程序，第二次调用run_test时会出现崩溃（表现为段错误、线程异常、弹窗报错或进程挂起）
• 若在run_test函数末尾手动将app变量重置为None，程序可正常运行

经过排查，已确认核心诱因是信号连接了持有QCoreApplication引用的局部lambda表达式，同时测试得出以下结论：

• 移除worker中的print语句仅能降低崩溃频率，无法彻底解决问题
• 在start_worker函数末尾调用线程join()可消除崩溃，但在app.exec_()之后调用join()无效
• 断开信号、调用gc.collect()、改用QThread类均无法解决崩溃问题

疑问解答 #

1. 为何重置app为None可避免崩溃？run_test返回时不该自动回收该变量吗？

Python的垃圾回收依赖引用计数，run_test函数返回时，局部变量app的引用计数本应减1，但这里因为lambda表达式持有了app的引用，而lambda又被Qt的信号槽机制内部持有（Qt会保留对槽函数的引用以保证信号触发时槽函数可用），导致app对应的QCoreApplication实例引用计数无法降到0，无法被自动回收。

手动将app设为None，相当于主动切断了局部变量对QCoreApplication实例的引用，配合后续Python垃圾回收机制，能让Qt内部残留的引用被正确清理，避免下一次创建QCoreApplication实例时出现资源冲突或非法内存访问。

2. 此问题是程序、Python还是Qt的bug？

• 这不是Python的bug：Python的引用计数机制工作正常，问题出在Qt与Python绑定层的交互逻辑上。
• 也不能完全归为Qt的bug：Qt文档虽未禁止创建多个QCoreApplication实例，但Qt底层设计默认一个进程中仅存在一个应用实例，多实例场景下，信号槽机制对Python对象的引用管理存在未覆盖的边界情况。
• 本质是程序实现层面的问题：在多QCoreApplication实例的场景下，使用持有应用实例引用的lambda作为槽函数，导致了跨实例的引用残留，触发了Qt底层的资源冲突。

内容的提问来源于stack exchange，提问作者Scott McPeak