c++oding="utf-8" ?>
线程创建失败时gdb看不到新线程，是因为pthread_create或std::thread构造失败后线程根本未生成；应拦截创建调用本身，在pthread_create入口或std::thread构造函数处下断点，检查参数合法性并验证返回值，而非等待线程出现。
线程创建失败时，gdb看不到新线程怎么办
因为 pthread_create 或 std::thread 构造失败时根本没生成线程，gdb 自然无法 info threads 列出它——你看到的其实是“失败前的最后状态”，不是“线程没起来”。关键不是等线程出现，而是拦截创建调用本身。
实操建议：
- 在
pthread_create入口下断点：break pthread_create，运行后观察第四个参数（start_routine）是否为NULL、第三个参数（attr）是否非法（比如已pthread_attr_destroy过） - 对 C++ 代码，更推荐在
std::thread构造函数处断点：break std::thread::thread（注意：GCC libstdc++ 下有效；Clang + libc++ 可能需break std::__thread_impl::_M_start） - 启用线程事件通知：
set follow-fork-mode child和set detach-on-fork off不起作用——它们只管 fork，不接管 pthread 创建；真正有用的是：set scheduler-locking on防止调度干扰断点命中，但调试期间建议关掉（off），否则可能卡住主线程
为什么 stepi / nexti 跳过 pthread_create 却没报错
这不是 gdb 的问题，是 pthread_create 内部做了 errno 检查并静默返回 —— 它返回非零值（如 EAGAIN、ENOMEM），但如果你没检查返回值，程序就带着一个未初始化的 pthread_t 继续跑，后续 pthread_join 必然崩溃或阻塞。
实操建议：
- 永远检查
pthread_create返回值：int ret = pthread_create(&tid, nullptr, func, arg); if (ret != 0) { printf("pthread_create failed: %s\n", strerror(ret)); } - 在 gdb 中直接打印返回值：
print $rax（x86_64 SysV ABI 下，pthread_create返回值在%rax）；或更稳妥地，在调用后立即print ret（如果变量名是ret） - 常见错误码含义：
EAGAIN（系统线程数超限）、EINVAL（attr无效或栈太小）、EPERM（无权限设置调度策略）
std::thread 构造抛 std::system_error 却没被捕获
C++ 标准规定：若 std::thread 构造失败，必须抛 std::system_error（底层调用 pthread_create 失败时转译）。但如果编译时定义了 _GLIBCXX_THROW 或链接了不带异常支持的 libstdc++（如嵌入式场景），它可能直接 abort，不会进 catch 块。
实操建议：
- 确认异常是否开启：
g++ -g -pthread main.cpp（不要加-fno-exceptions）；检查libstdc++.so是否含_ZSt17__throw_system_errori符号（nm -C /usr/lib/x86_64-linux-gnu/libstdc++.so | grep system_error） - 在 gdb 中捕获异常：
catch throw，运行后看是否停在std::thread构造内部；再用bt看堆栈，重点关注__gthread_create或pthread_create的调用位置 - 临时绕过异常机制验证：用
pthread_create替代std::thread，直接观察返回码——这是最干净的隔离手段
线程资源耗尽后，gdb info proc mappings 看不出问题
info proc mappings 显示的是内存映射，不是线程计数。Linux 线程数限制由 /proc/sys/kernel/threads-max 和每个进程的 RLIMIT_NPROC 控制，和虚拟内存无关。即使 mappings 很干净，pthread_create 仍可能因 EAGAIN 失败。
实操建议：
- 查当前限制：
cat /proc/sys/kernel/threads-max、ulimit -u（即RLIMIT_NPROC） - 查进程已用线程数：
ls /proc/<pid>/task/ | wc -l</pid>（比ps -T -p <pid> | wc -l</pid>更准，后者含线程头） - 在 gdb 中快速验证：
call syscall(120, 0, 0, 0, 0, 0, 0)（getrlimit(RLIMIT_NPROC, ...)的 syscall 编号是 120 x86_64），但更简单的是直接shell cat /proc/$pid/status | grep -i thread
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
