php的core问题,net core php

本文目录一览：

• 1、ThinkPHP3.2入口文件引入出错，求大神
• 2、如何调试PHP的Core之获取基本信息
• 3、如何查看php-fpm core dump 文件的错误

ThinkPHP3.2入口文件引入出错，求大神

这个入口文件，引用的是相对路径。

①首先，你要确定和index.php同级的目录下有没有core文件夹，如果有，进去看看有没有ThinkPHP.php。

②如果core目录和index.php不同级，就要根据相对路径去计算，如何定位到core文件夹。

这个问题是小问题，仔细一点，好好拍查一下。

如何调试PHP的Core之获取基本信息

在这个过程中, 会涉及到对PHP的函数调用, PHP的传参, PHP的一些全局变量的知识.

首先, 让我们生成一个供我们举例子的Core文件:

?php

function recurse($num) {

recurse(++$num);

}

recurse(0);

运行这个PHP文件:

$ php test.php

Segmentation 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:53

53 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:234

234 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, 大家也可以用文本编辑器打开, 看看里面定义的一些快捷的命令, 一般来说, 我常用的有:

zbacktrace

print_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-fpm core dump 文件的错误

开启php的coredump输出，修改ulimit -c就可以了，但是很多情况下，会提示权利受限，无法修改

[fukun@10.16.29.xxx]$ ulimit -a

core file size (blocks, -c) 0

data seg size (kbytes, -d) unlimited

scheduling priority (-e) 0

file size (blocks, -f) unlimited

pending signals (-i) 30678

max locked memory (kbytes, -l) 64

max memory size (kbytes, -m) unlimited

open files (-n) 32768

pipe size (512 bytes, -p) 8

POSIX message queues (bytes, -q) 819200

real-time priority (-r) 0

stack size (kbytes, -s) 10240

cpu time (seconds, -t) unlimited

max user processes (-u) 1024

virtual memory (kbytes, -v) unlimited

file locks (-x) unlimited

$ ulimit -c unlimited

-bash: ulimit: core file size: cannot modify limit: Operation not permitted

解决方案：

1.检查配置

看看shell配置里有没有 ulimit -c 0 这种类似的关闭的操作，例如

$HOME/.bash_profile 或者 $HOME/.bashrc 之类的，如果有，注释掉。

#

# Do not produce core dumps

#

# ulimit -c 0

2. 全局coredump开启

使用root用户，修改 /etc/security/limits.conf

# /etc/security/limits.conf

#

# Each line describes a limit for a user in the form:

#

# domain type item value

#

* soft core unlimited

3.退出并从新登录shell，修改配置

ssh fukun@10.16.29.xxx

[fukun@10.16.29.xxx]$ ulimit

-c

先切换成root用户进行设置

su –

ulimit -c unlimited

ulimit -c

unlimited

然后切换回自己的用户进行设置

su – fukun

ulimit -c unlimited

ulimit -c

unlimited

以上3步有可能不是必须的，但是只要按这个步骤来，肯定能设置成功，在其它方法设置不成功的时候，按这个步骤来试试把。