You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Unable to serialize processed SplFixedArrays in PHP 8.2.4 #10907
The above test code works in all commonly active versions: PHP 8.1, PHP 8.0 and PHP 7.4. However the above code does not work only in PHP 8.2.4.
Originally reproduced with Ubuntu 20.04 + PHP 8.2.4.
This is also reproducible in PHP Windows environment using PHP 8.2.4 .
I've check the upgrade notes on PHP 8.2.4. There is nothing that mention between serialize() and SplFixedArray. I'm still learning more about PHP 8.2, so please help me confirm if this is a bug or simply a usage issue. Thank you!
I fixed this particular issue in this commit on my fork: ndossche@042287c
However, the test won't pass yet because I ran into another pre-existing issue...
See the following code: https://3v4l.org/uZH8a of which the output doesn't make sense.
Upon trying to unserialize a property which can be interpreted as a numeric key it actually becomes a numeric key. This causes the property "123" to incorrectly end up in the array instead of the properties. If I manually print out the hashtable entries received in __unserialize, I see that the entry corresponding to what previously was "123" is now the numeric key 123 (i.e. key==NULL && h==123). I can't seem to figure out where and how this happens.
The numeric-like string bug is not an actual problem for this issue I think. I just wanted to test that scenario in my .phpt file to see if I didn't break anything wrt that.
I see that @Girgias is listed as code owner, maybe you can help here (if you want) :) ?
Activity
ndossche commentedon Mar 22, 2023
Can confirm your findings: Does indeed not reproduce on 8.1, but does on 8.2.
PHP crashes with a segfault.
ndossche commentedon Mar 22, 2023
I fixed this particular issue in this commit on my fork: ndossche@042287c
However, the test won't pass yet because I ran into another pre-existing issue...
See the following code: https://3v4l.org/uZH8a of which the output doesn't make sense.
Upon trying to unserialize a property which can be interpreted as a numeric key it actually becomes a numeric key. This causes the property "123" to incorrectly end up in the array instead of the properties. If I manually print out the hashtable entries received in __unserialize, I see that the entry corresponding to what previously was "123" is now the numeric key 123 (i.e. key==NULL && h==123). I can't seem to figure out where and how this happens.
The numeric-like string bug is not an actual problem for this issue I think. I just wanted to test that scenario in my .phpt file to see if I didn't break anything wrt that.
I see that @Girgias is listed as code owner, maybe you can help here (if you want) :) ?
Girgias commentedon Mar 23, 2023
Erg this feels like something related to this change in 7.2: https://www.php.net/manual/en/migration72.incompatible.php#migration72.incompatible.object-array-casts
So I think it is expected behaviour? Looking at the code run on all versions, the behaviour seems consistent since mid PHP 5.4
The fix looks sensible tho
ndossche commentedon Mar 23, 2023
Strange but okay. I'll not touch that behaviour and just amend my test and then create a PR for this. Thanks for having a look.
Fix phpGH-10907: Unable to serialize processed SplFixedArrays in PHP …
Merge branch 'PHP-8.2'
Fix test for GH-10907 with output in different order for master branch
Fix phpGH-10907: Unable to serialize processed SplFixedArrays in PHP …