有时候，使用PHP的第三方扩展之后，可能会发生一些错误，这个时候，可能就需要更底层的方式追踪调试程序发生错误的地方和原因，熟悉linux下C编程的肯定不陌生gdb
首先，使用ulimit -c命令，查看系统是否会生成 core文件。
#返回结果可能是0
ulimit -c
当返回结果为0时，说明系统不会生成core文件，这个时候使用ulimit -c命令改变系统的默认设置
ulimit -c unlimited
#或者
ulimit -c n #n大于0的数字
这样当程序运行错的时候，就会把运行过程记录到core文件里面
一般来说，core文件会在程序运行目录下生成，文件名类似 core.5740
下面开始使用gdb来调试
gdb php -c core.5740
#进入之后显示很多东西，然后不停的 按 输入 bt回车，查看执行流程
#在gdb运行环境中，使用PHP的gdb调试脚本，其中/prefix/php-src-dir 是php的源码目录
source /prefix/php-src-dir/.gdbinit
#zbacktrace会更加精确到PHP的错误
zbacktrace
详细的使用gdb调试PHP的文章，可以参考鸟哥的博客
如何调试PHP的Core之获取基本信息
转自:https://segmentfault.com/a/1190000002703073
在开发过程中，用命令行执行php文件时，报 Segmentation fault，于是到网上求救，大家都说生成一个core文件，查看一下。
什么是core文件啊，我不知道啊。
后来才知道 用gdb调试php时，会把错误原因放到core中。
我这是突然报错误，无法运行php,经过查找错误原因，定位到了xdebug的问题，是因为昨天安装了xdebug，导致今天无法执行php .
我把本机的xdebug卸载了后，就可以了。赞～