这几天以前曾经做过的一个项目上线测试了，果不其然，没有经过’战争洗礼’的产品就是靠不住，这不出了若干问题。害得我逃了半天课远程支持。

其中的一个问题很值得思考。其所在的模块并非是一个核心功能模块，而是一个提高系统Availability的一个功能模块，主要功能就是监视磁盘占用率。我们通过配置给出允许使用的磁盘空间大小(以M Byte为单位)，以及两个阈值，即当占用率达到多少的时候，Do A；达到多少的时候Do B。

我们假设用变量quota代表配置中读取的配额数值，而total代表实际检测到的占用数值，一般关于文件大小的系统调用都是用byte作为单位的，也就是说我们需要做一个转换，假设换算后的变量为quota1。由于最初我们没有考虑周全的原因，我们使用unsigned int作为quota、quota1和total的存储类型。结果在家里没有做过认真的测试，导致一到现场就’露馅’了。这个问题反应到家里后，一个同事发现了这一问题，并作了修改，经过简单的测试，好像表面上问题消失了。再一次提交到现场后，问题依旧。

由于那位同事还有其他工作，我只能逃课改问题，经过一段时间的代码Review终于发现了些许’蛛丝马迹’，简单表述一下，原来这里的代码是这样的：

计算total;
quota1 = quota * 1024 * 1024;
拿total和quota1之比与配额阈值作比较;

注意这里的total和quota1是unsigned long long，也就是64位的，而quota是unsigned int，即32位的。首先quota肯定不会出现溢出的可能，因为检查配置发现这个数不大。那么为什么从日志观察，quota1有问题呢？

比如我们的quota配置为1004800，那么在换算后正确的数值应该是053609164800，而日志中打印出来的结果却是1342177280。基本上可以肯定问题出在quota1 = quota * 1024 * 1024;这个转换式上。

我们大概可以用下面的程序来模拟一下这个问题：
int main() {
        long m = 1004800;
        unsigned long long n;
        n = m * 1024 * 1024;
        printf("%llu\n", n);
}

由于n = m * 1024 * 1024这个计算式的工作流程是这样的，先将m * 1024 * 1024的结果保存在一个临时变量中，然后再将这个临时变量值赋给n，这里是在Solaris9下利用GDB反汇编的结果：

(gdb) disas main
Dump of assembler code for function main:
0x0001066c <main+0>:    save  %sp, -128, %sp
0×00010670 <main+4>:    sethi  %hi(0xf5400), %o0
0×00010674 <main+8>:    or  %o0, 0×100, %o0     ! 0xf5500
0×00010678 <main+12>:   st  %o0, [ %fp + -20 ]
0x0001067c <main+16>:   ld  [ %fp + -20 ], %o0
0×00010680 <main+20>:   sll  %o0, 0×14, %o0
0×00010684 <main+24>:   st  %o0, [ %fp + -28 ]
0×00010688 <main+28>:   sra  %o0, 0x1f, %o0
0x0001068c <main+32>:   st  %o0, [ %fp + -32 ]
0×00010690 <main+36>:   sethi  %hi(0×10400), %o0
0×00010694 <main+40>:   or  %o0, 0×358, %o0     ! 0×10758 <_lib_version+8>
0×00010698 <main+44>:   ld  [ %fp + -32 ], %o1
0x0001069c <main+48>:   ld  [ %fp + -28 ], %o2
0x000106a0 <main+52>:   call  0×20800 <printf>
0x000106a4 <main+56>:   nop
0x000106a8 <main+60>:   mov  %o0, %i0
0x000106ac <main+64>:   nop
0x000106b0 <main+68>:   ret
0x000106b4 <main+72>:   restore

%o0 = 0xf5500 = 1004800
store %o0 -> fp + -20
大概看一下：
0×00010670 <main+4>:    sethi  %hi(0xf5400), %o0
0×00010674 <main+8>:    or  %o0, 0×100, %o0     ! 0xf5500
0×00010678 <main+12>:   st  %o0, [ %fp + -20 ]
这三句实际上是在栈上分配一个变量m，并赋值为1004800，这里编译器利用sethi  %hi(0xf5400), %o0和or  %o0, 0×100, %o0两句在寄存器%o0中构造出1004800(即0xf5500)，然后将寄存器的值通过st指令写入到%fp – 20的位置。即m占据着从%fp – 17到%fp – 20这四个字节。

再往下
sll  %o0, 0×14, %o0，
st  %o0, [ %fp + -28 ]
这里是编译器做的优化，它没有乘以两次1024，而是直接乘以1024*1024的结果，也就是2^20，即将%o0逻辑左移20位，即逻辑左移0×14，我们知道逻辑左移即把操作数看成无符号数。对寄存器操作数进行移位，不管左右移，空出的位均补0，我们可以来手工逻辑左移一次，目前%o0中存储的是无符号数0xf5500, 即 0000 0000 0000 1111 0101 0101 0000 0000(B)，我们逻辑左移20位后为0101 0000 0000 0000 0000 0000 0000 0000(B), 即0×50000000，即1342177280。之后利用st指令将改寄存器的值存入到%fp – 28开始的8个字节当中(即从%fp – 21到%fp – 28)。这样我们读出来的n值也就是1342177280了。

如何修正呢？看下面的例子：
int main() {
        long m = 1004800;
        unsigned long long n = m;

        n *= 1024 * 1024;
        printf("%llu\n", n);
}

(gdb) disas main
Dump of assembler code for function main:
0x0001066c <main+0>:    save  %sp, -128, %sp
0×00010670 <main+4>:    sethi  %hi(0xf5400), %o0
0×00010674 <main+8>:    or  %o0, 0×100, %o0     ! 0xf5500
0×00010678 <main+12>:   st  %o0, [ %fp + -20 ]
0x0001067c <main+16>:   ld  [ %fp + -20 ], %o0
0×00010680 <main+20>:   st  %o0, [ %fp + -28 ]
0×00010684 <main+24>:   sra  %o0, 0x1f, %o0
0×00010688 <main+28>:   st  %o0, [ %fp + -32 ]
0x0001068c <main+32>:   ldd  [ %fp + -32 ], %o0
0×00010690 <main+36>:   mov  %o0, %o2
0×00010694 <main+40>:   mov  %o1, %o3
0×00010698 <main+44>:   srl  %o3, 0xc, %o5
0x0001069c <main+48>:   sll  %o2, 0×14, %o4
0x000106a0 <main+52>:   or  %o5, %o4, %o0
0x000106a4 <main+56>:   sll  %o3, 0×14, %o1
0x000106a8 <main+60>:   std  %o0, [ %fp + -32 ]
0x000106ac <main+64>:   sethi  %hi(0×10400), %o0
0x000106b0 <main+68>:   or  %o0, 0×378, %o0     ! 0×10778 <_lib_version+8>
0x000106b4 <main+72>:   ld  [ %fp + -32 ], %o1
0x000106b8 <main+76>:   ld  [ %fp + -28 ], %o2
0x000106bc <main+80>:   call  0×20820 <printf>
0x000106c0 <main+84>:   nop
0x000106c4 <main+88>:   mov  %o0, %i0
0x000106c8 <main+92>:   nop
0x000106cc <main+96>:   ret
0x000106d0 <main+100>:  restore

和上面的汇编差不多少，主要的差别就是再st  %o0, [ %fp + -28 ]后，所有的操作均针对8位的m了，而且寄存器也不仅仅一个%o0参与(位数不够了)，这句之后都是关于8字节的运算了。也就不存在溢出了。毕竟汇编细节看起来还是很费劲的，大家能明白其中的意思即可。

其实简单来看我们可以这么来理解：
n = m * 1024 * 1024;
n *= 1024 * 1024;

前一个式子可以看成 m’ = m * 1024 * 1024; n = m’；这样我们可以简单的认为m’这个中间变量和m存储空间一致。
而n *= 1024 * 1024 <=> n *= 1048576 <=> n = n * 1048576，都是在n的基础上操作，不会出现溢出问题。

溢出问题一般都很隐蔽，很难轻易发现，大家要格外注意。

下午到ChinaUnix C/C++版看了看，发现一个比较有意思的问题，一位兄弟在其帖子中问一段很简单的程序明显有数组越界访问之错误，可程序为什么运行起来却’安然无恙’，我看看了看，也给出了我自己的回复，晚上下班后又想想了这个问题，决定写一篇blog说说。

这位仁兄的程序(据他个人说来源自’GNU/Linux编程指南’)是这样的：

#define BIGNUM 50

void index_to_the_moon(int arr[]);

int main(void)
{
        int intary[10];
        index_to_the_moon(intary);

        exit(EXIT_SUCCESS);
}

void index_to_the_moon(int arr[])
{
        int i;
        for(i=0;i<bignum;i++)
        {
                arr[i]=i;
                printf("%d\n",arr[i]);
        }
}

正如这位楼主所说，这段代码很简单，相信学过2天C程序的人都能看得懂。按照楼主所说我在公司的环境(Solaris 9, Gcc 3.4)编译运行了这段代码，果然让楼主言中了，程序’安然无恙’的运行结束，没有任何异常。在那个帖子的回复中很多人说原因：’C不对数组下标越界进行检查，如果越界访问，其结果未定义’。这些回答其实也没有错，我在Windows XP, mingw Gcc 3.4.2下也试过编译运行该程序，结果是当打印输出到47，程序就中止了，也没有任何提示或者错误出现，估计是Windows OS中途将之Kill掉了。我们还是不说Windows上的东西比较好，我们还是主要以Unix平台为例，为什么Unix平台运行该程序一切OK呢？我们不妨分析一下：

明眼人都看得出来，该程序的确是越界访问数组了，但这只是表面想象或者说是违反了C语言的约束的做法，而更进一步说越界访问的结果是什么呢？Unix OS凭什么知道需要给出错误信息(Dump Core)呢？直截了当地说这个程序里面只是’污染’了用户进程地址空间中的一个叫’栈’的空间，我们回顾一下一个应用程序它的进程地址空间是一个什么样的布局(这个在’C专家编程’一书中有说明)：

———— 0xFFFFFFFF(高地址)
栈  (stack bottom)

    (stack top)
————
  |
  |
 \|/
 空洞
 /|\
  |
————
堆

————
数据段
————
文本段
———— 0×00000000(低地址)

按照上面的布局，我们来大致确定一下那个程序中各个变量的位置，当然我们主要聚焦在栈区了，我们要看看index_to_the_moon函数到底污染了栈上的哪些区域？在main函数中程序定义了一个局部数组变量intary，之后调用了函数index_to_the_moon，我们可以得到一个这样的栈布局：
—————————
stack bottom(high addess)
    |
   \|/
————–
main的返回地址
————–
saved %ebp
————–
intary[9]
————–
…
————–
intary[0]
…
————–
index_to_the_moon返回地址
….

    |
   \|/
stack top(low address)
————————–

从这个布局中我们可以看得出来，在栈上，intary中的各个元素的排列，通过打印出intary[0]和intary[1]的地址我们即可推导出其伸展方向，这样已经一目了然了，从intary[0]到intary[9]是从低地址到高地址分配的，这样我们可以推断如果有intary[10]，其地址应该在intary[9]的高地址方向上，这样在index_to_the_moon中越界修改的栈数据就是沿着高地址方向的污染，而高地址方向存储的是什么呢，继续看图，沿着高地址方向依次是main的返回地址、以及调用main函数的_start函数的访问地址以及他们的参数列表和相关局部变量，当然_start函数究竟是什么样子的我们不得而知。但是污染了这些数据会不会导致core的出现呢？我觉得可能性不大，我想当main函数调用exit或者return后用户进程退出了，OS只是象征性的到栈上取一些返回值罢了，至于这些值是0还是796，意义已经不大。

那是不是这样越界下去就永远不会出问题了呢？当然不是。你把上面程序中的BIGNUM换成1000看看，起码在我的环境上，当printf访问到intary[654]的时候，出现了’段错误 ((主存储器)信息转储)’，这又是为什么呢？我们都知道我们现在的OS采用的都是虚拟存储管理，我们的进程地址空间也是虚拟地址，当我们无限制的沿着高低址方向试图访问数据时，所访问的虚拟地址值就会最终’进入内核空间’或者’溢出当前内存页所能表示的虚拟内存地址’而导致访问违例，当你访问违法的地址时出错就是必然的了。