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

[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

[mvorisek]

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)

[sezeryalcin]

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.

[iluuu1994]

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.