Skip to content

Unable to serialize processed SplFixedArrays in PHP 8.2.4 #10907

Closed

Description

@codex-m

Description

The following code:

<?php
ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
error_reporting(E_ALL);

$array = new SplFixedArray(5);

$array[1] = 2;
$array[2] = "test value";
$copy = $array;
$serialized_one = serialize($array);
$object_vars = get_object_vars($array);
foreach ($object_vars as $property_name => $property_value) {    
    $copy[$property_name] = $property_value;
}
$serialized_two = '';
if ($copy === $array) {
    $serialized_two = serialize($copy);
}

if ($serialized_one === $serialized_two) {
    echo "PHP version " . phpversion() . " is ok";
}

Resulted in this output:

500 internal server error or no output

But I expected this output instead:

PHP version 8.2.4 is ok

Notes:

  • 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!

PHP Version

PHP 8.2.4

Operating System

Ubuntu 20.04 / Windows 10

Activity

  1. ndossche commented on Mar 22, 2023

    @ndossche
    Member

    Can confirm your findings: Does indeed not reproduce on 8.1, but does on 8.2.
    PHP crashes with a segfault.

  2. self-assigned this
    on Mar 22, 2023
  3. ndossche commented on Mar 22, 2023

    @ndossche
    Member

    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) :) ?

  4. Girgias commented on Mar 23, 2023

    @Girgias
    Member

    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

  5. ndossche commented on Mar 23, 2023

    @ndossche
    Member

    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.

  6. added a commit that references this issue on Mar 23, 2023
    490dade
  7. added 2 commits that reference this issue on Mar 24, 2023
    bb9480a
    01cb6fb
  8. added a commit that references this issue on Feb 1, 2024
    a082696
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions