Edit report at https://bugs.php.net/bug.php?id=69154&edit=1
ID: 69154
User updated by: mberchtold at gmail dot com
Reported by: mberchtold at gmail dot com
Summary: Access violation in php7.dll!_emalloc
-Status: Feedback
+Status: Open
Type: Bug
Package: *General Issues
Operating System: Windows Server 2012 R2
PHP Version: master-Git-2015-03-01 (snap)
Block user comment: N
Private report: N
New Comment:
mail is configured and mails are sent despite the crash. In other parts of the code a call to mail
does not trigger the crash.
I already performed the following tests:
- Wrote arguments of mail to log and tried to recreate the crash on the same system/php
configuration. I wasn't able reproduce the crash with the same mail arguments.
- Called mail like this: mail('valid@host.com', '', '')
this still caused the crash
The email is sent
Conclusion: mail arguments seem to be irrelevant.
- On the production system, I have commented out the following in php.ini
; For Win32 only.
;SMTP = localhost
;smtp_port = 25
This triggers the crash for other calls to mail as well.
- Disabled opcache by commenting out the zend_extension:
;zend_extension = php_opcache.dll
-> No crash
Previous Comments:
------------------------------------------------------------------------
[2015-03-02 22:45:18] ab@php.net
Thanks for sharing the minidump. Here's the flow you could trace
Zend\\EventManager\\EventManager::triggerListeners()
... call_user_func() ...
Zend\\EventManager\\EventManager::triggerListeners()
... call_user_func() ...
Zend\\ServiceManager\\ServiceManager::createServiceViaCallback()
... call_user_func() ...
Zend\\ServiceManager\\ServiceManager::createServiceViaCallback()
... call_user_func() ...
Zend\\Db\\ResultSet\\ResultSet::setArrayObjectPrototype()
... new Zend\\Db\\TableGateway\\TableGateway ...
... crash ...
You seem to be right, something is causing a mem corruption. As there's actually nothing
criminal in the dump, so something must have been happening before and corrupting the memory.
The question about mail(), as you mean it's causing it - is your system actually configured to
send a mail? Depending on yes/no - could you please try the opposite (like if it's supposed to
really send, turn it off). If the crash behavior changes, that were an indicator for the cause to be
exact mail().
And the second thing - were it possible you to catch the concrete values passed to mail()? Even you
could anonymize them, but it were probably worth to check this though debugger. Maybe there were a
chance to workout a repro snippet.
As a side note - to check your dump i've pulled the exact 9dac923 x64 snap, but seems the
symbols were invalid while worky with the pdb you've supplied. Weird, it might be wrong pdb or
rev. About the latest BT you've posted - looks actually same, but please don't use opcache
when creating dumps as it's not an opcache issue but might affect the way how things look (or
was the first one also with opcache? didn't look like that).
Thanks.
------------------------------------------------------------------------
[2015-03-02 14:52:51] mberchtold at gmail dot com
If I had to make a guess I would say the mail function somehow corrupts the heap/memory management
and that is the reason that a following call to _emalloc causes the access violation.
As soon as I uncomment the call to mail I do not experience the access violation.
------------------------------------------------------------------------
[2015-03-02 14:36:58] mberchtold at gmail dot com
The pdb are matching in today's x86 snapshot and I was able to reproduce the crash with x86.
The result is a more meaning stack trace:
php7.dll!_emalloc(unsigned int size) Line 2200 C
> php7.dll!lex_scan(_zval_struct * zendlval) Line 1919 C
php7.dll!zendlex(_zend_parser_stack_elem * elem) Line 1382 C
php7.dll!zendparse() Line 4341 C
php7.dll!compile_file(_zend_file_handle * file_handle, int type) Line 592 C
php7.dll!phar_compile_file(_zend_file_handle * file_handle, int type) Line 3311 C
php_opcache.dll!compile_and_cache_file(_zend_file_handle * file_handle, int type, char * key,
unsigned int key_length, _zend_op_array * * op_array_p, int * from_shared_memory) Line 1392 C
php_opcache.dll!persistent_compile_file(_zend_file_handle * file_handle, int type) Line 1611 C
php7.dll!compile_filename(int type, _zval_struct * filename) Line 640 C
php7.dll!ZEND_INCLUDE_OR_EVAL_SPEC_CV_HANDLER(_zend_execute_data * execute_data) Line 24729 C
php7.dll!execute_ex(_zend_execute_data * execute_data) Line 352 C
php7.dll!zend_call_function(_zend_fcall_info * fci, _zend_fcall_info_cache * fci_cache) Line 847 C
php7.dll!zend_call_method(_zval_struct * object, _zend_class_entry * obj_ce, _zend_function * *
fn_proxy, const char * function_name, unsigned int function_name_len, _zval_struct * retval_ptr, int
param_count, _zval_struct * arg1, _zval_struct * arg2) Line 101 C
php7.dll!zif_spl_autoload_call(_zend_execute_data * execute_data, _zval_struct * return_value)
Line 426 C
php7.dll!zend_call_function(_zend_fcall_info * fci, _zend_fcall_info_cache * fci_cache) Line 866 C
php7.dll!zend_lookup_class_ex(_zend_string * name, const _zval_struct * key, int use_autoload)
Line 1029 C
php7.dll!zend_fetch_class_by_name(_zend_string * class_name, const _zval_struct * key, int
fetch_type) Line 1343 C
php7.dll!ZEND_NEW_SPEC_CONST_HANDLER(_zend_execute_data * execute_data) Line 2881 C
php7.dll!execute_ex(_zend_execute_data * execute_data) Line 352 C
php7.dll!zend_call_function(_zend_fcall_info * fci, _zend_fcall_info_cache * fci_cache) Line 847 C
php7.dll!zif_call_user_func(_zend_execute_data * execute_data, _zval_struct * return_value) Line
4725 C
php7.dll!ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER(_zend_execute_data * execute_data) Line 649 C
php7.dll!execute_ex(_zend_execute_data * execute_data) Line 352 C
php7.dll!zend_call_function(_zend_fcall_info * fci, _zend_fcall_info_cache * fci_cache) Line 847 C
php7.dll!zif_call_user_func(_zend_execute_data * execute_data, _zval_struct * return_value) Line
4725 C
php7.dll!ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER(_zend_execute_data * execute_data) Line 649 C
php7.dll!execute_ex(_zend_execute_data * execute_data) Line 352 C
php7.dll!zend_execute(_zend_op_array * op_array, _zval_struct * return_value) Line 381 C
php7.dll!zend_execute_scripts(int type, _zval_struct * retval, int file_count, ...) Line 1310 C
php7.dll!php_execute_script(_zend_file_handle * primary_file) Line 2527 C
php-cgi.exe!main(int argc, char * * argv) Line 2439 C
php-cgi.exe!__tmainCRTStartup() Line 536 C
kernel32.dll!@BaseThreadInitThunk@12 () Unknown
ntdll.dll!__RtlUserThreadStart() Unknown
ntdll.dll!__RtlUserThreadStart@8 () Unknown
I have sent the dump by email as well.
------------------------------------------------------------------------
[2015-03-02 13:15:13] mberchtold at gmail dot com
I have sent the crash dump by email.
------------------------------------------------------------------------
[2015-03-02 09:53:30] ab@php.net
First of all, please check with bug #69115. Recently an issue with mail() was fixed.
Secondly, I see a potential issue in the bt supplied. call_user_func() seems to be called
recursively and that can lead to the stack overflow. PHP has no recursion protection for this case.
Please check the script. If that's the case, there'll be probably no need to share the
dump. Otherwise, please send a mail with the link to the dump.
Thanks.
------------------------------------------------------------------------
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=69154
--
Edit this bug report at https://bugs.php.net/bug.php?id=69154&edit=1