图中按资源耗尽与访问越界分开诊断，错误名称相似不代表处置相同。
“程序发生内存溢出”，到底是递归层数太深、动态分配失败，还是向数组外面写了数据？这三种情况经常被放进同一个词里，却分别涉及调用资源、分配资源和访问合法性。先把问题说准确，才能找到对应的检查方法。
栈耗尽不等于写越界
在常见原生程序实现中，函数调用需要保存相应执行状态，递归或过大的自动对象可能使调用栈资源不足。即便每次数组访问都在界内，也可能因为调用深度持续增加而耗尽资源，这与把一个数组下标写错是不同问题。
但 C 语言并不保证每个局部变量都以固定方式放在机器栈上。优化、调用约定和目标平台会影响实际表现，递归调用也可能受到优化。因此，不能从源代码里递归了几层，就脱离环境给出一个普遍的崩溃深度。
发生耗尽后怎样表现也取决于系统。它不保证总能以某个可移植异常被捕获，不能把其他语言的栈异常名称直接移植到 C 程序。定位应结合实际信号、栈信息、资源限制和构建条件。
堆耗尽先看分配接口
动态分配失败通常需要从分配器返回结果判断。对普通 malloc，无法满足的请求可能返回空指针，调用方应按接口检查，而不是拿到结果就直接写入。请求大小计算还要先防止整数溢出，否则原本想分配很多元素，可能只申请到一小块。
分配成功也不等于所有后续资源需求都永久得到保证。某些操作系统配置允许延迟承诺或实际触碰内存时才暴露问题，具体行为要看平台策略。不能用一个非空返回值证明系统拥有任意数量的可用物理内存。
同样，分配器保留空间、碎片与真实泄漏也要区分。释放对象后进程占用没有立刻回落，不一定就是这次释放失败；但若所有权丢失、无法再释放，才是另一种需要跟踪的资源问题。
缓冲区越界是访问不合法
一个四字节字符数组，若要保存四个普通字节字符并加上结尾零字节，就需要五个字节。忽略这个额外位置，即使机器还有很多空闲内存，写入仍然越过了对象边界。
越界写不保证立即崩溃。它可能破坏其他对象、分配器元数据或调用状态，也可能暂时看起来没有影响。在 C 语言层面，不能把一次运行结果当成未定义行为的固定后果，更不能推导“还能输出正确答案，所以没有问题”。
越界读同样不合法，不能因为没有修改内存就当成安全。检测工具或边界检查能够帮助发现具体执行路径的问题，但一次检查没有报告，也不证明所有输入和路径都合法。
三种问题需要三类证据
排查栈资源可以从调用链、递归终止条件和局部对象大小开始；排查分配失败要记录请求大小、失败分支和真实资源状态；排查越界则要回到对象容量、索引范围、拷贝长度和生命周期。
如果只是给进程增加内存，可能延后耗尽，却不会修复一个固定数组的越界。反过来，把所有递归改写成循环，也未必解决动态对象持续增长。修复动作必须对应根因，不能因为都叫溢出就统一调一个容量参数。
还应区分症状发生处与错误发生处。内存被较早的一次写入破坏，可能到很晚才在无关位置崩溃。此时只修补最后一个报错点，很容易留下原始越界。
安全处理从输入尺寸开始
需要复制文本时，先明确长度是否包含终止符、目标容量是多少、源数据有多少可读字节，再决定是否接受、截断或返回错误。截断若是接口允许的行为，也应让调用者知道，而不是静默改变数据含义。
对于数量乘元素大小的分配，先做可表示范围检查，再调用分配器，并为失败安排清楚的清理路径。资源所有权和释放责任也应明确，避免处理中途失败时泄漏前面已申请的对象。
这道题不需要现场运行一个会破坏内存的程序。把三类问题的条件、证据和修复方向说清，更能体现判断能力。若越界发生在一个很小的数组里，给机器增加一倍内存，为什么仍然不能让那次写入合法？