- 主题:对于几十万行代码的工程，如果某一处出现了数组越界，如何定位
这种写代码的时候就应该打好基础了，严格限制出口入口。
【 在 tianzong (emb) 的大作中提到: 】
:
: --
:
:
--
FROM 223.104.39.*
代码提交diff定位大致位置，静态分析+小流量复现排查，成熟的核心商业系统这样的case大概几个小时能完成修复
不管结果如何，一条线的人通报批评是省不了的了
--
FROM 111.206.214.*
这个要赞，确实也是一种思路
【 在 wuyeguo 的大作中提到: 】
:
: 十年前的时候
: 有个模块内存问题，怎么也查不出来，实在没办法，把模块重写了一遍
:
: --
发自「今日水木 on iOS」
--
FROM 123.125.37.*
如果代码量不大的话，其实也可以试试小黄鸭调试法
有次调了一下午的程序，崩溃后找另一个工程师来看
结果在给他讲解我的逻辑5分钟后，我自己发现了问题。。。。。。。
【 在 xeagle (静下心来编程) 的大作中提到: 】
: 这个要赞，确实也是一种思路
: 发自「今日水木 on iOS」
--
FROM 121.69.67.*
你的debug信息的配置是什么样的，越详细越好
【 在 tianzong (emb) 的大作中提到: 】
:
: --
:
:
--
FROM 124.202.217.*
我在想能不能开发给工具：替换数组成带数组长度的结构 然后检查访问数组的index来确定哪里出了问题。
【 在 tianzong 的大作中提到: 】
--
FROM 116.4.9.*
数组越界不是每次都必现错误的、
、
【 在 mopo 的大作中提到: 】
: 代码提交diff定位大致位置，静态分析+小流量复现排查，成熟的核心商业系统这样的case大概几个小时能完成修复
: 不管结果如何，一条线的人通报批评是省不了的了
--
FROM 113.138.30.*
asan coverity fortify clockwork
【 在 tianzong 的大作中提到: 】
:
: --
:
发自「今日水木 on SPN-AL00」
--
FROM 49.94.173.*
查不出来就加长数组分配的长度，使用的长度保持不变
--
FROM 111.205.43.*
必现还不简单。
打钱吧。
【 在 tianzong (emb) 的大作中提到: 】
: 基本上必现，但就是代码量太大，如何查找是个问题
--
FROM 27.38.241.*