php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #67489 PHP Crashes in zend_execute_scripts / zend_vm_execute
Submitted: 2014-06-21 02:13 UTC Modified: 2021-03-16 12:36 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: majo-bugs dot php dot net at pematon dot com Assigned: cmb (profile)
Status: Closed Package: Reproducible crash
PHP Version: 5.4.29 OS: FreeBSD 9.2
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: majo-bugs dot php dot net at pematon dot com
New email:
PHP Version: OS:

 

 [2014-06-21 02:13 UTC] majo-bugs dot php dot net at pematon dot com 
Description:
------------
I get often crashes on FreeBSD 9.2 in zend_execute_scripts / execute (in zend_vm_execute.h). There are two variants of this crash.

Expected result:
----------------
Not crash.

Actual result:
--------------
Variant 1:

Core was generated by `httpd'.
Program terminated with signal 11, Segmentation fault.
#0  execute (op_array=0x807277ff8) at zend_vm_execute.h:363
363	zend_vm_execute.h: No such file or directory.
	in zend_vm_execute.h
[New Thread 802407400 (LWP 102448/httpd)]
#0  execute (op_array=0x807277ff8) at zend_vm_execute.h:363
#1  0x000000080588e737 in zend_execute_scripts (type=2, retval=0x0, file_count=1) at /tmp/portbuild/usr/ports/www/mod_php5/work/php-5.4.29/Zend/zend.c:1315
#2  0x0000000805937ee1 in php_handler (r=0x8071830a0) at /tmp/portbuild/usr/ports/www/mod_php5/work/php-5.4.29/sapi/apache2handler/sapi_apache2.c:669
#3  0x000000000044e91a in ap_run_handler (r=0x8071830a0) at config.c:169
#4  0x0000000000452682 in ap_invoke_handler (r=0x8071830a0) at config.c:439
#5  0x0000000000463f8e in ap_process_async_request (r=0x8071830a0) at http_request.c:317
#6  0x00000000004640cf in ap_process_request (r=0x8071830a0) at http_request.c:363
#7  0x0000000000460815 in ap_process_http_connection (c=0x807145290) at http_core.c:190
#8  0x0000000000458c22 in ap_run_process_connection (c=0x807145290) at connection.c:41
#9  0x000000000046a327 in child_main (child_num_arg=<value optimized out>) at prefork.c:704
#10 0x000000000046a5a4 in make_child (s=0x802453268, slot=11) at prefork.c:800
#11 0x000000000046af06 in prefork_run (_pconf=<value optimized out>, plog=<value optimized out>, s=<value optimized out>) at prefork.c:902
#12 0x00000000004360b2 in ap_run_mpm (pconf=0x802423028, plog=0x80244f028, s=0x802453268) at mpm_common.c:96
#13 0x000000000043021b in main (argc=2, argv=0x7fffffffdd18) at main.c:777

Variant 2 (longer trace, probably because now it is with mod_rewrite):

Core was generated by `httpd'.
Program terminated with signal 11, Segmentation fault.
#0  execute (op_array=0x802639490) at zend_vm_execute.h:363
363	zend_vm_execute.h: No such file or directory.
	in zend_vm_execute.h
[New Thread 802407400 (LWP 101517/httpd)]
#0  execute (op_array=0x802639490) at zend_vm_execute.h:363
#1  0x000000080588e737 in zend_execute_scripts (type=2, retval=0x0, file_count=1) at /tmp/portbuild/usr/ports/www/mod_php5/work/php-5.4.29/Zend/zend.c:1315
#2  0x0000000805937ee1 in php_handler (r=0x807323970) at /tmp/portbuild/usr/ports/www/mod_php5/work/php-5.4.29/sapi/apache2handler/sapi_apache2.c:669
#3  0x000000000044e91a in ap_run_handler (r=0x807323970) at config.c:169
#4  0x0000000000452682 in ap_invoke_handler (r=0x807323970) at config.c:439
#5  0x0000000000463baa in ap_internal_redirect (new_uri=<value optimized out>, r=<value optimized out>) at http_request.c:644
#6  0x000000080546b640 in handler_redirect (r=0x8072fe0a0) at mod_rewrite.c:5105
#7  0x000000000044e91a in ap_run_handler (r=0x8072fe0a0) at config.c:169
#8  0x0000000000452682 in ap_invoke_handler (r=0x8072fe0a0) at config.c:439
#9  0x0000000000463f8e in ap_process_async_request (r=0x8072fe0a0) at http_request.c:317
#10 0x00000000004640cf in ap_process_request (r=0x8072fe0a0) at http_request.c:363
#11 0x0000000000460815 in ap_process_http_connection (c=0x8072ec290) at http_core.c:190
#12 0x0000000000458c22 in ap_run_process_connection (c=0x8072ec290) at connection.c:41
#13 0x000000000046a327 in child_main (child_num_arg=<value optimized out>) at prefork.c:704
#14 0x000000000046a5a4 in make_child (s=0x80244b268, slot=5) at prefork.c:800
#15 0x000000000046af06 in prefork_run (_pconf=<value optimized out>, plog=<value optimized out>, s=<value optimized out>) at prefork.c:902
#16 0x00000000004360b2 in ap_run_mpm (pconf=0x802423028, plog=0x80244f028, s=0x80244b268) at mpm_common.c:96
#17 0x000000000043021b in main (argc=2, argv=0x7fffffffdd18) at main.c:777

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2014-07-03 02:54 UTC] laruence@php.net
-Status: Open +Status: Feedback
 [2014-07-03 02:54 UTC] laruence@php.net 
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with <?php and ends with ?>,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.
 [2014-07-03 09:07 UTC] majo-bugs dot php dot net at pematon dot com
-Status: Feedback +Status: Open
 [2014-07-03 09:07 UTC] majo-bugs dot php dot net at pematon dot com 
Unfortunately I am not able to provide a reproducing script because I am not able to reproduce the problem. If I call the script that causes the crash with exactly the same parameters as the one that has crashed it is not crashing any more. However the script is crashing few times a week (with different parameters / conditions).
 [2014-07-05 21:30 UTC] majo-bugs dot php dot net at pematon dot com 
I tried to analyze the crash dumps little more. I have recompiled the source code without optimizations (without -O2) and added some debug statements.

I have found out that the crash happens in the following method in zend_vm_execute.h:

    ZEND_API void execute(zend_op_array *op_array TSRMLS_DC)

The problem is that:

    execute_data = (zend_execute_data *)zend_vm_stack_alloc(

returns NULL:

    (gdb) p execute_data
    $3 = (zend_execute_data *) 0x0

Can this happen when it is not possible to allocate any additional memory on stack? That the program is using too much memory? Most of the core dumps have 48MB.

The following code:

    /* Initialize execute_data */
    execute_data = (zend_execute_data *)zend_vm_stack_alloc(
            ZEND_MM_ALIGNED_SIZE(sizeof(zend_execute_data)) +
            ZEND_MM_ALIGNED_SIZE(sizeof(zval**) * op_array->last_var * (EG(active_symbol_table) ? 1 : 2)) +
            ZEND_MM_ALIGNED_SIZE(sizeof(temp_variable)) * op_array->T TSRMLS_CC);

is trying to allocate 4944 bytes (144 + 8 * 16 * 2 + 32 * 142):

    (gdb) p alloc_size <-- my debug statement
    $2 = 4944
 [2021-03-16 12:28 UTC] cmb@php.net
-Status: Open +Status: Feedback -Assigned To: +Assigned To: cmb
 [2021-03-16 12:28 UTC] cmb@php.net 
Is that still an issue with any of the actively supported PHP
versions[1]?

[1] <https://www.php.net/supported-versions.php>
 [2021-03-16 12:36 UTC] majo-bugs dot php dot net at pematon dot com
-Status: Feedback +Status: Closed
 [2021-03-16 12:36 UTC] majo-bugs dot php dot net at pematon dot com 
No, we do not have a problem with this issue any more on our servers with the current version of PHP (7.4). I am closing the issue.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Fri Jan 10 12:01:28 2025 UTC