Qt对象删除后信号仍触发引发程序崩溃问题求助

首先，你的问题核心是Qt信号槽的同步执行机制和对象销毁时机冲突导致的，这不是Qt的bug，是代码逻辑中的常见陷阱。

为什么delete A无法阻止信号传递？ #

Qt的信号槽调用默认是同步的：当foo->currentIndexChanged信号触发时，程序会直接进入bar函数执行，而bar末尾调用inspector->update()后，delete A会立即销毁对象A——但此时信号的调用栈还没有走完！

看Valgrind的日志，崩溃发生在QMetaObject::activate函数中，这个函数是Qt处理信号分发的核心逻辑，它还在尝试访问已经被释放的对象A的内存（因为delete A已经释放了内存，但activate的调用还没结束）。虽然Qt的QObject会在析构时自动断开所有以它为接收者的信号槽连接，但这个断开操作是在对象析构过程中执行的，而此时当前的信号调用已经在进行中了，所以无法中断正在执行的bar函数后续的调用链，更无法阻止activate函数对已销毁对象内存的访问。

为什么会出现多个信号？ #

你提到只修改过一次ComboBox的值，却有多个信号触发，可能的原因有两个：

1. 对象销毁时的子控件析构触发信号：当delete A执行时，A作为QWidget会调用deleteChildren()销毁所有子控件（包括foo这个ComboBox），ComboBox的析构过程中可能会触发状态变化的信号（比如currentIndexChanged，旧版本Qt的控件析构时可能存在这类行为）。
2. 新对象B的初始化触发信号：当你创建新的对象B时，如果给它的ComboBox设置了和A相同的初始索引，而ComboBox从零开始初始化再设置索引时，可能会触发一次currentIndexChanged（比如从-1到目标索引）。

解决方案 #

针对这个问题，有几个可靠的修复方式：

1. 使用deleteLater()延迟销毁对象
   这是Qt中安全销毁对象的标准做法，尤其是在信号处理或事件循环中。把delete A;替换为：

   A->deleteLater();
   

   deleteLater()会告诉Qt事件循环，在当前所有正在处理的事件（包括当前的信号调用）完成后，再销毁对象A。这样就能保证QMetaObject::activate的调用栈已经走完，不会再访问已销毁的内存。

2. 改用Qt 5+的新式信号槽语法
   你当前使用的是旧的SIGNAL/SLOT宏语法，这种语法是运行时绑定，错误检查较弱。换成新式语法：

   connect(foo, &QComboBox::currentIndexChanged, this, &A::bar);
   

   新式语法不仅能在编译时检查参数匹配，还能更可靠地管理信号槽连接的生命周期，配合deleteLater()使用能进一步避免这类问题。

3. 避免在信号处理中直接销毁自身
   如果可以调整逻辑，尽量不要在bar函数的调用链中销毁对象A。比如可以把销毁对象的逻辑放到单独的事件中，或者通过状态标记让事件循环在合适的时机处理对象的销毁和重建。

4. 阻塞新对象初始化时的信号
   如果是新对象B的初始化触发了额外信号，可以在设置ComboBox索引时暂时阻塞信号：

   // 在创建对象B时
   B->foo->blockSignals(true);
   B->foo->setCurrentIndex(targetIndex);
   B->foo->blockSignals(false);
   

调试建议 #

• 打印对象地址跟踪调用链：在bar函数、inspector->update()、delete A（或deleteLater()）处添加日志，打印对象A的地址，确认调用顺序和对象销毁时机。
• 查看信号槽连接情况：在关键位置调用A->dumpObjectInfo()，打印所有与A相关的信号槽连接，确认在销毁前连接是否存在，销毁后是否正确断开。
• 分步排查：先注释掉创建新对象B的代码，只保留delete A，看是否还会崩溃，以此确认是销毁本身的问题还是重建对象的问题。

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