Edit report at https://bugs.php.net/bug.php?id=70805&edit=1
ID: 70805
Updated by: ab@php.net
Reported by: alex dot a dot pott at gmail dot com
Summary: Segmentation faults whilst running Drupal 8 test
suite
-Status: Verified
+Status: Feedback
Type: Bug
Package: Reproducible crash
Operating System: OS X & Linux
PHP Version: 7.0.0RC5
Block user comment: N
Private report: N
New Comment:
@neclimdul, still having a reproduce code were the preferable way. I've a question to ask yet.
Is call_user_func_array() called recursively? From the later backtrace, it might be good the case.
But such recursive calls are often causing stack overflow and there's no protection against
such stuff in PHP (I mean even in PHP5 and earlier). Could you guys please analyze this part? If it
is possible to extract a synthetic repro case, that would rock.
Thanks.
Previous Comments:
------------------------------------------------------------------------
[2015-10-29 17:08:04] ab@php.net
Yeah, I've just switched to MySQL to fix that. Now only can reproduce with APache, the dev
server just hangs. But tested also on Windows and can confirm the BT
> php7ts.dll!_emalloc(unsigned __int64 size) Line 2442 C
php7ts.dll!zend_array_dup(_zend_array * source) Line 1717 C
php7ts.dll!_zval_copy_ctor_func(_zval_struct * zvalue) Line 222 C
php7ts.dll!object_properties_init(_zend_object * object, _zend_class_entry * class_type) Line
1180 C
php7ts.dll!_object_and_properties_init(_zval_struct * arg, _zend_class_entry * class_type,
_zend_array * properties) Line 1285 C
php7ts.dll!ZEND_NEW_SPEC_CONST_HANDLER(_zend_execute_data * execute_data) Line 3356 C
php7ts.dll!execute_ex(_zend_execute_data * ex) Line 417 C
php7ts.dll!zend_call_function(_zend_fcall_info * fci, _zend_fcall_info_cache * fci_cache) Line
855 C
php7ts.dll!zif_call_user_func_array(_zend_execute_data * execute_data, _zval_struct *
return_value) Line 4809 C
php7ts.dll!ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER(_zend_execute_data * execute_data) Line 723 C
php7ts.dll!execute_ex(_zend_execute_data * ex) Line 417 C
php7ts.dll!zend_call_function(_zend_fcall_info * fci, _zend_fcall_info_cache * fci_cache) Line
855 C
php7ts.dll!zif_call_user_func_array(_zend_execute_data * execute_data, _zval_struct *
return_value) Line 4809 C
php7ts.dll!ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER(_zend_execute_data * execute_data) Line 723 C
php7ts.dll!execute_ex(_zend_execute_data * ex) Line 417 C
php7ts.dll!zend_execute(_zend_op_array * op_array, _zval_struct * return_value) Line 459 C
php7ts.dll!zend_execute_scripts(int type, _zval_struct * retval, int file_count, ...) Line 1429 C
php7ts.dll!php_execute_script(_zend_file_handle * primary_file) Line 2471 C
Thanks.
------------------------------------------------------------------------
[2015-10-29 16:52:38] neclimdul at gmail dot com
Sounds like the web user doesn't have access to your sites directory. Changing that should fix
the error.
------------------------------------------------------------------------
[2015-10-29 16:32:34] ab@php.net
Were it possible to extract a reproduce case? I currently have a trouble reproducing it as the test
fails to execute:
An AJAX HTTP error occurred.
HTTP Result Code: 500
Debugging information follows.
Path: /drupal-8.0.0-rc2/index.php/batch?id=6&op=do_nojs&op=do
StatusText: Internal Server Error
ResponseText: {"message":"A fatal error occurred: SQLSTATE[HY000]: General error: 14
unable to open database: sites\/default\/files\/.ht.sqlite-simpletest813778: ATTACH DATABASE
:database AS :prefix; Array\n(\n [:database] =\u003E
sites\/default\/files\/.ht.sqlite-simpletest813778\n [:prefix] =\u003E
simpletest813778\n)\n"}
Or maybe you have a tip how to overrule it?
Thanks.
------------------------------------------------------------------------
[2015-10-28 18:03:10] fabian at tag1consulting dot com
A simple gc_collect_cycles() before the affected code also "solves" the problem.
------------------------------------------------------------------------
[2015-10-28 17:57:17] fabian at tag1consulting dot com
I just confirmed that this is a GC problem:
a) The graph implementation, which is really simple leaks memory - so directed references are not
resolved correctly.
b) Disabling the GC via disable_gc() during the graph operation fixes the segfault.
I assume this is just happening very late in a process, because we first garbage collect wrongly, so
memory is leaked and then we suddenly garbage collect _during_ the graph creation and that wracks
havoc, which also means the backtrace makes sense.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=70805
--
Edit this bug report at https://bugs.php.net/bug.php?id=70805&edit=1