下午到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采用的都是虚拟存储管理，我们的进程地址空间也是虚拟地址，当我们无限制的沿着高低址方向试图访问数据时，所访问的虚拟地址值就会最终’进入内核空间’或者’溢出当前内存页所能表示的虚拟内存地址’而导致访问违例，当你访问违法的地址时出错就是必然的了。

上午我们的一个实施组从现网发回来一封邮件，接到这种邮件一般都是报告问题的，果然不出所料，现场出现一个core，经过分析这是个由于线程函数参数存储位置不当造成的，从中我们可以总结出一些经验，以避免以后再犯。

我采用下面的一个例子来模拟问题的出现：

#include <pthread.h>
#include <errno.h>
#include <stdio.h>

typedef struct foo {
        char c[10];
        int  *p;
} foo;

void *thread_func(void *para) {
        foo     *p      = (foo*)para;
        sleep(5); //等待以让gen_thread先退出
        printf("[thr2-1]: the foo’s str is %s\n", p->c);
        printf("[thr2-1]: the foo’s p is %d\n", *(p->p));
        *(p->p) = 10;
        strcpy(p->c, "Bye, Tony");
        printf("[thr2-2]: the foo’s str is %s\n", p->c);
        printf("[thr2-2]: the foo’s p is %d\n", *(p->p));
        return;
}

pthread_t gen_thread() {
        pthread_t       id;
        int             rv;
        int             i       = 0;
        foo             f;

        memset(&f, 0, sizeof(foo));
        strcpy(f.c, "HelloTony");
        f.p = &i;

        printf("[thr1]: the foo’s str is %s\n", f.c);
        printf("[thr1]: the foo’s p is %d\n", *(f.p));

        rv = pthread_create(&id, NULL, (void*)thread_func, (void*)&f);
        if (rv != 0) {
                printf("create pthread error, errno is %d!\n", errno);
                exit (1);
        }

        return id;
}

int main() {
        pthread_join(gen_thread(), NULL);
        return 0;
}

编译执行：
a.out
[thr1]: the foo’s str is HelloTony
[thr1]: the foo’s p is 0
[thr2-1]: the foo’s str is 旷
[thr2-1]: the foo’s p is 0
[thr2-2]: the foo’s str is Bye, Tony
[thr2-2]: the foo’s p is 10
段错误 ((主存储器)信息转储)

我们来分析一下出现core的过程，gen_thread函数在创建一个新的线程后退出，而在创建新的线程时，传给线程函数的参数是存储在gen_thread函数的栈上的局部变量。而在gen_thread退出后，新线程的线程函数对线程参数进行了修改，其结果就相当于修改了主线程的栈上的数据，而当系统调用访问主线程的栈数据时，这些数据已经被修改，导致系统调用访问到’非法地址’而Dump Core。

当然上面的例子是’臆造’出来的，这也是我们的系统在一个特殊情况下出现的问题，在以前的测试中从未发生。但是我们系统使用栈上变量作为线程函数参数，这确是一潜在的问题，尽管这种问题的发生几率很小。

那么如何解决这一问题呢？眼前就有两个办法：
1、使用全局变量或者是STATIC变量
在上面的例子中，如果我们把foo f拿到函数外，并声明为static foo f，那么Core就不会出现，因为STATIC变量存储在BSS段中，其Scope也是全局的(文件Scope的全局)。所以即使gen_thread返回，存储f的区域仍然是合法的。但是这样做的一个缺点就是：如果新创建多个线程的话，那么这些线程就会共享该参数了，这是一个需要考虑的问题，但是这种情况也许会是用于某些场合。

2、在堆上动态分配变量
在堆上分配变量，既可以避免使用局部变量的’非法访问’问题，也可以避免多个线程共享的问题，针对每创建一个新线程，我们都malloc一块内存，将这块内存地址作为参数传给线程函数。这样做也不是没有弊端，因为动态分配内存，所以你就需要自己管理内存，找到时机释放它。

还有一种方法叫’线程局部存储(Thread Local Storage，TLS)’，应该专门针对第一种办法的，针对声明为全局的或者STATIC的变量，给每个线程提供一份COPY，保证互不干扰。当然这种技术需要编译器的扩展支持，目前不常用，这里也就不多说了。

总之，通过对上面这个问题地分析，我们应该在使用线程的时候注意线程参数的存储方式，这才是我们讨论这个问题的目的。