本地CTF实验中规划最小示例验证errno在内存分配失败后状态保存假设的场景清单

在本地CTF实验中，验证内存分配失败后errno的状态保存假设，需要通过控制分配大小和观察错误码变化来完成。实验者通常先构造故意触发ENOMEM的代码片段，再用GDB附加查看errno是否按预期保留。这种方法能帮助澄清标准库在失败路径上的行为差异，避免在后续调试中误判程序状态。规划最小示例时，重点在于限制变量数量、固定失败条件，并记录每次调用前后的errno值，以便准确判断保存假设是否成立。

这种验证过程适用于单线程或多线程的隔离环境，但必须排除外部信号或库调用的干扰。实验者需要准备好资源限制工具如setrlimit，并设计恢复机制以保持实验环境一致。判断依据包括调用返回NULL后errno立即为ENOMEM，且后续操作未覆盖该值。适用条件要求使用特定libc版本，并标注编译选项，因为优化级别可能影响错误报告路径。常见错误是忽略线程局部存储的影响或在信号处理程序中触发额外分配。

场景规划的基本原则

规划最小示例时首先限定目标函数为malloc或calloc，并固定失败条件为请求尺寸超过可用内存上限。示例代码应仅包含必要的包含头文件和单次调用，避免引入额外变量或循环。实验者需要预先确定资源限制值，通过setrlimit将RLIMIT_AS设为较小数值，然后请求一个明显超出该限制的尺寸。判断标准是errno在调用返回NULL后立即等于ENOMEM，且后续无其他库调用覆盖该值。适用边界为单线程环境，超出此范围需额外隔离线程局部存储。

在实际操作中，实验者应先保存原有资源限制，失败后恢复设置以避免影响其他测试。静态分析部分关注返回值判空后的errno读取位置，确保没有中间函数修改errno。常见误区是未屏蔽可能修改errno的信号，因此示例中需使用sigprocmask临时阻塞相关信号。适用条件包括使用未优化编译以保留完整调试信息，同时记录所用glibc版本，因为不同实现对ENOMEM的设置时机可能略有差异。

单线程下malloc失败的示例构造

构造步骤包括设置RLIMIT_AS为较小值，然后请求一个超出限制的尺寸。使用setrlimit前保存原有限制，失败后恢复以保持实验环境干净。实验者需编写包含#include 和#include 的最小代码，调用getrlimit获取初始值，修改后触发malloc。动态调试时在malloc调用后立即检查errno，静态分析则关注返回值判空后的errno读取位置。常见误区是忽略errno可能被信号处理程序修改，因此需在示例中屏蔽相关信号。

判断依据为malloc返回NULL且errno值为12（ENOMEM）。实验者可通过strerror打印 errno描述来辅助确认。适用条件是单进程、无并发访问的本地环境，超出此条件需添加线程隔离步骤。常见错误包括未恢复资源限制导致后续测试失败，或在检查errno前调用了其他可能修改errno的函数如printf。

realloc与calloc的失败路径对比

realloc在原指针为NULL时行为等同malloc，失败时同样设置errno。示例中需分别测试扩大与缩小两种尺寸，记录errno是否一致。实验者应准备两个独立的最小文件，一个使用realloc(NULL, large_size)，另一个使用realloc(existing_ptr, larger_size)并确保失败。判断标准是两次失败后errno均保持ENOMEM，且未被中间操作覆盖。

calloc额外清零操作可能影响内部错误报告路径，验证时应比较两次分配失败的errno值是否相同。适用条件为相同libc版本和编译选项，超出此范围需注明差异。常见误区是假设realloc失败时原指针仍有效，实际应在示例中验证指针未被修改。实验者还需注意realloc在失败时可能返回原指针，需通过返回值判断而非仅看errno。

多线程环境下的errno独立性

线程局部errno要求每个线程独立触发分配失败。示例中创建两个线程，分别请求超大内存，并在主线程检查是否互相干扰。实验者需使用pthread_create启动线程，并在每个线程内设置独立资源限制。调试步骤包括用thread apply all打印errno，或在失败点设置条件断点。判断依据是各线程errno值独立，且主线程未受影响。

适用条件为使用支持线程局部errno的glibc版本，边界在于自定义errno包装可能改变行为。常见错误是未使用pthread_key管理导致errno被共享，实验者应在示例中显式测试errno是否被其他线程覆盖。验证时可添加sleep调用以控制线程切换顺序，确保失败路径的时序可重现。

与信号处理程序的交互验证

信号处理程序内执行分配操作可能覆盖errno，因此示例需在主流程触发失败前注册信号处理器，并检查处理器退出后errno是否仍为预期值。实验者应使用sigaction注册处理程序，并在处理程序中避免调用非异步安全函数。步骤中先阻塞信号，触发失败，再解除阻塞观察变化。判断标准是信号返回后errno仍为ENOMEM。

适用范围限于异步安全函数，超出此范围的信号处理会引入不可预测状态。常见误区是未在示例中测试SIGSEGV或SIGALRM等可能触发的信号。实验者需记录信号掩码变更对errno保存的影响，并确保处理程序不执行malloc等操作。

核心转储与实时附加的取舍

当分配失败导致程序终止时，核心转储可保留errno现场，但需提前启用coredump。实验者应在脚本中临时设置ulimit -c unlimited，并使用gdb加载转储文件检查errno位置。实时附加则允许在失败点暂停并修改errno值进行后续测试。判断标准是转储文件中errno位置与实时读取一致。

局限在于部分发行版默认关闭coredump，需在实验脚本中临时调整。适用条件为程序因内存不足而退出而非直接返回的场景。常见错误是忽略转储文件权限或路径设置，导致无法读取errno值。实验者可结合两种方法，先用实时附加确认位置，再用转储验证持久性。

长期维护与示例库组织

将上述场景整理为独立文件，每个文件包含编译命令、运行前置条件和预期输出。实验者需建立目录结构，按函数分类存放最小示例，并添加README说明验证步骤。定期复盘时更新libc版本并重新执行验证，记录变更日志可追踪假设是否随工具链演进而失效。

最终目标是形成可复用的检查清单，而非一次性测试。适用条件是实验环境稳定，无外部依赖变更。常见错误是示例文件未标注编译选项，导致不同优化级别下结果不一致。实验者应定期清理临时资源限制设置，并备份验证日志以支持后续调试假设的回溯。