|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #79034 PHP Fatal error: CPU doesn't support SSE2 in Unknown on line 0
Submitted: 2019-12-26 12:35 UTC Modified: 2020-01-19 04:22 UTC
From: bugreports at gmail dot com Assigned:
Status: No Feedback Package: opcache
PHP Version: master-Git-2019-12-26 (Git) OS: Linux
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 this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Bug Type:
From: bugreports at gmail dot com
New email:
PHP Version: OS:


 [2019-12-26 12:35 UTC] bugreports at gmail dot com
some of the last recent changes in MASTER broke CPU detection at runtime

PHP Fatal error:  CPU doesn't support SSE2 in Unknown on line 0
i doubt that on a IvyBrdige machine :-)

this one was pretty fine and the binaries pass everything
PHP 8.0.0-dev (cli) (built: Dec 22 2019 12:57:58)

also APCu (built within PHP itself by unpack it to the extensions directory) started to behave randomly wrong in some autotest running at build time here in the profile stage of a PGO build and so it's stopped


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2019-12-26 13:16 UTC]
-Status: Open +Status: Feedback
 [2019-12-26 13:16 UTC]
There haven't been any recent changes to the CPU detection code. Can you please bisect which commit introduced the issue? There were only a handful of commits since Dec 22 and none really look relevant.
 [2019-12-26 14:03 UTC] bugreports at gmail dot com
i'm about to dig it out, what i can say for now is that it breaks JIT

comment that two out and all including apcu works fine
;opcache.jit_buffer_size  = 50000000
;opcache.jit = 1235

i first thought the big cleanup commit from today is likely but it's broken before and "substr() expects parameter 1 to be string, int given" in apcu-related code iterating through a array which for sure has string keys as well as that after apcu_delete() values still exists smells like memory corruption
 [2019-12-26 15:39 UTC] bugreports at gmail dot com
here we go (besdies that someone could review the compiler warnings on Fedora 30 with GCC9 which increased with 7.4 and 8.0:

BROKEN: 2 days ago  Dmitry Stogov Build call graph before type inference
OK:     2 days ago  Xinchen Hui Implemented FR #78638 (__PHP_Incomplete_Class should...

the results are all sorts of weird behavior with enabled opcache-jit and "CPU doesn't support SSE2 in Unknown" is only one, it goes from random "1885613 Segmentation fault" over strange behavior in acpu where after apcu_delete() a call of apcu_fetch() still receives the record to "TypeError: substr() expects parameter 1 to be string, int given" when foreach() over a apcu stored array which for sure contains only strings and sometimes all of them mixed

side note:
2 days ago i added '-fno-semantic-interposition' because of and that causes problems too, in fact "Implemented FR #78638 (__PHP_Incomplete_Class should..." had the same behavior and switch to "-fsemantic-interposition" *ssemd* to fix all the troubles - but it didn't really
 [2019-12-30 12:35 UTC]
I've fixed one JIT issue in, but that one was introduced after the referenced commit.
 [2019-12-31 00:02 UTC] bugreports at gmail dot com
tried current MASTER, still random issues, differnt runs, different errors without any change and "Trying to access array offset on value of type array" is something not possible normally i guess

one time even the whole test-suite passed and in the middle of the PGO-profiling spider a demo-website segfault


removing that two lines from "php.ini" and everything is fine

opcache.jit_buffer_size          = 50000000
opcache.jit                      = 1235


PHP Fatal error:  CPU doesn't support SSE2 in Unknown on line 
Trying to access array offset on value of type array line 267: 322863 Segmentation fault
 [2020-01-09 09:28 UTC] bugreports at gmail dot com
PHP 8.0 MASTER is still broken, i don't get why a offending change after which a predictable environment which worked before with 7.2/7.3/7.4/8.0 HEAD with and without JIT worked perfectly fine has now all sort of memory curruptions and sgefaults isn't simply reverted that long

i used to build 7.2-8.0 nearly daily for weeks until that breakage
 [2020-01-09 10:00 UTC]
The referenced change is not at fault, it exposed a bug somewhere else. Unless you are interested in debugging this issue (I can provide instructions, though the first thing to do is of course switch to a debug build), this will only be resolved once someone qualified happens to reproduce this in other code.
 [2020-01-15 18:37 UTC] bugreports at gmail dot com
using "lld" seems to be part of the problem while lld-8.0.0-1.fc30.x86_64 is used here pointed me to try without lld

- export LD="ld.lld"
+ export


but there is still stuff broken in the final PGO binary (latest master) while the intermdiate "profile-gen" suceeds on the whole testsuite and that is currently reproduceable but as said only in ta optimized "profile-use" build

TypeError: substr() expects parameter 1 to be string, null given in api_cache.php:705
line 705: if($cache_key !== NULL && substr($cache_key, 0, $hash_length) === $hash)

TypeError: substr() expects parameter 1 to be string, null given in api_cache.php:707
line 705: if($cache_key !== NULL)
line 706: {
line 707:  if(substr($cache_key, 0, $hash_length) === $hash)


that code is part of the apcu-caching layer and follows "$inventory = apcu_fetch('shm_inventory')" which is looped with "foreach($inventory as $cache_key=>$shm_key)" and so move apcu out of the game don't make any sense

 tar xzf /rpmbuild/SOURCES/apcu-%{apcu_version}.tgz
 mv apcu-%{apcu_version} ./ext/apcu
 sadly another build without changes didn't suceed the testsuit ebecause of random type errors
 honestly i have no idea what's going on here
 TypeError: strtolower() expects parameter 1 to be string, null given
 [2020-01-15 18:51 UTC] bugreports at gmail dot com
foregt it, it#s a gmabling machine with my code and the 3 succesful pgo builds where just random, it's now at "CPU doesn't support SSE2" again, build without JIT for now
 [2020-01-19 04:22 UTC] php-bugs at lists dot php dot net
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.
 [2020-02-27 12:07 UTC] bugreports at gmail dot com

while the performance is horrible compared to 7.4 in the identical setup depending on "opcache.jit" setting it becomes stable

my first hope was disable "enable AVX instruction generation" (because there was alone would be the trigger but it isn't

in case the problem is in that context: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz (IvyBrdige with AVX but no AVX2) and the binary is built in a VMware Workstation guest running Fedora 31, the weird behavior is on the guest as well as on the host 


CPU specific optimization flags: none
JIT trigger: JIT all functions on first script load


corruption: opcache.jit = 1235
corruption: opcache.jit = 0235
no errors:  opcache.jit = 0205




AVG: 3686,04


PHP 8.0 (PRELOAD: BASE, FULL, API - JIT not compiled at all)





AVG: 3568,85

PHP Copyright © 2001-2020 The PHP Group
All rights reserved.
Last updated: Mon Jul 06 22:01:03 2020 UTC