很多站长朋友们都不太清楚php显示调用堆栈，今天小编就来给大家整理php显示调用堆栈，希望对各位有所帮助，具体内容如下：
本文目录一览： 1、 PHP has encountered a Stack overflow PHP遇到堆栈溢出 2、 如何调试PHP的Core之获取基本信息 3、 php不打印调用栈 4、 如何查看linux php-fpm.pid位置 5、 php能不能像java那样打印错误堆栈信息到错误日志 PHP has encountered a Stack overflow PHP遇到堆栈溢出你可能是新的环境，你按我的方法试一下，在你的程序外面再建一个目录，然后重新绑定一下程序就可能了，这是权限问题
如何调试PHP的Core之获取基本信息首先, 让生成一个供举例子的Core文件: <?phpfunction recurse($num) { recurse(++$num);} recurse(0); 运行这个PHP文件: $ php test.phpSegmentation fault (core dumped) 这个PHP因为无线递归, 会导致爆栈, 从而造成 segment fault而在PHP的当前工作目录产生Coredump文件(如果你的系统没有产生Coredump文件, 那请查询ulimit的相关设置). 好, 现在, 让删除掉这个test.php, 忘掉上面的代码, 我们现在仅有的是这个Core文件, 任务是, 找出这个Core产生的原因, 以及发生时候的状态. 首先, 让用gdb打开这个core文件: $ gdb php -c core.31656 会看到很多的信息, 首先让我们注意这段: Core was generated by `php test.php'.Program terminated with signal 11, Segmentation fault. 他告诉我们Core发生的原因:”Segmentation fault”. 一般来说, 这种Core是最常见的, 解引用空指针, double free, 以及爆栈等等, 都会触发SIGSEGV, 继而默认的产生Coredump. 现在让看看Core发生时刻的堆栈: #0 execute (op_array=0xdc9a70) at /home/laruence/package/php-5.2.14/Zend/zend_vm_execute.h:5353 memset(EX(CVs), 0, sizeof(zval**) * op_array->last_var);(gdb) bt#0 execute (op_array=0xdc9a70) at /home/laruence/package/php-5.2.14/Zend/zend_vm_execute.h:53#1 0x00000000006ea263 in zend_do_fcall_common_helper_SPEC (execute_data=0x7fbf400210) at /home/laruence/package/php-5.2.14/Zend/zend_vm_execute.h:234#2 0x00000000006e9f61 in execute (op_array=0xdc9a70) at /home/laruence/package/php-5.2.14/Zend/zend_vm_execute.h:92#3 0x00000000006ea263 in zend_do_fcall_common_helper_SPEC (execute_data=0x7fbf400440) at /home/laruence/package/php-5.2.14/Zend/zend_vm_execute.h:234#4 0x00000000006e9f61 in execute (op_array=0xdc9a70) at /home/laruence/package/php-5.2.14/Zend/zend_vm_execute.h:92#5 0x00000000006ea263 in zend_do_fcall_common_helper_SPEC (execute_data=0x7fbf400670) at /home/laruence/package/php-5.2.14/Zend/zend_vm_execute.h:234..... 不停的按回车, 可以看到堆栈很深, 不停的是zend_do_fcall_common_helper_SPEC和execute的重复, 那么这基本就能断定是因为产生了无穷大的递归(不能一定说是无穷递归, 比如之前文章中介绍深悉正则(pcre)最大回溯/递归限制). 从而造成爆栈产生的Core. Ok, 那么现在让看看, Core发生在PHP的什么函数中, 在PHP中, 对于FCALL_* Opcode的handler来说, execute_data代表了当前函数调用的一个State, 这个State中包含了信息: (gdb)f 1#1 0x00000000006ea263 in zend_do_fcall_common_helper_SPEC (execute_data=0x7fbf400210) at /home/laruence/package/php-5.2.14/Zend/zend_vm_execute.h:234234 zend_execute(EG(active_op_array) TSRMLS_CC);(gdb) p execute_data->function_state.function->common->function_name$3 = 0x2a95b65a78 "recurse"(gdb) p execute_data->function_state.function->op_array->filename$4 = 0x2a95b632a0 "/home/laruence/test.php"(gdb) p execute_data->function_state.function->op_array->line_start$5 = 2 现在我们得到, 在调用的PHP函数是recurse, 这个函数定义在/home/laruence/test.php的第二行 经过重复验证几个frame, 可以看出, 一直是在重复调用这个PHP函数. 要注意的是, 为了介绍查看执行信息的原理, 我才采用原生的gdb的print来查看, 其实我们还可以使用PHP源代码中提供的.gdbinit(gdb命令编写脚本), 来简单的获取到上面的信息: (gdb) source /home/laruence/package/php-5.2.14/.gdbinit(gdb) zbacktrace[0xbf400210] recurse() /home/laruence/test.php:3[0xbf400440] recurse() /home/laruence/test.php:3[0xbf400670] recurse() /home/laruence/test.php:3[0xbf4008a0] recurse() /home/laruence/test.php:3[0xbf400ad0] recurse() /home/laruence/test.php:3[0xbf400d00] recurse() /home/laruence/test.php:3[0xbf400f30] recurse() /home/laruence/test.php:3[0xbf401160] recurse() /home/laruence/test.php:3..... 关于.gdbinit, 是一段小小的脚本文件, 定义了一些方便我们去调试PHP的Core, 大家也可以用文本编辑器打开, 看看里面定义的一些快捷的命令, 一般来说, 我常用的有: zbacktraceprint_ht**系列zmemcheck OK, 回归正题, 我们现在知道, 问题发生在/home/laruence/test.php的recurse函数的递归调用上了. 现在, 让我们来看看, 在调用这个函数的时候的参数是什么? PHP的参数传递是依靠一个全局Stack来完成的, 也就是EG(argument_stack), EG在非多线程情况下就是executor_globals, 它保持了很多执行状态. 而argument_statck就是参数的传递栈, 保存着对应PHP函数调用层数相当的调用参数. 要注意的是, 这个PHP函数调用堆栈(层数)不和gdb所看到的backtrace简单的一一对应, 所以参数也不能直接和gdb的backtrace对应起来, 需要单独分析: //先看看, 最后一次函数调用的参数数目是多少(gdb) p (int )*(executor_globals->argument_stack->top_element - 2)$13 = 1 //再看看, 最后一次函数调用的参数是什么(gdb) p **(zval **)(executor_globals->argument_stack->top_element - 3)$2 = {value = {lval = 22445, dval = 1.1089303420906779e-319, str = {val = 0x57ad <Address 0x57ad out of bounds>, len = 7}, ht = 0x57ad, obj = {handle = 22445, handlers = 0x7}}, refcount = 2, type = 1 '\001', is_ref = 0 '\0'} 好, 我们现在得到, 最后一次调用的参数是一个整数, 数值是22445 到了这一步, 我们就得到了这个Core发生的时刻的PHP层面的相关信息, 接下来, 就可以交给对应的PHP开发工程师来排查, 这个参数下, 可能造成的无穷大递归的原因, 从而修复这个问题..
php不打印调用栈基于以上原因，今天我们就来讲一讲在 PHP 项目当中，怎样快速得到 PHP 调用栈。
PHP 调用栈，顾名思义就是从我们 Web 访问项目的时候，PHP 从执行开始到返回给我们结果的这一系列操作的 PHP 类/方法等调用的过程。
一、利用 XDebug 扩展的 xdebug_get_function_stack() 函数
对 XDebug 扩展了解的同学，可以知道 XDebug 的功能主要用于代码调试。其中，XDebug 就提供了一个非常有用的函数：xdebug_get_function_stack()。
从这个函数的的名字我们可以知道它就是获取方法调用栈的。
我们只需要在项目当中放到 PHP 脚本当中，只要这个方法被执行到。那么，这个方法就能打印 PHP 脚本从开始到执行到这个位置的所有调用栈。从而就能解决我们对代码执行流程不清晰的问题。
这个方法会返回一个数组。数据里面包含了执行的脚本文件路径、类名、方法名、参数等信息。
注：该方法生成的调用栈信息相对比较粗糙。对于简单初浅调试完成够用了。同时，要使用这个方法，必须安装 XDebug 扩展。PHP 安装 XDebug 扩展的教程网上很多。这里不赘述。
二、利用 phptrace 扩展查看
phptrace 是一个追踪（trace）PHP 执行流程的工具。这是奇虎 360 团队开源的一款 PHP 扩展工具。它本身的功能之一就是查看 PHP 调用栈。所以，推荐指数 5 颗星。
项目开源地址：
安装扩展：
$ wget
$ tar zxvf trace-1.0.1beta.tgz
$ cd trace-1.0.1beta/extension
$ {php_bin_dir}/phpize
$ ./configure --with-php-config={php_bin_dir}/php-config
$ make
$ make cli
$ make install-all
然后在 php.ini 配置文件末尾增加：
extension=trace.so
重启我们的 PHP-FPM。
为了能在命令行使用 phptrace 提供的命令，我们还需要在刚刚的 exten
如何查看linux php-fpm.pid位置保证空闲进程数最大值，如果空闲进程大于此值，此进行清理
pm.max_requests = 1000
#设置每个子进程重生之前服务的请求数. 对于可能存在内存泄漏的第三方模块来说是非常有用的. 如果设置为 '0' 则一直接受请求. 等同于 PHP_FCGI_MAX_REQUESTS 环境变量. 默认值: 0.
pm.status_path = /status
#FPM状态页面的网址. 如果没有设置, 则无法访问状态页面. 默认值: none. munin监控会使用到
ping.path = /ping
#FPM监控页面的ping网址. 如果没有设置, 则无法访问ping页面. 该页面用于外部检测FPM是否存活并且可以响应请求. 请注意必须以斜线开头 (/)。
ping.response = pong
#用于定义ping请求的返回相应. 返回为 HTTP 200 的 text/plain 格式文本. 默认值: pong.
request_terminate_timeout = 0
#设置单个请求的超时中止时间. 该选项可能会对php.ini设置中的'max_execution_time'因为某些特殊原因没有中止运行的脚本有用. 设置为 '0' 表示 'Off'.当经常出现502错误时可以尝试更改此选项。
request_slowlog_timeout = 10s
#当一个请求该设置的超时时间后，就会将对应的PHP调用堆栈信息完整写入到慢日志中. 设置为 '0' 表示 'Off'
slowlog = log/$pool.log.slow
#慢请求的记录日志,配合request_slowlog_timeout使用
rlimit_files = 1024
#设置文件打开描述符的rlimit限制. 默认值: 系统定义值默认可打开句柄是1024，可使用 ulimit -n查看，ulimit -n 2048修改。
rlimit_core = 0
#设置核心rlimit最大限制值. 可用值: 'unlimited' 、0或者正整数. 默认值: 系统定义值.
chroot =
#启动时的Chroot目录. 所定义的目录需要是绝对路径. 如果没有设置, 则chroot不被使用.
chdir =
#设置启动目录，启动时会自动Chdir到该目录. 所定义的目录需要是绝对路径. 默认值: 当前目录，或者/目录（chroot时）
catch_workers_output = yes
#重定向运行过程中的stdout和stderr到主要的错误日志文件中. 如果没有设置, stdout 和 stderr 将会根据FastCGI的规则被重定向到 /dev/null . 默认值: 空.
三，常见错误及解决办法整理
1,request_terminate_timeout引起的资源问题
request_terminate_timeout的值如果设置为0或者过长的时间，可能会引起file_get_contents的资源问题。
如果file_get_contents请求的远程资源如果反应过慢，file_get_contents就会一直卡在那里不会超时。我们知道php.ini 里面max_execution_time 可以设置 PHP 脚本的最大执行时间，但是，在 php-cgi(php-fpm) 中，该参数不会起效。真正能够控制 PHP 脚本最大执行时间的是 php-fpm.conf 配置文件中的request_terminate_timeout参数。
request_terminate_timeout默认值为 0 秒，也就是说，PHP 脚本会一直执行下去。这样，当所有的 php-cgi 进程都卡在 file_get_contents() 函数时，这台 Nginx+PHP 的 WebServer 已经无法再处理新的 PHP 请求了，Nginx 将给用户返回“502 Bad Gateway”。修改该参数，设置一个 PHP 脚本最大执行时间是必要的，但是，治标不治本。例如改成 30s，如果发生 file_get_contents() 获取网页内容较慢的情况，这就意味着 150 个 php-cgi 进程，每秒钟只能处理 5 个请求，WebServer 同样很难避免”502 Bad Gateway”。解决办法是request_terminate_timeout设置为10s或者一个合理的值，或者给file_get_contents加一个超时参数。
$ctx = stream_context_create(array(
'http' => array(
'timeout' => 10 //设置一个超时时间，单位为秒
)
));
file_get_contents($str, 0, $ctx);
2,max_requests参数配置不当，可能会引起间歇性502错误：
1
pm.max_requests = 1000
设置每个子进程重生之前服务的请求数. 对于可能存在内存泄漏的第三方模块来说是非常有用的. 如果设置为 ’0′ 则一直接受请求. 等同于 PHP_FCGI_MAX_REQUESTS 环境变量. 默认值: 0.
这段配置的意思是，当一个 PHP-CGI 进程处理的请求数累积到 500 个后，自动重启该进程。
但是为什么要重启进程呢？
一般在项目中，我们多多少少都会用到一些 PHP 的第三方库，这些第三方库经常存在内存泄漏问题，如果不定期重启 PHP-CGI 进程，势必造成内存使用量不断增长。因此 PHP-FPM 作为 PHP-CGI 的管理器，提供了这么一项监控功能，对请求达到指定次数的 PHP-CGI 进程进行重启，保证内存使用量不增长。
正是因为这个机制，在高并发的站点中，经常导致 502 错误，我猜测原因是 PHP-FPM 对从 NGINX 过来的请求队列没处理好。不过我目前用的还是 PHP 5.3.2，不知道在 PHP 5.3.3 中是否还存在这个问题。
目前我们的解决方法是，把这个值尽量设置大些，尽可能减少 PHP-CGI 重新 SPAWN 的次数，同时也能提高总体性能。在我们自己实际的生产环境中发现，内存泄漏并不明显，因此我们将这个值设置得非常大（204800）。大家要根据自己的实际情况设置这个值，不能盲目地加大。
话说回来，这套机制目的只为保证 PHP-CGI 不过分地占用内存，为何不通过检测内存的方式来处理呢？我非常认同高春辉所说的，通过设置进程的峰值内在占用量来重启 PHP-CGI 进程，会是更好的一个解决方案。
3,php-fpm的慢日志，debug及异常排查神器：
request_slowlog_timeout设置一个超时的参数，slowlog设置慢日志的存放位置
1
tail -f /var/log/
上面的命令即可看到执行过慢的php过程。
大家可以看到经常出现的网络读取超过、Mysql查询过慢的问题，根据提示信息再排查问题就有很明确的方向了。
php能不能像java那样打印错误堆栈信息到错误日志PHP 确实不会输出错误堆栈，但通过函数，还是能够获取到错误堆栈的。
function getBacktrace() {
ob_start();
debug_print_backtrace();
return ob_get_clean();
}
调用上面这个函数取得错误堆栈，再用 file_put_contents('log_path', FILE_APPEND); 写入日志文件即可。
还有一个办法：为 PHP 安装 xdebug 扩展
windows 下的安装方法 安装好后，修改 php.ini
关于php显示调用堆栈的介绍到此就结束了，不知道本篇文章是否对您有帮助呢？如果你还想了解更多此类信息，记得收藏关注本站，我们会不定期更新哦。
查看更多关于php显示调用堆栈 php调用c的详细内容...