php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #77357 base64_encode / base64_decode doest not work on nested VM
Submitted: 2018-12-27 09:05 UTC Modified: 2019-01-04 08:09 UTC
From: hsiangjen at gmail dot com Assigned: nikic (profile)
Status: Closed Package: *General Issues
PHP Version: 7.3.0 OS: Windows 2012R2
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: hsiangjen at gmail dot com
New email:
PHP Version: OS:

 

 [2018-12-27 09:05 UTC] hsiangjen at gmail dot com
Description:
------------
The Windows guest machine installed in the nested virtual enviornment (esx -> OpenStack -> Windows 2012R2), the simple code works on php 7.2.13 but 7.3.0

Test script:
---------------
$STRING = '564dace0-391c-42b6-d098-5b7742cb19ee';
$output = base64_encode($STRING);
print_r($output);

Expected result:
----------------
NTY0ZGFjZTAtMzkxYy00MmI2LWQwOTgtNWI3NzQyY2IxOWVl

Actual result:
--------------
Firefox Browser display:

The connection was reset

The connection to the server was reset while the page was loading.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2018-12-27 10:03 UTC] requinix@php.net
-Status: Open +Status: Feedback
 [2018-12-27 10:03 UTC] requinix@php.net
Please read the comments on bug #77284 to see if your problem is the same.
 [2018-12-27 14:57 UTC] hsiangjen at gmail dot com
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
 [2018-12-28 16:34 UTC] cmb@php.net
-Assigned To: +Assigned To: cmb
 [2018-12-28 16:34 UTC] cmb@php.net
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?
 [2018-12-29 16:16 UTC] hsiangjen at gmail dot com
I download "VC15 x64 Thread Safe" from https://windows.php.net/download/ and module with latest build apache from https://www.apachelounge.com/download/
 [2018-12-29 16:59 UTC] cmb@php.net
-Status: Feedback +Status: Open
 [2018-12-29 16:59 UTC] cmb@php.net
Thanks for the info!
 [2018-12-30 13:42 UTC] cmb@php.net
-Status: Assigned +Status: Feedback
 [2018-12-30 13:42 UTC] cmb@php.net
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.
 [2019-01-02 08:13 UTC] hsiangjen at gmail dot com
-Status: Feedback +Status: Open
 [2019-01-02 09:45 UTC] nikic@php.net
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?
 [2019-01-02 09:47 UTC] cmb@php.net
-Status: Assigned +Status: Open -Assigned To: cmb +Assigned To:
 [2019-01-02 09:47 UTC] cmb@php.net
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)
 [2019-01-03 08:43 UTC] hsiangjen at gmail dot com
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.
 [2019-01-03 08:49 UTC] nikic@php.net
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...
 [2019-01-03 09:01 UTC] hsiangjen at gmail dot com
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
 [2019-01-03 09:08 UTC] spam2 at rhsoft dot net
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
 [2019-01-03 09:19 UTC] nikic@php.net
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.
 [2019-01-03 09:28 UTC] nikic@php.net
-Status: Open +Status: Feedback
 [2019-01-03 09:28 UTC] nikic@php.net
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.
 [2019-01-04 02:38 UTC] hsiangjen at gmail dot com
It works for snapshot build revision r5a361c3. Thank you very much for your quick response.
 [2019-01-04 08:09 UTC] nikic@php.net
-Status: Feedback +Status: Closed -Assigned To: +Assigned To: nikic
 [2019-01-04 08:09 UTC] nikic@php.net
Thanks for the confirmation!
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Dec 14 14:01:26 2024 UTC