首页 > Linux故障排查 > 一例php进程的SIGBUS故障

一例php进程的SIGBUS故障

2016年11月12日

一例php进程的SIGBUS故障

http://blog.druggo.org/post/2013/05/02/一例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”,前两名的连接基本就给出了答案:

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

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

简单说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)

果然是个经常会被改写的文件啊。。。剩下的就交给开发的同学去解决吧。

分类: Linux故障排查 标签:
本文的评论功能被关闭了.