基于C++ STL实现红黑树时DeleteNode函数段错误问题求助

SIGABRT（退出码134）的核心诱因 #

退出码134对应SIGABRT信号，通常由以下情况触发：

• 代码中断言（assert）失败
• 空指针/野指针解引用导致的非法内存访问
• 内存双重释放或释放已失效指针

针对DeleteNode节点替换与父节点绑定的常见错误排查点 #

1. 父节点的孩子指针未同步更新 #

替换待删除节点时，仅修改替换节点的parent指针是不够的，必须根据待删除节点是父节点的左/右孩子，同步更新父节点对应的孩子指针，否则父节点会残留野指针：

// 错误示例：仅更新替换节点的parent
replacement->parent = z->parent;

// 正确实现：同步更新父节点的对应孩子指针
if (z->parent == nullptr) {
    root = replacement; // 待删除节点是根节点，更新根指针
} else if (z == z->parent->left) {
    z->parent->left = replacement;
} else {
    z->parent->right = replacement;
}

2. 叶子/单孩子节点的边界处理失效 #

• 若待删除节点是叶子节点（左右孩子均为nullptr或哨兵节点），替换节点为nullptr时，必须将父节点的对应孩子指针设为nullptr（或哨兵），避免残留无效指针。
• 若使用了CLRS中推荐的哨兵节点（NIL），所有空指针都要指向哨兵，不能直接用nullptr，否则后续遍历或修复逻辑会访问空地址。

3. DeleteFixup中的空指针访问 #

删除后的红黑属性修复逻辑（DeleteFixup）中，容易出现访问空节点的情况：

• 当替换节点成为新根时，应直接终止修复流程，避免访问根节点的父节点（不存在的地址）。
• 访问节点的兄弟、兄弟的左右孩子时，要先判断是否为nullptr（或哨兵），再进行后续操作。

4. 断言触发的中断 #

检查代码中是否有assert语句（比如校验节点颜色、父子关系合法性），DeleteNode破坏红黑树规则时会触发断言，导致SIGABRT。可以暂时注释断言，或通过GDB的bt命令定位到触发断言的具体行。

5. 内存释放后残留野指针 #

若删除节点后直接delete，但父节点的孩子指针未更新为替换节点，后续代码访问该指针会触发非法内存访问。确保释放节点前，所有指向该节点的指针都已被正确替换。

实用排查方法 #

• GDB调试：运行gdb ./test_program，执行run触发崩溃后，用bt查看调用栈，定位崩溃的具体代码行。
• 打印调试：在DeleteNode关键步骤打印节点地址、parent/left/right指针值，验证指针关系是否符合预期。
• 边界测试：单独测试删除根节点、叶子节点、单孩子节点等场景，缩小问题范围。

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