【问题标题】:php7.0.2 Program terminated with signal 11, Segmentation faultphp7.0.2 程序以信号 11 终止,分段错误
【发布时间】:2016-04-20 09:31:40
【问题描述】:

我正在使用 codeigniter(一个 php mvc 框架)运行 php-7.0.2。我遇到了一些导致核心转储的分段错误。而且,我发现这些分段错误是在子 php-fpm 进程关闭和重新启动时随机发生的。我不知道为什么。

使用 gdb "bt" 显示核心转储:

Core was generated by `php-fpm: pool www                                                               '.
Program terminated with signal 11, Segmentation fault.  
\#0  zend_string_release (ht=0x114dae0) at /home/smt/phpng/php-7.0.2/Zend/zend_string.h:269  
269     /home/smt/phpng/php-7.0.2/Zend/zend_string.h: No such file or directory.  
        in /home/smt/phpng/php-7.0.2/Zend/zend_string.h  
Missing separate debuginfos, use: debuginfo-install php7-7.0.2-20160407105024.x86_64  
(gdb) bt  
\#0  zend_string_release (ht=0x114dae0) at /home/smt/phpng/php-7.0.2/Zend/zend_string.h:269  
\#1  zend_hash_destroy (ht=0x114dae0) at /home/smt/phpng/php-7.0.2/Zend/zend_hash.c:1273  
\#2  0x000000000080647b in module_destructor (module=0x14b6ae0)  
    at /home/smt/phpng/php-7.0.2/Zend/zend_API.c:2509  
\#3  0x000000000080075c in module_destructor_zval (zv=<value optimized out>)  
    at /home/smt/phpng/php-7.0.2/Zend/zend.c:615  
\#4  0x000000000080dcff in _zend_hash_del_el_ex (ht=0x1154780)  
    at /home/smt/phpng/php-7.0.2/Zend/zend_hash.c:1013  
\#5  _zend_hash_del_el (ht=0x1154780) at /home/smt/phpng/php-7.0.2/Zend/zend_hash.c:1037  
\#6  zend_hash_graceful_reverse_destroy (ht=0x1154780) at /home/smt/phpng/php-7.0.2/Zend/zend_hash.c:1489  
\#7  0x0000000000800096 in zend_shutdown () at /home/smt/phpng/php-7.0.2/Zend/zend.c:840  
\#8  0x00000000007a2a6a in php_module_shutdown () at /home/smt/phpng/php-7.0.2/main/main.c:2339  
\#9  0x000000000089e45d in main (argc=<value optimized out>, argv=<value optimized out>)  
    at /home/smt/phpng/php-7.0.2/sapi/fpm/fpm/fpm_main.c:1997  
(gdb) quit  

php-fpm.log 如下:

[20-Apr-2016 08:00:02] WARNING: [pool www] child 11751 exited on signal 11 (SIGSEGV - core dumped) after 3600.462022 seconds from start

我对这个错误很好奇。

到目前为止,我确信核心转储是在 fpm 重新启动时发生的。重新启动是由命令“kill -10 fpm-master-process-ids”引起的。或者,当 fpm 处理完 'pm.max_requests' 请求后,它也会重新启动。

但是,核心转储并不是在每次重启时都发生,而且核心转储的概率非常小。我找不到这个角色。

幸运的是,我已经在我们的生产环境中安装了 7.0.5 版本来替换 7.0.2 版本,并且它已经运行了三天而没有核心转储。

我在从 7.0.2 到 7.0.5 的变更日志中找不到任何修改。这正是一个非常奇怪的错误,我想知道原因。谁能告诉我有关此错误的信息?

【问题讨论】:

  • 这是一个错误,将在 7.0.6 中修复
  • 是的,我发现了这个错误bugs.php.net/bug.php?id=71662&edit=3 它说这个错误在 7.0.4 中已修复,但我们在 changlog 中找不到
  • 是什么导致了这个错误?我在 7.0.6 分支中找不到此错误的修改。

标签: php-7


【解决方案1】:

更新到 7.0.5 后,2 周内没有发生核心转储。所以,这个 bug 已经在 7.0.5 中修复了!

我还是不知道这个bug是什么情况。

我是一只好奇的猫。 @_@

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2021-03-27
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2014-01-20
    • 1970-01-01
    相关资源
    最近更新 更多