ARM架构任天堂Switch自制C应用中stb_image分配位图时特定尺寸malloc返回NULL原因问询

基础排查步骤 #

• 打印运行时真实参数，不要只靠源码静态定位。在调用stbi__malloc的代码位置，直接输出target、s->img_x、s->img_y的原始值、三者相乘的实际计算结果、当前的errno值。重点排查隐式类型转换带来的计算错误：哪怕你预想的计算结果是正确的，也要确认参与运算的变量的位宽、符号是否匹配——比如如果宽高字段是16位无符号数，参与运算时被错误转换为负值，最终算出的待分配大小会远高于实际值，必然导致分配失败。
• 绕开stb_image的封装做对照测试。在同一个代码位置，直接调用原生malloc()传入你预先计算的目标size，看是否同样返回NULL。如果直接调用原生malloc也返回NULL，说明问题和stb_image无关，是堆本身的状态异常。

针对homebrew环境的特殊排查点 #

• 验证堆碎片化的影响。devkitA64默认的malloc实现基于连续堆段工作，经过多次分配、释放操作后，堆会被拆分成零散的空闲块，哪怕总空闲内存的数值足够，只要没有匹配请求大小的连续空闲块，就会直接返回NULL。
  这种现象可以解释你测试表里的反常结果：更小尺寸的请求反而比更大尺寸的请求容易失败。堆刚启动时存在一整块连续的大空闲块，更大尺寸的请求可以直接占用整块内存成功；等大块内存被切分占走之后，小尺寸的连续空闲块已经被切得很碎，哪怕总空闲内存比小请求的size大，也没有足够长的连续块满足分配。
  你可以做个对照测试：在程序刚启动、没有做任何其他内存分配操作的时候，依次测试所有尺寸的分配请求，看是否同样出现指定尺寸失败的情况。如果启动时所有尺寸都能正常分配，问题就出在之前的内存操作把堆切碎了。
• 排查堆越界破坏元数据的问题。很多时候malloc返回NULL不是真的内存不足，而是之前的代码写越界了，把malloc用来管理空闲块的元数据结构踩坏了，导致malloc遍历空闲块时误判可用内存的大小。这种情况的典型特征就是特定代码路径下、特定尺寸的请求才会触发必现失败。重点检查QR码生成环节的缓冲区边界计算是否正确：如果QR码生成时写出的字节数超过了自身位图缓冲区的长度，刚好踩到相邻malloc块的管理元数据，后续的内存分配就会出现完全不符合预期的失败。
• 核对程序的堆配置上限。devkitA64程序的可用堆边界是在链接脚本中固定的，如果之前的代码已经通过其他方式（比如直接映射内存、使用自定义内存池）占用了堆段的空间，实际可用的连续堆内存会比配置值小，也会出现特定大小请求必现失败的情况。
• 检查UI库的自定义内存逻辑。不少嵌入式UI库会在初始化时预申请一整块大内存池，替换原生malloc实现，只允许从自己的池子里分配内存。如果内存池的块大小是固定对齐的，当请求的size刚好跨越多个块的边界时，就会返回NULL。

内容的提问来源于stack exchange，提问作者Johnny Verbeek