|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
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 Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: james at jamesreno dot com
New email:
PHP Version: OS:


 [2009-04-29 07:59 UTC] james at jamesreno dot com
PHP leaks file descriptors by not closing the requested file at the end of request. 


*** 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:

auto_prepend_file = "/tmp/test.php";

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

<? echo "hello"; ?>

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


Add a Patch

Pull Requests

Add a Pull Request


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.
 [2009-04-29 17:00 UTC] james at jamesreno dot com

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 -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]
Please try using this CVS snapshot:
For Windows:

 [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: Tue May 28 07:01:29 2024 UTC