线程完成任务后出现段错误，第二次调用pthread_create时触发故障

核心错误点 #

• 对pthread_create接口的传参逻辑存在根本性误用
  pthread_create的函数原型为：int pthread_create(pthread_t *thread, const pthread_attr_t *attr, void *(*start_routine)(void *), void *arg)
  其中第三个参数要求传入线程入口函数的内存地址（函数指针），而非直接调用这个函数。
  原代码中写作print_n(100)的传参写法，实际执行逻辑是：在调用pthread_create之前，先在主线程上下文里同步执行一次print_n(100)，函数执行完成后返回NULL（因为print_n的return值是NULL），最终把这个NULL值当作线程入口函数的地址传给了pthread_create。
  这里需要明确：不带括号的函数名代表函数的内存地址，带括号的写法一定会触发函数调用、返回函数执行结果。
• 线程入口函数的签名完全不符合接口规范
  符合pthread要求的入口函数必须满足：接收一个void*类型的参数，返回void*类型值。原代码中定义的print_n函数签名为void *print_n(int n)，参数类型为int，本身就不满足接口的参数要求，就算正确传了函数地址，也会在函数调用时发生栈内存对齐、参数传值的错乱。

段错误触发的实际时机 #

观察到的“第二次调用pthread_create时触发段错误”只是时间上的巧合：

1. 第一次循环执行时，pthread_create拿到的线程入口地址是NULL，接口本身在创建线程的内核结构、完成线程初始化的阶段，并不会立刻解引用这个函数地址，因此会正常返回成功。
2. 后续当这个没有有效入口的线程被操作系统调度获得CPU时间片时，会尝试从地址0开始执行指令，直接触发访问非法地址的段错误。这个崩溃发生的时间点，刚好落在第二次循环调用pthread_create的执行路径上，造成了“第二次调用pthread_create才崩溃”的错觉。

• 编译阶段开启严格检查：编译时加上-Wall -Wextra -pthread参数，编译器会直接报出“传入pthread_create的参数类型不匹配”的警告，从根源暴露类型错误。
• 调试阶段定位真实崩溃点：使用gdb复现场景，在程序崩溃时通过bt命令打印调用栈，会发现崩溃位置根本不在pthread_create的系统调用流程里，而是在某个未关联有效入口的线程执行流中。
• 接口校验：对照目标接口的官方原型逐行核对传参类型，不要混淆“函数指针”和“函数调用返回值”的概念。

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

// 匹配pthread要求的函数签名：接收void*类型参数，返回void*
void *print_n(void *arg)
{
    int n = *(int *)arg;
    printf("%d\n", n);
    pthread_detach(pthread_self());
    return NULL;
}

int main()
{
    int print_val = 100;
    while (1)
    {
        pthread_t thread;
        // 正确传参：第三个参数为print_n的函数地址，第四个参数为传递给线程的实参地址
        if (pthread_create(&thread, NULL, print_n, &print_val))
        {
            printf("pthread_create error\n");
        }
        // 避免循环创建过快导致的资源耗尽，可根据实际场景调整
        usleep(1000);
    }
    return 0;
}

注意：如果给线程传递循环内的临时栈变量值，需要保证传值的内存地址在线程实际读取时仍然有效，否则会触发悬空指针问题。通常如果需要传递动态值，会通过堆内存分配的方式传参，在线程入口函数中完成内存释放。

内容的提问来源于stack exchange，提问作者S.Sot