借助GDB分析Apache核心转储文件 排查LAMP栈段错误问题

哥们儿，先别慌，你这套环境出现的段错误和核心转储，大概率是版本兼容性、内存泄漏或者特定代码触发的bug，给你列几个实操性强的排查步骤：

• 优先分析核心转储文件：这是定位段错误最直接的线索
  用gdb工具加载Apache二进制文件和核心转储文件，命令如下：

  gdb /usr/local/apache2/bin/httpd /path/to/core.xxxx
  

  进入gdb后，执行bt full查看完整的调用栈，重点关注最后几行的函数调用——如果段错误发生在mod_php.so相关函数里，那问题大概率出在PHP或其扩展上；如果是libssl.so或Apache的SSL模块函数，那要排查OpenSSL编译或配置问题。
  注意：如果编译Apache时没加调试符号，调用栈可能不够清晰，这种情况下可以尝试重新编译Apache时加上--enable-debug选项（先备份当前二进制文件），或者下载对应版本的调试符号包。

• 检查软件版本的已知Bug：你用的几个组件版本都比较老，大概率存在已修复的段错误问题

  • Apache 2.4.23是2016年的版本，后续的2.4.24+修复了多个mod_ssl和内存管理相关的bug；
  • PHP 7.1.8是2017年的版本，7.1系列后续补丁修复了不少mod_php模式下的内存泄漏和段错误问题；
  • OpenSSL 1.0.2j同样是2016年版本，后续的1.0.2k及以后修复了多个安全和稳定性漏洞，部分漏洞会导致段错误。
    建议先尝试升级到对应系列的最新稳定版（比如Apache 2.4.57，PHP 7.1.33，OpenSSL 1.0.2zh），这些版本都是对应分支的最终维护版，修复了绝大多数已知bug。

• 排查系统资源与配置问题：核心转储文件过大可能和内存溢出有关

  • 检查Apache的MaxRequestWorkers、ServerLimit等配置，确保子进程数量不会超出系统内存承载能力；可以用ps aux | grep httpd统计所有Apache进程的内存占用总和，看是否接近系统总内存；
  • 检查PHP的memory_limit设置，如果单个PHP脚本占用内存过高，可能导致Apache子进程崩溃；
  • 查看系统日志（/var/log/messages或/var/log/syslog），看段错误发生时是否有内存不足（OOM）的记录，如果有，说明是内存耗尽导致的进程崩溃。

• 启用详细日志定位触发场景：

  • 将Apache的LogLevel临时调整为debug（或trace6到trace8，注意会生成大量日志），同时确保ErrorLog路径正确，查看段错误发生前的日志，看是否有SSL握手失败、PHP脚本致命错误等异常信息；
  • 调整PHP配置：设置error_reporting = E_ALL、log_errors = On、error_log = /var/log/php_errors.log，排查是否有PHP脚本或扩展触发的错误导致进程崩溃。

• 逐个排查站点与第三方模块：

  • 临时禁用部分SSL站点，观察段错误是否停止，以此定位是否是某个站点的代码或配置导致的问题；
  • 检查Apache是否加载了第三方模块（比如mod_security、mod_pagespeed等），尝试禁用这些模块，看问题是否消失——部分第三方模块和mod_php、mod_ssl存在兼容性冲突。

内容的提问来源于stack exchange，提问作者jhilgeman