Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.

Since i got not mutch experience in this area to do backtrace and you guide look a little bit outdated,
i'm not sure if i do all right.
But this looks for me as the best result:

ntdll!RtlReportCriticalFailure+88 
ntdll!RtlpReportHeapFailure+2f 
ntdll!RtlpLogHeapFailure+41 
ntdll!RtlFreeHeap+48251 
ucrtbase!_free_base+1b 
ucrtbase!__crt_unique_heap_ptr<char,__crt_internal_free_policy>::~__crt_unique_heap_ptr<char,__crt_internal_free_policy>+c 
ucrtbase!strftime+1a 
php7ts!php_strftime+1fc 
php7ts!xmlParserInputRead+841f 
php7ts!execute_internal+25

Thanks for the further info. The backtrace is mising some info due to the absence of the debug package, I guess. I can't reproduce the crash locally, however the backtrace looks familiar to that in bug #64359. It might be still the same bug in the CRT. 

Maybe yet some factors are relevant to reproduce the bug. Anyway, one more try could be done. I'd ask you to fetch the debug symbols and retry with the backtrace. Alternatively you could share the crash dump somewhere. 

Thanks.

Now I startet directly from cli and
checked all files,
now looks better in my eyes:
ntdll!RtlReportCriticalFailure+88 
ntdll!RtlpReportHeapFailure+2f 
ntdll!RtlpLogHeapFailure+41 
ntdll!RtlFreeHeap+48251 
ucrtbase!_free_base+1b 
ucrtbase!__crt_unique_heap_ptr<char,__crt_internal_free_policy>::~__crt_unique_heap_ptr<char,__crt_internal_free_policy>+c 
ucrtbase!strftime+1a 
php7ts!php_strftime+1fc 
php7ts!zif_strftime+f 
php7ts!ZEND_DO_ICALL_SPEC_RETVAL_USED_HANDLER+6b 
php7ts!execute_ex+78 
php7ts!zend_execute+152 
php7ts!zend_execute_scripts+96 
php7ts!php_execute_script+1f6 
0x14a00000 
ucrtbase!_LocaleUpdate::_LocaleUpdate+115 
php7ts!php_execute_script+c1 
php!do_cli+ea 
php!do_cli+950 
0x004e0000

That's actually same as before. The first one shows something about ext/libxml, but the second one doesn't. The common part is still in strftime, which is a function from the CRT. Unfortunately no much details, as the debug symbols are not used. You can fetch the corresponding debug symbols from https://windows.php.net/downloads/releases/ .

Otherwise, i'm still scratching my head about how to reproduce it. The only laptop with this upgrade doesn't show the regression :/ Perhaps you could also check, whether you're using the latest vc15 redistributable and upgrade it if you don't?

Thanks.

I'm somewhat startled regarding the setlocale() calls, since these
are supposed to fail due to wrong locales, aren't they?

True, they won't work on Windows (should be "english_United States"), but fixing it doesn't repro for me.

Today MS pushed out KB4103721 which "addresses additional issues with updated time zone information".
https://support.microsoft.com/en-us/help/4103721
It brings ucrtbase.dll from version 10.0.17134.12 (at least that's what the Windows SDK has) to 10.0.17134.48. I hate to ask you to install an update as fresh as this but that changelog entry sounds suspiciously relevant.

Ohh, I've also overseen setlocale(). Besides them likely to be failing, they're not thread safe. There could be a race condition, as while one thread calls setlocale(), another one calls strftime(). But since the same does repro on CLI, it is most likely not the case. A good idea is probably to move such code to ICU.

Still, there was issues with strftime alone in the past, when the receiving buffer was initially too small. If the CRT upgrade didn't help, i can provide a test build with an increased initial buffer, lets see. @drop_box, which exact PHP builds do you use?

Thanks.

Well i use here the x86 ts version of php,
on the other hand I try my best to compile my self a debug version,
because i don't understand what the meaning of "debug symbols" is.

Here the output of my 7.2.5 debug x86 ts version:
php7ts_debug.dll!php_strftime(_zend_execute_data * execute_data, _zval_struct * return_value, int gmt) line 1707	C
php7ts_debug.dll!zif_strftime(_zend_execute_data * execute_data, _zval_struct * return_value) line 1740	C
php7ts_debug.dll!ZEND_DO_ICALL_SPEC_RETVAL_USED_HANDLER(_zend_execute_data * execute_data) line 617	C
php7ts_debug.dll!execute_ex(_zend_execute_data * ex) line 59723	C
php7ts_debug.dll!zend_execute(_zend_op_array * op_array, _zval_struct * return_value) line 63760	C
php7ts_debug.dll!zend_execute_scripts(int type, _zval_struct * retval, int file_count, ...) line 1496	C
php7ts_debug.dll!php_execute_script(_zend_file_handle * primary_file) line 2590	C
php.exe!do_cli(int argc, char * * argv) line 1011	C
php.exe!main(int argc, char * * argv) line 1404	C

I also install in the meantime the update: KB4103721
but nothing changed in my eyes (as you see on my backtrace/crash report)

> because i don't understand what the meaning of "debug symbols" is
https://en.wikipedia.org/wiki/Debug_symbol

the debug symbols are what is responsible for outputs like below

php7ts_debug.dll!zif_strftime(_zend_execute_data * execute_data, _zval_struct * return_value) line 1740	C
php7ts_debug.dll!ZEND_DO_ICALL_SPEC_RETVAL_USED_HANDLER(_zend_execute_data * execute_data) line 617	C

since i got the debug version now,
i get an error message which i think could be helpful:
HEAP CORRUPTION DETECTED: before CRT block (#15222) at 0x0721CDB8.
CRT dectected that the application wrote to memory before start of heap buffer.

Memory allocated at
minkernel\crts\ucrt\src\appcrt\time\strftime.cpp(147).

@drop_box, I still have no crash even on the debug build :/ Perhaps it depends on the system locale, dunno. Which locale is on your machine by default? And nevertheless, since you can compile yourself, could you please apply the following and see whether it fixes the issue?

diff --git a/ext/date/php_date.c b/ext/date/php_date.c
index 993a7b11cf..1a8f3a8e83 100644
--- a/ext/date/php_date.c
+++ b/ext/date/php_date.c
@@ -1644,7 +1644,7 @@ PHPAPI void php_strftime(INTERNAL_FUNCTION_PARAMETERS, int gmt)
        zend_long            timestamp = 0;
        struct tm            ta;
        int                  max_reallocs = 5;
-       size_t               buf_len = 256, real_len;
+       size_t               buf_len = 512, real_len;
        timelib_time        *ts;
        timelib_tzinfo      *tzi;
        timelib_time_offset *offset = NULL;

Thanks.

After change and recompile the error msg keep the same.
The default locale is:
LC_COLLATE=C;LC_CTYPE=German_Germany.1252;LC_MONETARY=C;LC_NUMERIC=C;LC_TIME=C

I've created a VM with this update and German locale. The snippet from the description still passes, however :/ Lets see for perhaps more comments or more lucky reproducer. Or if you come up with a patch perhaps, please post. As before, seems it's a bug in the CRT.

Thanks.

Any news on this? Something changed after upgrades or some new repro?

Thanks.

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.