上午我们的一个实施组从现网发回来一封邮件，接到这种邮件一般都是报告问题的，果然不出所料，现场出现一个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，保证互不干扰。当然这种技术需要编译器的扩展支持，目前不常用，这里也就不多说了。

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

下午一同事发现代码中的一处问题，问题的现象是这样的：这位同事调用了一部门基础库函数，当使用32位编译后，程序正常运行；而当使用64位编译后，系统运行dump core。让这位同事奇怪的是他所修改的程序中还有其他模块也使用了同样的基础库函数，为什么偏偏他这块儿出错呢？恰恰该程序的其他模块是我写的。

该程序调用的基础库函数大致是这样的：
typedef unsigned long my_size_t;
int my_socket_recv(my_socket_t socket, char *buf, my_size_t *len, int timeout);

而这个库函数的实现主要就是调用了系统的库函数：recv，通过man命令查到recv函数原型为：ssize_t recv(int s, void *buf, size_t len, int flags);

而my_socket_recv的实现如下：
int my_socket_recv (my_socket_t socket, char *buf, my_size_t *len, int timeout)
{
     int rv;
     … …
 
     rv = recv(socket, buf, (*len), 0);
     … …
}

使用gdb察看core文件，通过栈上信息看出(*len)值有问题，有经验的人可能基本就可以断定问题所在了，对了，应该类型长度不匹配的问题，导致内存访问越界。同事的代码也证实了这一点。原来我的这位同事在调用my_socket_recv时第三个参数传入一个unsigned int型的地址，而不是unsigned long型的地址，我们知道在64位编译下，long型已经升级到8个字节，而int型依旧是4个字节，而size_t也是unsigned long的typedef，所以当调用recv时，通过len指针，recv系统调用毫无顾忌的去取8个字节，而实际上在栈上只有前四个字节是合法的数据，从第5个字节开始已经是非法的了，出core也就在情理之中了。我们可以简单的模拟出这种情况，如下面的例子：

/* test.c */
#include

void print_long_int(unsigned long *i) {
        printf("i is %ld\n", *i);
}

int main() {
        unsigned int n = 1024;
        print_long_int(&n);

        return 0;
}

64位编译：
gcc -m64 -g test.c

执行a.out出core.

问题虽然解决了，但是思前想后，发现一个问题：即库函数调用暗藏的’陷阱’问题，像这样的问题实际上是基础库函数的接口设计的不够好，实际上它的正常运行依赖某些条件，而不是’无偿’的，但是这些条件又很难识别出来，特别是对于新手而言更是难上难。

想出两种办法解决：
1、不要设计像上面my_socket_recv这样的带有’隐含’条件的接口(recv系统调用接口就没有隐含条件)；
2、调用接口的人不要想当然的随便传入不同类型的数据，应尽量保持实参数据类型与形参数据类型完全匹配(这块儿编译器可以帮你做检查)，如果不这样，很有可能像我的这位同事一样，掉入了库函数调用的陷阱中。^_^