php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Request #47396 resource ids get re-used when opening enough files
Submitted: 2009-02-15 16:02 UTC Modified: 2011-04-08 20:41 UTC
Votes:40
Avg. Score:4.6 ± 0.6
Reproduced:34 of 36 (94.4%)
Same Version:6 (17.6%)
Same OS:8 (23.5%)
From: cweiske@php.net Assigned:
Status: Open Package: Scripting Engine problem
PHP Version: 5.2.9RC2 OS:
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:
28 - 17 = ?
Subscribe to this entry?

 
 [2009-02-15 16:02 UTC] cweiske@php.net 
Description:
------------
Using php for long running daemons and opening files in there can lead to crashes, when resource ids wrap around the integer/long size and come to 0 at last.

There is no sanity check if a resource is already in use when assigning it.

This problem is more likely to appear on 32bit systems than on 64, since it takes ages to overflow that number with 64bit. Still, it is a problem.

Example:
- Open a file -> resource id is now +1
- Open many files. Eventually, it will reach MAX_INT or whatever number that is and wrap around to "-" that number, increasing from now on.
- Double the time, and the script reaches an resource id of 0
- Now chances are very high that the an existing resource is at the same id
- PHP crashes


The problem has been - wrongly - described here:
http://gnuvince.wordpress.com/2008/10/28/php-wrong-for-long-running-processes-wrong-for-america/
The issue is the one I described here

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2009-02-15 16:07 UTC] magicaltux@php.net 
I had a look at the problem inside zend, and found the problem most likely coming from zend_hash.c

       if ((long)h >= (long)ht->nNextFreeElement) {
         ht->nNextFreeElement = h + 1;
       }

If h (the element being inserted) is higher or equal than the current "nNextFreeElement", we set this to h+1.

This does not handles:
- The fact that we might get back to 0
- The fact that once we get back to 0, the "next free element" might be non free (and will most likely be for #1 and #2).
 [2009-06-23 22:47 UTC] jon dot cooke at frogtrade dot com 
IMHO the issue is in zend_register_resource, which uses 
zend_hash_next_free_element to get the index to use... which just 
returns ht->nNextFreeElement, which is always 1 larger than the 
biggest index in the table (later updated as indicates by 
magicaltux)

I'm going to try a different method for finding a free index if the 
next_free_index is big enough and see how it goes.

Time to give some back I think.
 [2011-04-08 20:41 UTC] jani@php.net
-Package: Feature/Change Request +Package: Scripting Engine problem
 [2021-08-11 11:53 UTC] cmb@php.net 
Related To: Bug #67845
 [2021-08-30 14:02 UTC] cmb@php.net 
Related To: Bug #81399
 [2023-03-06 06:36 UTC] croverwnorene8 at googlemail dot com 
Thanks for the information..    https://www.homebargainsportal.net/github.com
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Tue Apr 23 20:01:29 2024 UTC