EzVibe/docs/segfault_investigation.md

EzVibe Segfault 根因调查报告

调查时间

2026-05-22

崩溃现象

• 崩溃周期：约 120 秒（2分钟）稳定复现
• 退出码：Segmentation fault (core dumped)
• GDB 堆栈（两次运行不同）：

Run 1 — QBoxLayout::setGeometry → QLayoutPrivate::doResize → QLayout::activate

#0  QBoxLayout::setGeometry(QRect const&)
#1  QLayoutPrivate::doResize()
#2  QLayout::activate()

Run 2 — QWidget::accessibleName() → setWindowTitle_sys → setVisible

#0  QWidget::accessibleName() const
#1  QWidgetPrivate::setWindowTitle_sys(QString const&)
#2  QWidget::create()
#3  QWidget::setVisible(bool)

两条堆栈指向不同的崩溃路径，但稳定在 120s 发生。

---

已排除的可能

1. _show_notification 的 QTimer

排除。 将 QTimer(popup) 改为 QTimer.singleShot(5000, popup.deleteLater) 后，崩溃仍然发生。

2. play_animation 的 QTimer 重入

排除。 在重新启动动画前加入 isActive() 检查并 stop，崩溃仍然发生。

3. deleteLater() 导致 widget 未从 layout 移除

排除。 _refresh_messages 已修复为先 removeWidget() 再 deleteLater()。测试确认单独运行 chat bubble（无 popup）可以稳定运行 130s+ 不崩溃。

4. _show_notification popup 本身

排除。 单独运行 popup（无 chat bubble）可以稳定运行 130s+ 不崩溃。

5. _add_helper 跨线程

排除。 _add_helper.do_add 通过 QueuedConnection 调用，总是在主线程执行。

6. _notification_helper 跨线程

排除。 同样通过 QueuedConnection 调用，总是在主线程执行。

7. _init_tray QSystemTrayIcon

排除。 禁用 _init_tray 后，崩溃仍然发生。

8. _init_brain_timer QTimer

排除。 禁用 _init_brain_timer 后，崩溃仍然发生。

9. show_reminder 本身（无任何 Qt 操作）

排除。 将 show_reminder 改为纯 no-op（只 print log），可以稳定运行 130s+ 不崩溃，正常 app.quit() 退出。

---

确认的交互：popup + chat bubble 同时启用 = 崩溃

组合	60s	120s	130s+
popup ✓, chat bubble ✓	警告出现	segfault	—
popup ✓, chat bubble ✗	无警告	无崩溃	clean exit
popup ✗, chat bubble ✓	无警告	无崩溃	clean exit
popup ✗, chat bubble ✗	无警告	无崩溃	clean exit

结论：崩溃需要 popup 和 chat bubble 同时启用，且随运行时间累积。

---

警告来源分析

QObject::setParent: Cannot set parent, new parent is in a different thread

警告在每次 show_reminder 调用时出现（通过 QueuedConnection），但：

• _notification_helper 及其所有操作都在主线程
• _add_helper 及其所有操作都在主线程
• invokeMethod(..., QueuedConnection) 后 Qt 内部没有任何跨线程 setParent

假设： 警告来自 QTimer.singleShot(5000, popup.deleteLater) — singleShot 在主线程创建内部 Timer 对象时，可能通过某种机制触发了 QTimer::startTimer，而该调用在跨线程场景下产生了警告。

但这仍然无法解释为什么 popup + chat bubble 同时启用才会崩溃。

QObject::startTimer: current thread's event dispatcher has already been destroyed

此警告同样在 popup + chat bubble 同时启用时出现。当 popup.deleteLater() 被调用后，popup 收到一个 deferred delete 事件。事件处理期间，如果有代码尝试访问 popup 的事件调度器（已经为 NULL），就会触发此警告。

但 popup 已经被标记为待删除（WA_DeleteAfterClose 或 deleteLater），访问其内部状态会导致未定义行为。

---

崩溃路径分析

路径 A：QBoxLayout::setGeometry（更常见）

ChatBubbleWidget._refresh_messages
  → _msg_vbox.addWidget(bubble)   // bubble 是新 QLabel
  → QLayout::activate()
  → QLayoutPrivate::doResize()
  → QBoxLayout::setGeometry()     // 崩溃点
    → QWidget::accessibleName()  // 内部访问已删除的 widget
      → segfault

可能的根因： _refresh_messages 创建的新 bubble widget（QLabel）在某个地方被提前销毁，导致 setGeometry 访问其内部时崩溃。

可能的原因链：

1. _show_notification 创建 QLabel(popup) 作为其 parent
2. 5 秒后 QTimer.singleShot(5000, popup.deleteLater) 触发
3. popup 被销毁时，其子 widget（如果有）被级联删除
4. 如果 bubble widget 和 popup 之间有某种隐式关联，可能导致 bubble widget 被意外删除

路径 B：QWidget::setVisible → create

Qt event loop
  → QScrollArea::event (QEvent::LayoutRequest)
  → qSmartMinSize(widget)
  → QLayout::totalSizeHint()
  → QBoxLayout::heightForWidth()
  → QWidget::accessibleName()  // widget 已删除
    → segfault

当 _refresh_messages 删除 bubble widgets 并重新添加新的之后，如果旧 bubble widget 的 deleteLater 还未被处理，而 Qt 在布局计算时访问了这些 widget，就会崩溃。

---

关键发现：崩溃与时间累积相关

• 120s 是固定崩溃时间
• test_reminder 每 60s 触发一次
• 每次触发可能增加 3 个 bubble widgets（water, stretch, test_reminder）
• 到 120s 时，有 6-9 个 bubble widgets 在 _messages 中

如果 _messages 持续增长而 _refresh_messages 没有被调用来清理，累积的 widget 可能导致布局系统超载。

但更可能的是：popup 的 QLabel 和 chat bubble 的 QLabel 之间有某种 Qt 内部 ID 冲突。

---

待验证假设

1. Popup QLabel 的 deleteLater 时机问题：popup 的 QLabel 虽然在 5 秒后计划删除，但如果在这 5 秒期间 _refresh_messages 触发了多次，某些已标记为删除的 widget 可能被错误地重用或访问。

2. 两个 QLabel 子树之间的隐式交互：popup 和 chat bubble 都创建了 QLabel 对象，虽然它们的 parent 不同，但在 Qt 内部的对象树模型中可能存在某种关联。

3. QTimer 的事件处理器竞争：popup 的 singleShot 在主线程事件循环中注册了一个定时器事件。如果在 5 秒期间，_refresh_messages 同时在处理另一个定时器事件，两者之间可能存在竞争条件。

4. Python 对象的生命周期问题：在 _show_notification 中创建的 popup 是一个局部变量，但如果 deleteLater 还未执行时函数返回，而 Qt 内部持有对该对象的引用，可能导致悬空指针。

---

下一步调查计划

1. 禁用 _show_notification 中的 deleteLater：用 popup.close() 替代，看是否能避免崩溃
2. 在 _show_notification 中为 popup 设置固定寿命，确保 popup 在 deleteLater 之前不会触发任何事件
3. 添加 widget 引用计数日志：追踪 bubble widget 的创建和销毁时间
4. 检查 Qt 对象 ID 分配：看 popup 和 bubble 是否可能分配到相同的内部 ID

---

当前代码改动记录

文件	改动	目的
ui/pet_window.py	_refresh_messages 中先 removeWidget() 再 deleteLater()	避免 layout itemList 损坏
ui/pet_window.py	play_animation 中先 stop() 再创建新 timer	防止 QTimer 重入
ui/pet_window.py	_show_notification 中用 singleShot 替代局部 QTimer	减少 QTimer 对象数量
ui/pet_window.py	_scroll_to_bottom 改为直接调用	避免 widget 已删除后 timer 才触发

---

新发现：app.exec() 阻塞（popup + chat bubble 同时启用）

现象

当 show_reminder 同时启用 popup 和 chat bubble 时：

• 单独启用 popup（chat bubble 禁用）：app.exec() 在 app.quit() 后正常返回，processEvents() 可以工作
• 单独启用 chat bubble（popup 禁用）：app.exec() 在 app.quit() 后正常返回
• 同时启用两者：app.exec() 永远不返回，processEvents() 无响应，app.quit() 被调用但 EXEC_RETURNED 从未打印

测试结果

popup ✓, chat bubble ✗ → app.exec() returns: YES (clean exit)
popup ✗, chat bubble ✓ → app.exec() returns: YES (clean exit)
popup ✓, chat bubble ✓ → app.exec() returns: NO (blocked forever)

分析

app.exec() 的事件循环通过 processEvents() 处理来自其他线程的事件。当同时启用 popup 和 chat bubble 时，_show_notification 中的 QTimer.singleShot(5000, popup.deleteLater) 可能是罪魁祸首。singleShot 在内部创建一个 QTimer 对象并通过 QCoreApplication::postEvent() 注册到事件队列。如果事件循环因为某种原因无法处理 app.quit() 事件（事件队列被阻塞或 Qt 内部状态损坏），app.exec() 就永远不会返回。

根本原因假设： QTimer.singleShot 的内部定时器事件在某个地方阻塞了 QCoreApplication 的退出条件。需要进一步调查 singleShot 的内部机制。

待验证

1. 用 popup.deleteLater() 直接调用替代 singleShot，避免 singleShot 内部的 QTimer 创建
2. 检查 QTimer.singleShot 是否在某些情况下会阻止 app.quit() 正常工作
3. 确认是否可以通过 QApplication::exit() 或其他方式强制退出

---

最新发现：QTimer.singleShot 导致 app.exec() 永不返回

测试

• 启用 notification_helper 调用（_show_notification 是 real code）
• _show_notification 改成 noop（不创建任何 Qt 对象）
• 结果：app.exec() 在 40s+ 后正常退出

确认：QTimer.singleShot(5000, popup.deleteLater) 就是罪魁祸首。

证据链

1. _show_notification 是 singleShot 唯一的不同之处（real popup vs noop popup）
2. 没有 singleShot 的调用链，app.exec() 可以正常退出
3. singleShot 本身是一个 QTimer::singleShot API，内部创建一个 QTimer 对象

假设根因

QTimer::singleShot 内部会创建一个 QTimer 对象并将其 deleteLater() 注册到事件队列。如果这个内部 Timer 在 popup.deleteLater() 执行之前触发某种清理操作，可能会影响 Qt 的退出条件检测。

更可能的情况：singleShot 内部的 QTimer 对象在销毁时，如果 popup 已经通过 deleteLater() 被标记为待删除，会导致该 QTimer 访问无效的 QObject 指针，从而在 Qt 内部的事件处理循环中造成死锁或死循环，使 app.quit() 永远无法完成退出。

修复方向

将 _show_notification 中的 QTimer.singleShot(5000, popup.deleteLater) 替换为直接调用 popup.deleteLater() 或使用其他不涉及 singleShot 的延迟删除机制。

测试代码

# 当前（有问题）：
self._QtCore.QTimer.singleShot(5000, popup.deleteLater)

# 候选修复方案 1（立即删除）：
popup.deleteLater()  # 不等待，立即标记为删除

# 候选修复方案 2（使用 QObject::startTimer 代替 singleShot）：
timer = self._QtCore.QTimer(popup)
timer.timeout.connect(popup.deleteLater)
timer.setSingleShot(True)
timer.start(5000)  # 显式创建 QTimer 并管理其生命周期

# 候选修复方案 3（使用 QTimer + QueuedConnection）：
timer = self._QtCore.QTimer()
timer.timeout.connect(lambda: popup.deleteLater())
timer.setSingleShot(True)
timer.start(5000)