HighWayToHell - Tag - lex_scan
花园里, 篱笆下
2023-08-13T10:38:15+08:00
Druggo
urn:md5:79dfcacdbfd6434dfc57423d51240051
Dotclear
一例php进程的SIGBUS故障
urn:md5:acabe3b168ecf55bdc9593843f67f4a5
2013-05-02T21:46:00+08:00
2013-05-02T23:02:24+08:00
Druggo
计算机
coredumpgdblex_scanlinuxphpsigbus
<p>某个子站是php写的,访问的时候nginx时不时会冒出现502错误,高峰时更频繁,检查php-fpm的日志发现大量的 child exited on signal 7 (SIGBUS),并且和accesslog里的502时间完全吻合,排除了php进程过载的可能,然后又排除了apc的嫌疑。</p>
<p>既然php进程是收到信号后死亡的,那么尝试抓些coredump来分析吧:</p>
<p>先设置一下coredump的保存路径,注意要空间够大的地方,因为coredump可能会较多而且很大(比如开了apc设置了1G,那就会有1G):</p>
<pre>
#echo "/tmp/core.%e.%p.%h.%t" > /proc/sys/kernel/core_pattern
</pre>
<p>然后修改下ulimit,允许coredump:</p>
<pre>
#ulimit -c unlimited
</pre>
<p>重启php-fpm。
要不了多久,/tmp/目录里就产生了一堆coredump文件,很好,打包拖回线下来分析吧。
记得关闭coredump,并重启程序:</p>
<pre>
#ulimit -c 0
</pre>
<p>分析coredump一般用gdb就够了,(二进制发行版的话,先安装对应的debug symbol包):</p>
<pre>
gdb /usr/local/php/sbin/php-fpm core.php-fpm.10375.php.1365314990
</pre>
<p>执行下bt命令,看下backtrace(具体的信息忘记记录了),发现是挂在lex_scan函数,看了好几个coredump,基本都是挂在lex阶段的函数。</p>
<p>我对php源码没什么研究,上google搜一下“php sigbus lex_scan”,前两名的连接基本就给出了答案:</p>
<ul>
<li><a href="https://bugs.php.net/bug.php?id=52752">https://bugs.php.net/bug.php?id=52752</a></li>
</ul>
<p>2010年报的bug,一直没有close,因为看起来这并不是php的bug,仔细看,里面有重现的范例,最后也有人找到了规避办法。</p>
<ul>
<li><a href="http://zecrazytux.net/troubleshooting/php-sigbus-crash-prestashop">http://zecrazytux.net/troubleshooting/php-sigbus-crash-prestashop</a></li>
</ul>
<p>此君经历了和我一样的分析过程,并且给出了明确的原因和解决办法。</p>
<p>简单说lex_scan是在对php文件进行语法分析,这个时候正好一个包含的php文件被改写,于是悲剧发生。</p>
<p>为了证实,我用strace跟踪php进程的执行,最后终于抓到了:</p>
<blockquote><p>11670 lstat("/home", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0</p>
<p>
11670 stat("/home/www/cache/default.php", {st_mode=S_IFREG|0644, st_size=68579, ...}) = 0</p>
<p>
11670 --- SIGBUS (Bus error) @ 0 (0)</p></blockquote>
<p>果然是个经常会被改写的文件啊。。。剩下的就交给开发的同学去解决吧。</p>
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#comment-form
http://blog.druggo.org/feed/atom/comments/243