Edit report at http://bugs.php.net/bug.php?id=47675&edit=1

 ID:                 47675
 Comment by:         php at marino dot st
 Reported by:        cs at ecn dot purdue dot edu
 Summary:            File descriptor leaked due to HAVE_BROKEN_GETCWD
 Status:             No Feedback
 Type:               Bug
 Package:            Apache2 related
 Operating System:   Solaris 10
 PHP Version:        5.2.9
 Block user comment: N

 New Comment:

I've been trying to track down this file descriptor leakage problem for
months.  I was stuck on 5.2.8 because of it.  I confirm that the issue
is specifically with Solaris 10.  I have opensolaris sxce nevada 130
locally and I've not seen FD leakage on it.



I confirm that patch suggested by bryan at stansell dot org seemed to
correct the problem.  FYI, PHP was spawned and remains persistent for
use with the Litespeed web server (uses the LSAPI interface), so it
would run out of file descriptors between 1 and 12 hours on my site. 
It's a bit disappointing that this error has been present for 5 releases
and was never fixed.


Previous Comments:
------------------------------------------------------------------------
[2010-01-12 15:40:45] bryan at stansell dot org

I finally got a chance to test a theory.  Looks like the volatile
attribute fixed things for me.



#if HAVE_BROKEN_GETCWD

        volatile int old_cwd_fd = -1;

#else



Once I added that, the setjmp/longjmp worked as expected.  I got the
idea from the manpage on Solaris:



     The values of register and  automatic  variables  are  unde-

     fined.  Register  or automatic variables whose value must be

     relied upon must be declared as volatile.



Perhaps it's a gcc/gas/Solaris/x86 optimization somewhere that
overlooked the case, but this is a workaround.  Of course, undefining
HAVE_BROKEN_GETCWD for Solaris also works, if you have a web tree that
isn't restricted in some way.

------------------------------------------------------------------------
[2010-01-09 06:59:22] bryan at stansell dot org

I've encountered this problem using OpenSolaris (snv_115), apache 1.3.41
and php-5.2.12 (via mod_php5).  It was also a problem with php 5.2.9. 
My apache processes continue to accumulate open files pointing to the
directory which contains the php script.



I am using gcc 4.3.3, gnu as, and solaris ld.  It makes me wonder if
it's a compiler-related thing.



I was also talking to a friend and we checked his httpd processes and
saw the same file descriptor leak.  His setup is Solaris 9 (sparc),
apache 1.3.41, php 4.4.8, and gcc 4.0.2.



I worked around my problem by unsetting HAVE_BROKEN_GETCWD.  I have a
couple other ideas on possibly narrowing down the problem, but I haven't
had a chance to try them.

------------------------------------------------------------------------
[2009-06-29 01:00:01] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

------------------------------------------------------------------------
[2009-06-22 00:18:11] d...@php.net

Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".

Thank you for your interest in PHP.


I run OpenSolaris 2009.06 with Apache 2.2.11 and cannot reproduce this 

behavior. The old_cwd_fd is closed. ZEND_EXIT calls zend_bailout which 

jumps back to the end of the try/catch block in php_execute_script where


the descriptor is closed.



Can you be more specific about the behavior you encountered?





------------------------------------------------------------------------
[2009-03-16 16:25:21] cs at ecn dot purdue dot edu

I am using apache 2.2.11.

------------------------------------------------------------------------


The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

    http://bugs.php.net/bug.php?id=47675


-- 
Edit this bug report at http://bugs.php.net/bug.php?id=47675&edit=1

Reply via email to