代码破破烂烂,我们缝缝补补
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、 当然有个好伙伴,一块讨论,激发思路也很重要。