并不习惯处理大整数导致 SIGSEGV 或 SIGBUS 或 "Error: free(): invalid next size"错误

概述

最近在调试一段用于处理图像的程序, C++的代码, 需要对每个pixel逐个处理. 在小图像(大约VGA的size)上调试好了需要处理4k size的图像, 一直出现各种离奇错误, 都是和内存有关的, 例如各种SIGSEGV和SIGBUS异常, 在调用free()函数时发生"Error: free(): invalid next size" 错误. 经过仔细排查发现实际上是所用的整形数据类型在进行某些内存地址的运算时发生了类型的溢出.

分析

原始代码中, 使用int类型表示数组的index. 运算的中间结果需要存储在数组中, 为了节约内存, 有部分整数计算结果存储成unsigned short类型. 这两个地方就是出问题的关键.

数组索引运算溢出

对于一个4k尺寸的图像, 它的具体size可能达到3000 * 4000 像素, 也就是12 000 000像素. 我们需要对每个像素存储大约800个整数, 这需要9 600 000 000数量级别的数组. 当使用unsigend short作为存储类型时, 每个整数占用2 Byte内存, 所以我们需要19 200 000 000 Byte的内存, 也就是 大约17.88 GB的内存. 由于在调试时使用int类型作为数组的索引, 而在当前系统上, int类型为4个Byte, 能够表示的最大有符号整数为 2 147 483 647, 所以在使用4k 图像时, 索引值就会出现溢出状况, 破坏了临近区域的内存. 导致程序报出SIGSEGV或SIGBUS错误.

存储类型溢出

如上所述, 我们用unsigned short类型存储计算结果, 而unsigned short类型能够表示的最大无符号整数为
65535. 当计算的数值操过这个值时, 就造成了数值溢出, 整个程序的运算都会有问题.

解决

对于数组索引, 其存储索引的变量声明为size_t类型, 并且参与运算该索引的变量必须也是size_t类型或通过static_cast<size_t>() 转换为size_t类型. 例如

int width, height, valueDim;
size_t index = static_cast<size_t>(width) * height * valueDim;

对于需要用unsigned short存储的结果, 需要提前预估数据出现的范围. 在允许对数据进行clip的时候, 应当用更高位宽的数据类型表示计算结果, 然后再clip到unsigned short能够表示的范围然后再存储成unsigned short类型的值.

后记

高了一个周末, 回想起来是因为自己经验不足, 在处理较大的整数时并没有注意到一些潜在的问题. 另一个就是python用多了, 有些关于类型的事情, 都不怎么注意了.