Skip to content

Resource ID space overflow: Better approach to incremental resource id assignment #19253

Open

Description

@sezeryalcin

Description

We have the following simple code that runs in a daemon which is expected to to run very long time. However it looks like a new resource id is assigned every time this runs. And this runs a lot as we write to a ramdisk.
The following code:

61
62 file_put_contents("/dev/shm/somefile.txt", $data, LOCK_EX);
63 

Resulted in this output:

PHP Fatal error:  Resource ID space overflow in cache.class.php on line 62

But I expected this output instead:

No errors.
I understand that file_put_contents() creates a temporary file resource on each run and probably it's reaching  PHP_INT_MAX to cause this fatal error.
There is only one function get_resource_id() to guess and deal with this issue. Workaround is to keep file handles active during execution.

A)
PHP can handle this by resetting it back to 0 and adding a check to compare it to existing active resources(to avoid conflict) If this is not feasible, I could propose following:
1) In addition to get_resource_id(), we need **get_all_resource_ids**() : Return all active variables with resource ids
2) **resource_id_update**(existing, new) to move active variables to a specific range,
3) **resource_id_range** (0, PHP_INT_MAX) : This would reset back to start when max is reached.

With these extra methods, long running processes can allocate their active resources to a range and let dynamic resource id allocation out of conflict.

B) Another simpler approach could be: Assuming program creates all permanent resources for that run session after a few seconds, program can call a new method: resource_set_dynamic(). This method should record current+1 resource id in memory as "start point" and whenever overflow is due, it can reset it back to start point. This would avoid conflict with permanent resources which would be already created.

C) Checking against existing IDs could be another approach but this may have some impact on performance.

PHP Version

PHP 8.2.7 (cli) (built: Jul 20 2023 18:02:54) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.2.7, Copyright (c) Zend Technologies
    with Zend OPcache v8.2.7, Copyright (c), by Zend Technologies

Operating System

Debian 12.11

Activity

  1. mvorisek commented on Jul 26, 2025

    @mvorisek
    Contributor

    The exception is emit from https://github.com/php/php-src/blob/php-8.2.7/Zend/zend_list.c#L40.

    The limit is defined in https://github.com/php/php-src/blob/php-8.2.7/Zend/zend_long.h#L35.

    The question is why you are using 32-bit PHP? Is that intentional?

    On 64-bit, you would need to live forever to hit the limit :)

    (the limit was 32-bit until PHP 8.1 https://github.com/php/php-src/blob/php-8.0.30/Zend/zend_list.c#L40, but you are on PHP 8.2.x already)

  2. sezeryalcin commented on Jul 27, 2025

    @sezeryalcin
    Author

    This is an older RPI device. It does have arm64 bit OS on it.
    Linux base2.local 6.12.34+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.12.34-1+rpt1~bookworm (2025-06-26) aarch64 GNU/Linux

    We could wrap around file_put_contents to keep file open to avoid resource id increment. I wouldnt take long to hit the limit if you loop it.

  3. iluuu1994 commented on Jul 29, 2025

    @iluuu1994
    Member

    Resources are in the process of being phased out. I suspect there's likely little interest in solving this issue now. But this may potentially be addressed by storing a free-list of indexes of freed resource IDs, with the caveat of resource IDs no longer being unique over the lifetime of an application.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions