Please read the comments on bug #77284 to see if your problem is the same.

Checked the source code, I think the issue maybe related to new method that using CPU instructions to calculate string.

Here is my VM guest CPU information from CPU-Z.


Number of cores		1 (max 1)
Number of threads	1 (max 1)
Name			Intel Pentium II
Codename		
Specification		QEMU Virtual CPU version 2.0.0
Package (platform ID)	Slot 1 SEPP (0x0)
CPUID			6.6.3
Extended CPUID		6.6
Core Stepping		
Technology		0.25 um
Core Speed		2997.0 MHz
Multiplier x Bus Speed	5.0 x 599.4 MHz
Base frequency (cores)	599.4 MHz
Base frequency (ext.)	599.4 MHz
Stock frequency		333 MHz
Instructions sets	MMX, SSE, SSE2, SSE3, EM64T, VT-x
Microcode Revision	0x1
L1 Data cache		32 KBytes, 8-way set associative, 64-byte line size
L1 Instruction cache	32 KBytes, 8-way set associative, 64-byte line size
L2 cache		4096 KBytes, 16-way set associative, 64-byte line size
Max CPUID level		00000004h
Max CPUID ext. level	8000000Ah
Cache descriptor	Level 1, D, 32 KB, 1 thread(s)
Cache descriptor	Level 1, I, 32 KB, 1 thread(s)
Cache descriptor	Level 2, U, 4 MB, 1 thread(s)
FID/VID Control		no

IBRS			not supported
IBPB			not supported
STIBP			not supported
RDCL_NO			no
IBRS_ALL		not supported

Clock Speed 0		2997.00 MHz (Core #0)
Core 0 max ratio	(effective) 5.0

Did you compile PHP yourself, or are you using a build from
<https://windows.php.net/download/>?  If the former, did you use
the --native-intrinsics configure option?

I download "VC15 x64 Thread Safe" from https://windows.php.net/download/ and module with latest build apache from https://www.apachelounge.com/download/

Thanks for the info!

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.

Please download here for debug dump

https://www.dropbox.com/s/1431ohhj4ikvoor/php__PID__42952__Date__01_02_2019__Time_03_58_11PM__308__Second_Chance_Exception_C000001D_CrashHangAnalysis.mht?dl=0

Stack trace says:

php7ts!php_prefix_varname+8c82 
php7ts!php_prefix_varname+88a7 
php7ts!zend_ast_destroy+230 
php7ts!execute_ex+5f 
php7ts!zend_execute+1a8 
php7ts!zend_execute_scripts+b9 
php7ts!php_execute_script+261 
php!sapi_cli_single_write+1320 
php!sapi_cli_single_write+2298 
php!sapi_cli_single_write+9fa8 
kernel32!BaseThreadInitThunk+22 
ntdll!RtlUserThreadStart+34 

Which doesn't look possible. Maybe the symbols weren't resolved correctly?

Thanks!  Apparently, the actual backtrace is:

    php7ts!php_prefix_varname+8c82
    php7ts!php_prefix_varname+88a7
    php7ts!zend_ast_destroy+230
    php7ts!execute_ex+5f
    php7ts!zend_execute+1a8
    php7ts!zend_execute_scripts+b9
    php7ts!php_execute_script+261
    php!sapi_cli_single_write+1320
    php!sapi_cli_single_write+2298
    php!sapi_cli_single_write+9fa8
    kernel32!BaseThreadInitThunk+22
    ntdll!RtlUserThreadStart+34

    The assembly instruction at php7ts!php_prefix_varname+8c82 in C:\Program Files\SaaSaMe\Transport\php_7.3\php7ts.dll from The PHP Group has caused an unknown exception (0xc000001d)

I chagned order version of Debug Diagonstic tool (version 1.2)

Here is the dump again. 

https://www.dropbox.com/s/00hjbnny4hcomai/CrashHang_Report__Date_01_03_2019__Time_04_40_55PM__58.mht?dl=0

Hope this will help more.

Thank you.

Thanks, that does look more reasonable. We're crashing inphp7ts!php_base64_encode_avx2+82 with a 0xc000001d exception, i.e. illegal instruction. Clearly we're trying to execute an AVX2 instruction on a CPU that doesn't support it. The question is why...

Thank you for the help.

I guess since I am under KVM virtual machine enviornment. The CPU AVX instruction does not passvia to the guest level by default. I will bootup a Linux guest machine to try it also.

Maybe the isseu is like this: https://superuser.com/questions/453786/how-do-i-get-avx-support-in-qemu

https://superuser.com/questions/453786/how-do-i-get-avx-support-in-qemu is about AVX not passed to the guest which in fact happens on your guest given "Instructions sets	MMX, SSE, SSE2, SSE3, EM64T, VT-x"

but in that case PHP must not use the instructions

Okay, I think I see what the issue is. We're not using CPUID correctly. Here is (what I guess) is happening:

 * We're calling CPUID with EAX 7, which is above the maximum basic CPUID level of 4 supported by your CPU.
 * Per Intel instruction set reference, "If a value entered for CPUID.EAX
is higher than the maximum input value for basic or extended function for that processor then the data for the highest basic information leaf is returned."
 * This means we get back the level 4 information.
 * AVX2 support if bit 5 of EBX at level 7, while bits 0-11 of EBX at level 4 are the System Cache Coherence Size minus one. As this is probably a power of 2 >= 64, bit 5 will be set.

We should not be calling CPUID with values above the maximum basic function.

I've committed a possible fix at https://github.com/php/php-src/commit/5a361c3a54c055cdf7088e76aa8efa159334e096. If you could try a snapshot build with this change (once it is available at https://windows.php.net/snapshots/), that would be great.

It works for snapshot build revision r5a361c3. Thank you very much for your quick response.

Thanks for the confirmation!