info threads输出中真正有用的字段是：第一列（GDB线程ID）、第三列（停靠位置，含函数名和行号）及带星号（*）的行（当前作用线程）；括号内LWP值为真实OS线程ID。
直接看线程列表，重点盯住带 * 的那行和第三列的堆栈位置
info threads 输出里哪些字段真正有用
执行 info threads 后，典型输出像这样：
(gdb) info threads 4 Thread 0x7ffff7587700 (LWP 12346) 0x00007ffff7e8d609 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 3 Thread 0x7ffff6d86700 (LWP 12347) 0x00007ffff7e1d334 in sleep () from /lib/x86_64-linux-gnu/libc.so.6 * 2 Thread 0x7ffff7d88700 (LWP 12345) main () at main.c:10 1 Thread 0x7ffff7fc9740 (LWP 12344) 0x00007ffff7e94aff in __libc_recvfrom (fd=5, buf=0x7ffff7fc8b80, n=1024, flags=0, addr=0x0, addrlen=0x0) at ../sysdeps/unix/sysv/linux/recvfrom.c:28
- 第一列是
gdb内部分配的线程 ID（不是 OS 线程 ID），后续thread 2、thread apply 2 bt都用这个数字 - 第二列括号里的
LWP 12345是 Linux 下的真实线程 ID（即gettid()返回值），查/proc/PID/task/或用ps -T -p PID对得上 - 第三列是当前线程停在哪儿：函数名 + 文件行号（如
main () at main.c:10）最直观；全是地址或??说明没调试信息或已优化掉 - 带
*的那行 = 当前线程，所有单步、print、bt默认只作用于它
为什么 info threads 有时只显示一行或报错
常见原因就三个：
- 程序根本没创建新线程（比如还没走到
pthread_create），info threads就只显示主线程（ID 1） - 编译时没加
-g，GDB 能识别线程但无法解析符号，第三列会是乱码或地址，但线程数量是对的 - GDB 版本太老或系统不支持 NPTL（比如某些嵌入式 uClibc 环境），执行
info threads可能直接报Thread ID 1 not known—— 这时候thread apply all也用不了
info threads 和 thread apply all bt 别混着用
info threads 是快照，只告诉你“此刻有哪些线程、在哪停着”；thread apply all bt 是动作，让每个线程都立刻打一次堆栈。两者目的不同：
- 想快速确认线程是否都活得好好的、有没有卡死在锁或系统调用里？先
info threads看第三列状态 - 想查某线程是不是在等互斥量、或者崩溃前调用链是什么？必须切过去
thread 3再bt，或直接thread apply all bt -
info threads不会触发任何线程执行，绝对安全；而thread apply all bt在多线程挂起状态下是安全的，但如果线程正在执行中（比如刚中断在信号处理里），部分寄存器可能不准
实际调试时，info threads 就是你的线程仪表盘——别指望它告诉你 bug 在哪，但它能第一时间暴露异常模式：比如所有工作线程都停在 pthread_cond_wait，但主线程卡在 epoll_wait，那大概率是事件循环没起来或条件变量没发信号。
