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

go to bug id or search bugs for

Bug #48104 FD-Leak - FastCGI + auto_prepend
Submitted: 2009-04-29 07:59 UTC Modified: 2009-05-08 01:00 UTC
From: james at jamesreno dot com Assigned:
Status: No Feedback Package: CGI/CLI related
PHP Version: 5.2.9 OS: Debian 5.0.1 (lenny); 2.6.26-2-a
Private report: No CVE-ID: None
View Developer Edit
 [2009-04-29 07:59 UTC] james at jamesreno dot com 
Description:
------------
PHP leaks file descriptors by not closing the requested file at the end of request. 

See: http://pastebin.com/m3edccacf

*** REGARDLESS of suhosin being enabled/compiled or disable and NOT patched, the same problem appears. I have removed suhosin from php and yet the issue still appears. Please dont just "blame suhosin" and ignore this fact.

No third-party modules are enabled - apc has been disabled & uninstalled as well.

This seems like an off-by-one somewhere in relation to the auto_prepend.

removing the auto_prepend statement from the php.ini fixes the problem.

Reproduce code:
---------------
Request http://127.0.0.1/somescript.php

auto_prepend_file = "/tmp/test.php";

#/tmp/test.php
<? include("/tmp/test2.php"); ?>

#/tmp/test2.php
<? echo "hello"; ?>

#/var/www/html/somescript.php
echo " world";

Expected result:
----------------
Output of "hello World";

and PHP should close all of its files it opened.

Actual result:
--------------
Output is proper.

PHP opens:
1) /tmp/test.php
2) /tmp/test2.php
3) /var/www/html/somescript.php

however, php only closes:
1) /tmp/test.php
2) /tmp/test2.php

it does NOT close 3) /var/www/html/somescript.php

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2009-04-29 08:18 UTC] james at jamesreno dot com 
strace of the pid is also now included -- i forgot to include it in the previous pastebin url.

http://pastebin.com/mc72a99b
 [2009-04-29 17:00 UTC] james at jamesreno dot com 
[*** NOT TESTED - DO NOT USE ***]

After spending countless hours trying to determine where php is leaking the file descriptors as mentioned in the post. It looks like zend_destroy_file_handle in Zend/zend_language_scanner.c is missing a call to zend_file_handle_dtor on file_handler.

If you add zend_file_handle_dtor(file_handle); it would seem the issue would be fixed.

Is this proper - or is there some reason that zend_destroy_file_handle does not call the destructor zend_file_handle_dtor????
 [2009-04-29 21:53 UTC] james at jamesreno dot com 
Problem still persists. I have not yet found solution to resolve this problem.

More Information:
----------------------------
This leak only happens in fastCGI mode (-b).
It seems that the leak only happens in a subset of files on the server, not every file, but i can not find anything in those files other than the fact that they are larger than the rest (ie: more code). They do not use any weird extensions or special crazy syntax.

I tried to compile with --disable-all --enable-fastcgi, and the problem persists.

I was NOT able to re-produce with the "CGI" binary, stracing shows that php does indeed close the file. Only with -b and running in fastCGI mode does the PHP leak the FD's.


PHP-fcgi is started like so:
----------------------------
su -m -c "nohup env PHP_FCGI_CHILDREN=5 PHP_FCGI_MAX_REQUESTS=1000 bin/php-fcgi-spawn -b 127.0.0.1:8081 -d 'error_log=$PHP_ERRLOG' >> $FCGI_LOG 2>&1 &" apache


Is there anything else you can think of trying? The suggestion i provided in my previous comment, just causes glibc to segfault php with "glibc detected !prev".

In what file is the original file FD closed when executing via FCGI. I notice that the other included files are being closed properly, but just not the main executed .php.
 [2009-04-30 08:30 UTC] jani@php.net 
Please try using this CVS snapshot:

  http://snaps.php.net/php5.3-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/
 [2009-05-01 03:29 UTC] james at jamesreno dot com 
The php5.3-200904291830 snapshot worked - yes.   I am not for sure what causes this in 5.2.9 but 5.3 fixes the problem.  I generally dont like running beta/rc software in production however looks like this is my only choice currently.

Any ideas what could cause this issue?
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Fri Dec 27 02:01:29 2024 UTC