首先明确几个核心观点：GDB并非用于常规性能测试，而是当Swoole Worker进程出现卡死、RSS内存暴涨、协程无法退出等异常时，用来抓取现场、查看调用栈、定位C层阻塞点的终极调试利器。它无法替代xdebug_start_profiling()或perf，但能告诉你「为什么PHP代码正常，但进程却挂住了」。
gdb -p $(pgrep -f "php worker") 为何总是 attach 失败？常见原因与解决方法
这个错误非常常见：ptrace: Operation not permitted 或 Permission denied，在容器或 systemd 环境下尤为突出。
- 根本原因在于Linux内核安全策略限制了非root进程对其他进程的ptrace操作，这与是否使用sudo无关。
- 排查时，首先检查
/proc/sys/kernel/yama/ptrace_scope文件：默认值为1，会拒绝非子进程的attach；临时放开的办法是执行echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope。 - 如果运行在容器中，启动时需要显式添加
--cap-add=SYS_PTRACE；Docker Compose 则配置cap_add: [SYS_PTRACE]。 - 对于systemd托管的服务，还需要添加
SecureBits=keep-caps和CapabilityBoundingSet=CAP_SYS_PTRACE，否则即使使用sudo gdb -p也无法成功。
bt 和 zbacktrace 输出一堆 ??，如何解读？符号缺失解决方案
这是典型的调试符号缺失问题——GDB无法找到PHP或Swoole的调试符号，导致调用栈显示为 ?? 或地址乱码。
- PHP必须通过源码编译，并带上
--enable-debug和--without-opcache（因为Opcache会干扰栈帧）。 - Swoole扩展需要使用
phpize && ./configure --enable-debug重新编译，仅通过pecl安装是不够的。 - 确保
gdb能够加载.gdbinit：启动后执行source /path/to/php-src/.gdbinit，然后输入zbacktrace才能看到PHP函数名。 - 如果仍然显示
swServer_master_onAccept这类C函数但无参数，说明符号表虽然存在但局部变量已被优化掉——编译PHP时必须加上-O0禁用所有优化。
如何利用 info proc mappings 快速定位内存泄漏源头？
该命令不查看代码，只关注进程实际占用了哪些可写可执行内存页，是识别扩展层内存泄漏（如未释放的 swString、zval）最直接的方式。
- 执行
gdb -p $(pgrep -f "php worker") -ex "info proc mappings" -ex "quit"。 - 重点过滤
rwx权限段：使用grep rwx。正常的PHP进程通常只有1–2段（如JIT缓存、libpthread）；如果出现5段以上且地址连续增长，很可能是因为Swoole扩展反复malloc未free。 - 对比两次采样：先记录当前
rwx段的数量和大小，等RSS上升50MB后再运行一次，新增段的起始地址即为泄漏发生位置。 - 获取可疑地址后，使用
dump memory提取该段：dump memory /tmp/leak.bin 0x7fabc0000000 0x7fabc0100000，然后交给php-meminfo或pstack分析其内容。
真正困难的并非命令本身，而是当你在 bt 输出中看到满屏的 swReactorEpoll_wait 时，需要意识到问题并不在PHP层——这意味着事件循环已经卡死，应立即检查是否有人在协程中调用了同步阻塞函数（如 sleep()、file_get_contents()、未hook的 curl_exec()），而不是继续翻阅PHP代码。
