php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #67845 Resource ids may overflow when running a daemon or large app
Submitted: 2014-08-14 21:02 UTC Modified: -
Votes:1
Avg. Score:4.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:0 (0.0%)
From: blondie101010 at hotmail dot com Assigned:
Status: Open Package: Streams related
PHP Version: Irrelevant OS: Gentoo
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please — but make sure to vote on the bug!
Your email address:
MUST BE VALID
Solve the problem:
16 - 4 = ?
Subscribe to this entry?

 
 [2014-08-14 21:02 UTC] blondie101010 at hotmail dot com
Description:
------------
Working on a socket server, I had wondered what would happen when the resource id would reach 31 bits long, so I used the code below to test it.

Inevitably it failed at 2147483647.

A proactive solution would be for it to wrap once it reaches its limit, of course checking to see if the resource is already assigned.

An alternative would be to reuse freed resource ids but I can already see many bad programmers who would be scared by that option.

Test script:
---------------
<?php

for ($i = 0; $i < 5000000000; $i ++)
{
        $fp = fopen("/dev/null", "w");
        if (($i % 500000) == 0)
        {
                var_dump($fp);
                system("date");
        } // if
        fclose($fp);
} // for

?>

Expected result:
----------------
Keep running as there are actually no resources in use.

Actual result:
--------------
It starts giving errors when it exceeds 31 bits on my 32 bit system.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 
PHP Copyright © 2001-2019 The PHP Group
All rights reserved.
Last updated: Mon Oct 21 17:01:27 2019 UTC