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.

I have sent the crash dump by email.

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.

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.

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.

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

@mbrechtold, please check the next snaps.

Cheers.

I'm not able to reproduce the crash with the latest snapshot. Thanks.

Thanks for checking.