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)
来源：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
最新文章
- Linux2.6内核协议栈系列--TCP协议1.发送
- C#绘制传感器代码
- POJ1466 Girls and Boys（二分图最大点独立集）
- oracle:触发器,自治事务 trigger
- 设置ul阴影效果和边框圆角
- public,private,protected的区别
- Swift的初始化方法
- echo和print的区别
- Windows 上安装 Azure PowerShell及Azure PowerShell部署虚拟机
- 解决long类型传到前端损失精度问题
- react native中使用 react-native-easy-toast 和react-native-htmlview
- BZOJ.4909.[SDOI2017]龙与地下城(正态分布 中心极限定理 FFT Simpson积分)
- 【IE兼容问题】记一次Manifest因为jquery版本不同导致的兼容问题解决方案X-UA-Compatible
- java编程内容之开始
- IP地址 无限网卡的MAC地址
- docker入门——安装(CentOS)、镜像、容器
- (转)一些牛人榜样，多看看他们写的东西（后续整理牛人的blog等）
- mysql IPv4 IPv6
- cannot import name '_validate_lengths' from 'numpy.lib.arraypad'
- zrrx笔试题（一）——文件复制&日期天数差