线程栈溢出确实会导致Segmentation fault而非C++异常，关键判断依据是：bt显示调用深度浅但崩溃于大局部数组访问、info threads显示某线程异常、info frame显示栈帧接近2MB；可用$sp差值法估算已用栈量，超1.8MB即可确认；应显式设置pthread或std::thread栈大小，避免依赖默认2MB限制。
确认崩溃是否真由线程栈溢出引起
线程栈溢出不会抛 C++ 异常，try/catch 完全无效；它表现为 Segmentation fault (core dumped) 或 Cannot access memory at address，且仅在多线程路径中复现。关键判断依据有三点：
— gdb ./a.out core 后执行 bt，若调用深度仅 2–5 层，但崩溃点在局部大数组（如 char buf[1024*1024]）访问处，大概率是单帧过大
— 多线程中崩溃，bt 显示正常深度，但 info threads 列出的某线程状态异常（如 running 变为 exited 或无响应）
— info frame 显示当前栈帧 Size of frame 接近或超过 2MB（Linux std::thread 默认栈大小）
查线程栈实际使用量：用 $sp 差值法
GDB 里没有直接命令显示“已用栈空间”，但可通过寄存器差值估算。核心思路是：从线程入口帧（如 __pthread_bound_body 或 main）到当前崩溃帧，$sp 下降了多少，就是该线程迄今压栈的总字节数。
— 先切到线程入口附近帧：frame 10（数字根据 bt 输出调整，找最靠近线程启动的帧）
— 记录起点：set $sp_start = $sp
— 切回崩溃帧：frame 0
— 计算用量：p $sp_start - $sp
若结果 > 1.8MB，基本可断定栈耗尽。注意：此法不依赖符号表，即使函数被优化也能用
改线程栈大小：别只靠 std::thread 默认值
Linux 下 std::thread 构造的线程默认栈仅约 2MB，远低于主线程的 8MB（ulimit -s 所示）。一旦涉及深度递归、大缓冲区或嵌套回调，极易触顶。
— 正确做法是显式传入栈尺寸：std::thread(std::stacksize(4 * 1024 * 1024), func, args...)（C++23 起支持；旧标准需用 pthread）
— 更通用的是用 pthread_attr_setstacksize：pthread_attr_t attr; pthread_attr_init(&attr); pthread_attr_setstacksize(&attr, 8 * 1024 * 1024); pthread_create(&tid, &attr, thread_func, nullptr);
— 环境变量 PTHREAD_DEFAULT_STACK_SIZE 在部分系统（如 HP-UX）有效，但 Linux 上通常被忽略，不可依赖
避免误判：栈溢出和堆/内存越界表现相似但根源不同
同一句 Segmentation fault 可能来自完全不同的问题，混淆会导致调试方向错误。
— 若 bt 显示上百层重复调用（如 parse_json → parse_json → ...），是递归失控，属栈溢出
— 若崩溃点在 malloc 返回地址附近，或 info registers 显示 rdi/rsi 指向非法地址，更可能是堆越界或野指针
— ASan（-fsanitize=address）能一并捕获两者：栈溢出会报 stack-buffer-overflow，堆溢出会报 heap-buffer-overflow，且带精确行号——这是比纯 GDB 更快的初筛手段
