访问链表list释放后内存：两次coredump排除经历（二）并发删除

代码破破烂烂，我们缝缝补补

1、问题现象

上篇文章提到链表中重复添加节点，会导致链表成环。再次删除节点，会导致残留野指针。 juejin.cn/post/730234...

本篇继续分析一个类似问题。遍历list时访问异常指针，coredump文件却显示冲突链找不到该节点。当前冲突链，只有两个节点比如A、B。B的next指针是null。

GDB翻译coredump文件显示访问的pstNextNode非法地址。pstNode是个野指针，对应上图D节点。在GDB中，从头遍历hash冲突链 3 ，B节点的下一个null，并不是D节点。

scss 复制代码

#define LIST_FOREACH_SAFE_RCU(pstList, pstNode, pstNextNode) \
    for ((pstNode) = rcu_dereference((pstList)->next); \
        (null != (pstNode)) && \
        ({(pstNextNode) = rcu_dereference((pstNode)->next); true;}); \
        (pstNode) = (pstNextNode))

2、多线程引起的异常

初始状态

正常情况下，节点有A-B-C-D

多线程删除

1、线程1 遍历链表，分别获取当前节点C，和next节点D。还没有执行操作。

2、线程2 访问到节点D，摘除节点。摘除的结果是节点C的next置为null。

3、线程2 释放掉D节点。D节点是个释放后内存。

4、线程1 处理C节点：业务上会删除C节点。删除操作是C的前缀节点（B）的next设置为C的next。此时B的next就是null了。

5、线程1 继续访问D节点，是个释放后内存。它的next值可能被修改成非法指针。导致直接core。

3、屎山远行

定位疑难复杂问题，一定要合理猜测，大胆论证。上面问题、部门定位了很久。问题的"题眼"就是先发现"节点断链"这个题眼，进而合理推测。梳理代码流程，证实上述流程的存在。

修复问题往往是最简单的，维护业务逻辑复杂、屎山一样的代码。最难的是强大的逻辑推理能力，找到复现条件、才能在一坨坨代码里，找到那一两行异常处。

4、基本姿势

1、对GDB熟练使用，各种技巧熟记于心。

2、特别熟悉多线程问题。

  死锁、 未定义行为，数据不一致、内存泄露等。

3、最重要的是静下来梳理逻辑流程

4、当然有个好伙伴，一块讨论，激发思路也很重要。