线上Nginx偶尔出现worker进程直接消失的情况，error_log里只留下一行“worker process exited on signal 11”，除此之外没有任何有效的堆栈信息。这种段错误（SIGSEGV）问题，最有效的手段就是拿到核心转储文件，用gdb还原崩溃现场。本文从系统配置、Nginx编译、gdb分析三个层面，完整梳理Nginx核心转储调试的实践方法。
一、开启核心转储的系统与Nginx配置
核心转储的前提是操作系统允许进程在崩溃时生成core文件。现代Linux发行版默认往往限制了core文件大小为0，需要先确认并修改。可以用ulimit -c查看当前限制，如果输出是0，说明core被禁用了。对于临时生效的场景，在启动Nginx前执行ulimit -c unlimited即可；要让设置持久化，可以编辑/etc/security/limits.conf，添加一行* soft core unlimited。
core文件的保存路径由/proc/sys/kernel/core_pattern控制。默认值可能是core，表示在进程工作目录下生成名为core的文件。建议设置为带可执行文件名和PID的模板，避免多个worker同时崩溃时互相覆盖，例如/var/core/core.%e.%p，其中%e是程序名，%p是进程ID。注意目标目录要提前创建并保证Nginx运行用户有写权限，否则core文件根本落不了地，很多人配置了半天发现没有core文件，多半是栽在这一步。
Nginx自身还有一道开关。在nginx.conf的顶层main区域加上worker_rlimit_core和working_directory两个指令：
worker_rlimit_core 512m; working_directory /var/core/;
worker_rlimit_core让master进程在fork worker时设置RLIMIT_CORE，working_directory指定core文件的落地目录。如果系统层面通过systemd启动Nginx，别忘了systemd会忽略limits.conf，需要在unit文件中加上LimitCORE=infinity。配置完成后可以用kill -SEGV对一个worker进程发送信号做验证，看看指定目录有没有core文件生成。
二、用gdb加载并分析core文件
拿到core文件后，先确认gdb已安装（CentOS下yum install gdb，Ubuntu下apt install gdb）。加载的基本命令格式是gdb 程序路径 core文件路径，注意第一个参数必须是当初崩溃的那个Nginx可执行文件，路径要与线上版本完全一致，否则符号对不上，堆栈会显示成一堆问号。Nginx的master和worker是同一个二进制，所以直接指向nginx的sbin路径即可：
gdb /usr/local/nginx/sbin/nginx /var/core/core.nginx.12345
进入gdb交互界面后，最常用的几个命令要熟记。bt或backtrace打印崩溃时的函数调用栈，这是最核心的信息；bt full会额外打印每一层的局部变量值，信息量更大；frame N切换到第N层栈帧，配合info locals查看该层的局部变量；p 变量名打印变量值；info registers查看寄存器状态，怀疑野指针时可以通过寄存器地址判断内存是否有效。
一个典型的崩溃堆栈大致长这样：
(gdb) bt
#0 0x0000000000432a1f in ngx_http_parse_header_line (r=0x0, b=0x18f4d20, prefix=0)
at src/http/ngx_http_parse.c:1234
#1 0x000000000042e0c2 in ngx_http_process_request_headers (rev=0x18f9a18)
at src/http/ngx_http_request.c:1510
#2 0x0000000000415c98 in ngx_event_process_posted (cycle=0x18e6a80, posted=0x1a2b010)
at src/event/ngx_event_posted.c:94
最顶层的#0帧就是崩溃点。上面的例子中r=0x0说明request指针是空指针，直接解引用就崩了。顺着调用栈往下看，可以还原出“事件循环分发到读事件、进入请求头处理、最后在解析header时踩空指针”的完整路径。如果堆栈显示为??或地址明显不合理（比如栈帧全是同一个地址），通常意味着崩溃时栈本身已经被破坏，多与内存越界写有关，这种情况需要借助栈底残留信息或address sanitizer进一步分析。
三、编译带调试符号的Nginx让堆栈直达源码行
线上Nginx如果是通过包管理器安装的，bt输出往往只有函数地址没有函数名，因为默认编译剥离了调试符号。要获得精确到源码行号的堆栈，最好自己编译一版带调试信息的Nginx。在configure时加上--with-debug参数，同时不要在编译参数里加-s（strip）。GCC编译时加上-g选项：
./configure --with-debug --with-http_ssl_module \
--with-cc-opt="-g -O0"
make && make install
这里有个取舍需要注意：-O0关闭优化能让变量和行号信息最准确，但性能会下降，生产环境高并发场景不宜直接使用；折中方案是用-O2 -g，保留优化同时带调试信息，大部分场景够用。编译完成后，可以用objdump --syms或nm确认二进制里包含debug段。
如果core文件是在没有调试符号的版本上产生的，也有补救办法。只要保留一份与线上二进制完全相同的文件（MD5一致），再加上对应的调试符号文件，用symbol-file命令在gdb里手动加载符号即可。另外，安装CentOS的debuginfo包（如debuginfo-install nginx）也能让gdb自动关联系统仓库里的调试符号。务必保证符号文件和二进制严格同版本，差一个补丁版本行号就会错位，误导排查方向。
四、多worker进程下的实战技巧
Nginx是多进程模型，一台机器上可能同时有十几个worker，core文件名里带PID就是为了区分它们。拿到多个core时优先分析最新的，也可以结合error_log里的“exited on signal 11”时间戳和worker pid来匹配对应的core文件。gdb里执行info proc和p ngx_pid能进一步确认core属于哪个worker。
怀疑问题与第三方模块有关时，可以在gdb里加载时带上模块的符号路径，或者直接用info sharedlibrary查看崩溃时加载了哪些动态库。像lua-nginx-module这类模块的C栈和Lua栈是分离的，bt只看到C层面的入口，此时可以借助模块提供的调试钩子，或者结合ngx.log输出的Lua错误来交叉定位。另外，内存类问题往往不是一次就能复现，建议把coredump_filter设置为包含共享内存段，Nginx的共享内存在排查slab分配问题时很有价值：
echo 0x7f > /proc/<pid>/coredump_filter
最后提醒两点：一是core文件包含进程内存快照，可能含有请求头、cookie等敏感信息，生产环境务必控制目录权限并定期清理；二是排查完成后记得把core_pattern和ulimit恢复或调整到合理值，避免磁盘被大量core文件占满。掌握这套流程后，从“worker莫名退出”到“崩溃在某某函数第几行”，中间只差一次gdb bt的距离。