php进程的SIGBUS故障

某个子站是php写的，访问的时候nginx时不时会冒出现502错误，高峰时更频繁，检查php-fpm的日志发现大量的 child exited on signal 7 (SIGBUS)，并且和accesslog里的502时间完全吻合，排除了php进程过载的可能，然后又排除了apc的嫌疑。

既然php进程是收到信号后死亡的，那么尝试抓些coredump来分析吧：

先设置一下coredump的保存路径，注意要空间够大的地方，因为coredump可能会较多而且很大（比如开了apc设置了1G，那就会有1G）：

#echo "/tmp/core.%e.%p.%h.%t" > /proc/sys/kernel/core_pattern

然后修改下ulimit，允许coredump：

#ulimit -c unlimited

重启php-fpm。 要不了多久，/tmp/目录里就产生了一堆coredump文件，很好，打包拖回线下来分析吧。 记得关闭coredump，并重启程序：

#ulimit -c 0

分析coredump一般用gdb就够了，（二进制发行版的话，先安装对应的debug symbol包）：

gdb /usr/local/php/sbin/php-fpm core.php-fpm.10375.php.1365314990

执行下bt命令，看下backtrace（具体的信息忘记记录了），发现是挂在lex_scan函数，看了好几个coredump，基本都是挂在lex阶段的函数。

我对php源码没什么研究，上google搜一下“php sigbus lex_scan”，前两名的连接基本就给出了答案：

• https://bugs.php.net/bug.php?id=52752

2010年报的bug，一直没有close，因为看起来这并不是php的bug，仔细看，里面有重现的范例，最后也有人找到了规避办法。

• http://zecrazytux.net/troubleshooting/php-sigbus-crash-prestashop

此君经历了和我一样的分析过程，并且给出了明确的原因和解决办法。

简单说lex_scan是在对php文件进行语法分析，这个时候正好一个包含的php文件被改写，于是悲剧发生。

为了证实，我用strace跟踪php进程的执行，最后终于抓到了：

11670 lstat("/home", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0

11670 stat("/home/www/cache/default.php", {st_mode=S_IFREG|0644, st_size=68579, ...}) = 0

11670 --- SIGBUS (Bus error) @ 0 (0)

 

 

来源：http://blog.druggo.org/post/2013/05/02/%E4%B8%80%E4%BE%8Bphp%E8%BF%9B%E7%A8%8B%E7%9A%84SIGBUS%E6%95%85%E9%9A%9C