GDB无法直接查看每个线程的栈大小，它只能显示栈帧、栈指针和局部变量地址，但不解析栈边界或使用量；需结合ulimit -s、/proc/pid/maps及pthread创建时显式配置来获取真实栈限制。
gdb 无法直接查看每个线程的栈大小
这是个常见误解：GDB 本身不提供 thread stack-size 或类似命令来读取每个线程的栈空间上限或已用大小。它能看到栈帧（bt）、栈指针寄存器（如 $rsp 或 $r13）、局部变量地址，但**不解析线程栈边界或当前使用量**。
真正有效的替代方案是结合系统级工具查栈限制
线程栈大小由内核在创建时按 pthread_attr_setstacksize 或默认值分配，实际限制来自进程的 RLIMIT_STACK（对主线程）或创建时显式设置（对 pthread）。GDB 只能辅助验证是否溢出，不能查“大小”本身：
-
ulimit -s查的是主线程的软限制（单位 KB），所有新线程默认继承该值（除非 pthread 显式覆盖） - 用
cat /proc/<pid>/maps | grep '\[stack' </pid>可看到主线程栈映射范围（如7ffff7ff9000-7ffff7fff000 rw-p），长度即为实际分配大小（注意：不是 limit，是已 mmap 的空间） - 对 pthread 创建的线程，其栈地址需通过
info threads+thread apply all p $rsp推断大致位置，再结合/proc/<pid>/maps</pid>手动比对——但无法精确得出“该线程栈上限”，因为 pthread 栈通常不单独映射为[stack:xxx]条目
排查栈溢出时，GDB 能做什么
当怀疑栈溢出导致 crash（如 SIGSEGV 在 deep recursion 或大数组声明处），GDB 的作用是确认现象和定位上下文：
- 崩溃后运行
bt—— 如果栈深度异常大（几百层），或出现重复帧（如#1234 func() at foo.c:42→#1235 func() at foo.c:42），极可能栈溢出 - 用
x/16xg $rsp查看栈顶附近内存是否全为零或乱码（正常栈应有返回地址、保存寄存器等） - 检查函数内是否有超大栈对象：
info frame显示saved regs和栈帧起始地址，对比p $rsp与info frame中的地址差，可粗略估算当前帧占用 —— 但仅限单帧，非整个栈 - 若程序用
alloca()或 VLAs（变长数组），在bt中看到帧大小突增，也是线索
最易被忽略的一点：pthread 栈不可靠地暴露在 /proc/maps
主线程栈总对应一个 [stack] 条目，但普通 pthread 线程的栈在 /proc/<pid>/maps</pid> 中往往只体现为匿名映射（anon_inode:[perf_event] 或无名 rw-p 区域），且不标注用途。这意味着即使你知道线程 LWP ID，也无法从 maps 直接圈定“它的栈”。唯一可靠方式是：在创建线程前用 pthread_attr_setstack 指定栈地址+大小，并在 GDB 中用 p &some_local_var_in_thread_func 结合该基址做减法推算 —— 这要求你控制线程创建逻辑。
