php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #27992 Resource Leak
Submitted: 2004-04-14 11:41 UTC Modified: 2004-04-15 11:12 UTC
From: sean@php.net Assigned:
Status: Not a bug Package: Class/Object related
PHP Version: 4.3.6RC3 OS: Linux (any)
Private report: No CVE-ID: None
 [2004-04-14 11:41 UTC] sean@php.net
Description:
------------
See the attached code; it has been isolated from PEAR (core) and PEAR::Net_Socket.

Basically, after a certain number of iterations (Linux, PHP4.3.4 and 4.3.6RC3, likely others), PHP runs out of file resources.

Warning: fsockopen(): unable to connect to 192.168.100.51:80 in /home/sean/www/dev3/crashing_resources.php on line 51
ERROR: 24 - Too many open files

This SEEMS to be a leak (file handles are never closed?) in method_exists, get_classname or get_parent_classname, because if I remove the ShrunkenPEAR constructor (OR, the _ShrunkenPEAR method), the code does not fail.

Additionally, if I instanciate ShrunkenSocket as $sock = new ShrunkenSocket() (value instead of reference), the error is also absent.  The reason I'm using a reference: PEAR::HTTP_Request instanciates Net_Socket as such.

Also, as mentioned in a comment in the code, if I change the die to an echo, the script segfaults after ~65535 iterations (which seems like an overflow problem). 

** Note: this was originally posted to internals@ (PHP-DEV), but did not get a response.**

This COULD be a critical overflow problem (when segfaulting), but I don't know enough about the matter to declare it so.


Reproduce code:
---------------
http://sean.caedmon.net/php/crashing_resources.phps

Expected result:
----------------
(see description)

Actual result:
--------------
(see description)

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2004-04-14 22:34 UTC] sniper@php.net
Why woudln't it run out of file handles when you never CLOSE the socket..?

 [2004-04-15 10:02 UTC] sean@php.net
First, $sock should get re-allocated in each iteration, thereby forcing the former $sock (and it's ->fp) out of scope.

Second, the connect() method for $sock checks to see if it already has an allocated $fp; and if so, does an fclose.

While this example isn't practical, this problem directly affects PEAR's HTTP_Request code (but this still isn't a PEAR issue).

S

 [2004-04-15 10:05 UTC] gschlossnagle@php.net
The segfault is a known (and I believe wont-be-fixed-in
-4) 
bug in the reference counting implementation.
 [2004-04-15 10:15 UTC] sean@php.net
Segfault: understandable
My real concern is that it seems resources are not being released in this context.

65k is a big number (segfault).
1k not so much (warning; unable to open resource).

S

 [2004-04-15 10:34 UTC] gschlossnagle@php.net
Hi.  This isn't a bug.  In your constructor, you stick a 
reference to $this in $_PEAR_destructor_object_list.  
This gives the object a refcount of 2, so it isn't 
destructed when it falls out of scope.  This is expected 
behavior here.
 [2004-04-15 11:12 UTC] sean@php.net
Ah, now that you point that out, it's clear. Thank you. This is why I posted to internals@, first.

Agreed. Bogus.

S

 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Nov 21 17:01:32 2024 UTC