#43173 [Fbk->Csd]: FastCGI broken due to invalid descriptor
ID: 43173 User updated by: davidb at chelsea dot net Reported By: davidb at chelsea dot net -Status: Feedback +Status: Closed Bug Type: CGI related Operating System: Solaris 2.8 PHP Version: 5.2.4 Assigned To: dmitry New Comment: ARGH. I misunderstood your comment. In retrospect, I see what you were trying to say, and yes, that is indeed the problem. I have closed the bug. Thank you for the clarification. Previous Comments: [2007-11-20 08:50:52] [EMAIL PROTECTED] And my point was that this happened (yes, it was needed to fix certain issues): File: NEWS -8<-- 31 May 2007, PHP 5.2.3 - Changed CGI install target to php-cgi and 'make install' to install CLI when CGI is selected. (Jani) -8<-- So what you have there called 'php' is actually the CLI binary. The cgi binary is called 'php-cgi'.. -------- [2007-11-19 19:35:59] davidb at chelsea dot net Greetings. I don't know how else to convince everyone that I'm using the right file. But, here goes: - I run the EXACT SAME CONFIGURE SCRIPT for 5.2.0 and 5.2.4. It looks like this: ./configure --prefix=/opt/php/5.2.4 \ --with-zlib=/usr/local \ --with-mysql=/usr/local \ --with-db4=/usr/local \ --with-config-file-path=/usr/local/etc/php \ --enable-gd-native-ttf \ --with-jpeg-dir=/usr/local \ --with-openssl=/usr/local \ --with-gd=/usr/local \ --with-png-dir=/usr/local \ --with-freetype-dir=/usr/local \ --with-mhash=/usr/local \ --with-mm=/usr/local \ --with-xsl=/usr/local \ --with-zend-vm=CALL \ --with-curl=/usr/local \ --with-imap=/usr/local \ --with-imap-ssl=/usr/local \ --with-libxml-dir=/usr/local \ --enable-spl \ --enable-calendar \ --enable-fastcgi \ --enable-force-cgi-redirect \ --enable-sockets \ --enable-mbstring You'll know the first line allows us to change the directory that we build in so we can test new versions. - /usr/local/bin/php5 is a symlink pointing to the currently active version on the test machine. We also sometimes exec /opt/php/5.2.4/bin/php directly, there's no difference in failure type. - 5.2.0 works without a problem (as to 5.0.3 and 4.X); 5.2.3 and 5.2.4 do not. - Here's the output of ls -l: -rwxr-xr-x 1 root other39685444 Aug 12 08:34 /opt/php/5.2.0/bin/php* -rwxr-xr-x 1 root other40515124 Aug 6 10:49 /opt/php/5.2.3/bin/php* -rwxr-xr-x 1 root other41271848 Nov 13 10:37 /opt/php/5.2.4/bin/php* We've been doing this with PHP/FastCGI for years now. Please advise. If there's anything else you'd like to see, please let me know and I'll be happy to add it in. How/where does PHP decide to launch in FastCGI mode v. CGI mode when it is exec'd by the web server? Did the win32 changes in 5.2.2 leak into UNIX somehow? [2007-11-19 18:59:34] [EMAIL PROTECTED] And you're sure php5 is the cgi binary and not the CLI binary? As of some version we changed the binary name to be php-cgi. What was the configure line you used? -------------------- [2007-11-16 13:53:20] davidb at chelsea dot net PHP under apache uses it's own process manager to spawn children. I believe you can disable that so Apache does it itself, but I prefer to manage it in PHP so we can control the number of PHP works without editing httpd.conf. Here's the relevant configuration. In httpd.conf, I set up the PHP server as follows: AddHandler php-fastcgi .php SetHandler fastcgi-script Action php-fastcgi /cgi-bin/php DirectoryIndex index.html index.shtml index.php AddType application/x-httpd-php .php FastCgiServer /export/httpd/DOMAINS/fastcgi.com/cgi-bin/php -processes 1 The FastCgiServer is a shell script that execs the PHP process. We use it to set shell variables that we might need: #!/bin/sh PHP_FCGI_CHILDREN=2 export PHP_FCGI_CHILDREN exec /usr/local/bin/php5 All of this has worked fine for PHP 4.X, 5.0.X, 5.1.X, and 5.2.0. It broke sometime after 5.2.0. David. [2007-11-16 13:23:48] [EMAIL PROTECTED] What do you mean in "Using the php proc manager to control children"? Could you show your configuration files. 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/43173 -- Edit this bug report at http://bugs.php.net/?id=43173&edit=1
#43173 [Fbk->Opn]: FastCGI broken due to invalid descriptor
ID: 43173 User updated by: davidb at chelsea dot net Reported By: davidb at chelsea dot net -Status: Feedback +Status: Open Bug Type: CGI related Operating System: Solaris 2.8 PHP Version: 5.2.4 Assigned To: dmitry New Comment: Greetings. I don't know how else to convince everyone that I'm using the right file. But, here goes: - I run the EXACT SAME CONFIGURE SCRIPT for 5.2.0 and 5.2.4. It looks like this: ./configure --prefix=/opt/php/5.2.4 \ --with-zlib=/usr/local \ --with-mysql=/usr/local \ --with-db4=/usr/local \ --with-config-file-path=/usr/local/etc/php \ --enable-gd-native-ttf \ --with-jpeg-dir=/usr/local \ --with-openssl=/usr/local \ --with-gd=/usr/local \ --with-png-dir=/usr/local \ --with-freetype-dir=/usr/local \ --with-mhash=/usr/local \ --with-mm=/usr/local \ --with-xsl=/usr/local \ --with-zend-vm=CALL \ --with-curl=/usr/local \ --with-imap=/usr/local \ --with-imap-ssl=/usr/local \ --with-libxml-dir=/usr/local \ --enable-spl \ --enable-calendar \ --enable-fastcgi \ --enable-force-cgi-redirect \ --enable-sockets \ --enable-mbstring You'll know the first line allows us to change the directory that we build in so we can test new versions. - /usr/local/bin/php5 is a symlink pointing to the currently active version on the test machine. We also sometimes exec /opt/php/5.2.4/bin/php directly, there's no difference in failure type. - 5.2.0 works without a problem (as to 5.0.3 and 4.X); 5.2.3 and 5.2.4 do not. - Here's the output of ls -l: -rwxr-xr-x 1 root other39685444 Aug 12 08:34 /opt/php/5.2.0/bin/php* -rwxr-xr-x 1 root other40515124 Aug 6 10:49 /opt/php/5.2.3/bin/php* -rwxr-xr-x 1 root other41271848 Nov 13 10:37 /opt/php/5.2.4/bin/php* We've been doing this with PHP/FastCGI for years now. Please advise. If there's anything else you'd like to see, please let me know and I'll be happy to add it in. How/where does PHP decide to launch in FastCGI mode v. CGI mode when it is exec'd by the web server? Did the win32 changes in 5.2.2 leak into UNIX somehow? Previous Comments: [2007-11-19 18:59:34] [EMAIL PROTECTED] And you're sure php5 is the cgi binary and not the CLI binary? As of some version we changed the binary name to be php-cgi. What was the configure line you used? -------------------- [2007-11-16 13:53:20] davidb at chelsea dot net PHP under apache uses it's own process manager to spawn children. I believe you can disable that so Apache does it itself, but I prefer to manage it in PHP so we can control the number of PHP works without editing httpd.conf. Here's the relevant configuration. In httpd.conf, I set up the PHP server as follows: AddHandler php-fastcgi .php SetHandler fastcgi-script Action php-fastcgi /cgi-bin/php DirectoryIndex index.html index.shtml index.php AddType application/x-httpd-php .php FastCgiServer /export/httpd/DOMAINS/fastcgi.com/cgi-bin/php -processes 1 The FastCgiServer is a shell script that execs the PHP process. We use it to set shell variables that we might need: #!/bin/sh PHP_FCGI_CHILDREN=2 export PHP_FCGI_CHILDREN exec /usr/local/bin/php5 All of this has worked fine for PHP 4.X, 5.0.X, 5.1.X, and 5.2.0. It broke sometime after 5.2.0. David. [2007-11-16 13:23:48] [EMAIL PROTECTED] What do you mean in "Using the php proc manager to control children"? Could you show your configuration files. -------------------- [2007-11-15 23:28:25] davidb at chelsea dot net I am absolutely, 100% certain that I'm using the right binary. I've gone back and forth multiple times, and it is reproducible. Since this is for http://www.fastcgi.com, I have added incentive to get it figured out. How can I help troubleshoot this? How does php decide if it's running as a CGI or a FastCGI? How did that part of the code change? I'm not a C coder unfortunately (limited read-only knowledge) but from the truss() I'm guessing that the check is failing and it's using the cgi interfaces instead of the fastcgi interface when it wakes up. The web server is running as follows: - apache 1.3.39 - mod_fastcgi (previous versions, and also tried latest release of a few days ago to see if it makes a difference) - Using the php proc manager to control children, NOT the apache procmanager (this is the default mode of operation, or at least it was) - The only environment variable is PHP_FCGI_CHILDRE
#43173 [Fbk->Opn]: FastCGI broken due to invalid descriptor
ID: 43173 User updated by: davidb at chelsea dot net Reported By: davidb at chelsea dot net -Status: Feedback +Status: Open Bug Type: CGI related Operating System: Solaris 2.8 PHP Version: 5.2.4 Assigned To: dmitry New Comment: PHP under apache uses it's own process manager to spawn children. I believe you can disable that so Apache does it itself, but I prefer to manage it in PHP so we can control the number of PHP works without editing httpd.conf. Here's the relevant configuration. In httpd.conf, I set up the PHP server as follows: AddHandler php-fastcgi .php SetHandler fastcgi-script Action php-fastcgi /cgi-bin/php DirectoryIndex index.html index.shtml index.php AddType application/x-httpd-php .php FastCgiServer /export/httpd/DOMAINS/fastcgi.com/cgi-bin/php -processes 1 The FastCgiServer is a shell script that execs the PHP process. We use it to set shell variables that we might need: #!/bin/sh PHP_FCGI_CHILDREN=2 export PHP_FCGI_CHILDREN exec /usr/local/bin/php5 All of this has worked fine for PHP 4.X, 5.0.X, 5.1.X, and 5.2.0. It broke sometime after 5.2.0. David. Previous Comments: [2007-11-16 13:23:48] [EMAIL PROTECTED] What do you mean in "Using the php proc manager to control children"? Could you show your configuration files. [2007-11-15 23:28:25] davidb at chelsea dot net I am absolutely, 100% certain that I'm using the right binary. I've gone back and forth multiple times, and it is reproducible. Since this is for http://www.fastcgi.com, I have added incentive to get it figured out. How can I help troubleshoot this? How does php decide if it's running as a CGI or a FastCGI? How did that part of the code change? I'm not a C coder unfortunately (limited read-only knowledge) but from the truss() I'm guessing that the check is failing and it's using the cgi interfaces instead of the fastcgi interface when it wakes up. The web server is running as follows: - apache 1.3.39 - mod_fastcgi (previous versions, and also tried latest release of a few days ago to see if it makes a difference) - Using the php proc manager to control children, NOT the apache procmanager (this is the default mode of operation, or at least it was) - The only environment variable is PHP_FCGI_CHILDREN=2 - suexec is spawning this As I mentioned before, I have an identical configuration for 5.2.0 and it works fine. Thanks. [2007-11-15 22:53:06] [EMAIL PROTECTED] Are you sure you're loading the right php binary in your apache conf? I can't reproduce this, everything works just fine (although I'm using lighttpd..:) -------------------- [2007-11-15 14:02:38] davidb at chelsea dot net Greetings. I provided this input (or at least, I could swear I did). Here it is again. I feel like a bit of a broken record, as this is clearly related to the major FastCGI work that was done in 5.2.1'ish. Here's the output: Server API CGI/FastCGI The run_configure is IDENTICAL for 5.2.0 and 5.2.4. Also, please note that php doesn't seem to be figuring out it's running as a FastCGI application. Please let me know if there's anything else I can do to help debug this. [2007-11-01 17:47:13] [EMAIL PROTECTED] Was your php compiled with --enable-fastcgi? Try the following command: $ sapi/cgi/php-cgi -i | grep "Server API" Do you see CGI/FastCGI? 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/43173 -- Edit this bug report at http://bugs.php.net/?id=43173&edit=1
#43173 [Fbk->Opn]: FastCGI Broken due to session file - Redux
ID: 43173 User updated by: davidb at chelsea dot net Reported By: davidb at chelsea dot net -Status: Feedback +Status: Open Bug Type: CGI related Operating System: Solaris 2.8 PHP Version: 5.2.4 Assigned To: dmitry New Comment: I am absolutely, 100% certain that I'm using the right binary. I've gone back and forth multiple times, and it is reproducible. Since this is for http://www.fastcgi.com, I have added incentive to get it figured out. How can I help troubleshoot this? How does php decide if it's running as a CGI or a FastCGI? How did that part of the code change? I'm not a C coder unfortunately (limited read-only knowledge) but from the truss() I'm guessing that the check is failing and it's using the cgi interfaces instead of the fastcgi interface when it wakes up. The web server is running as follows: - apache 1.3.39 - mod_fastcgi (previous versions, and also tried latest release of a few days ago to see if it makes a difference) - Using the php proc manager to control children, NOT the apache procmanager (this is the default mode of operation, or at least it was) - The only environment variable is PHP_FCGI_CHILDREN=2 - suexec is spawning this As I mentioned before, I have an identical configuration for 5.2.0 and it works fine. Thanks. Previous Comments: [2007-11-15 22:53:06] [EMAIL PROTECTED] Are you sure you're loading the right php binary in your apache conf? I can't reproduce this, everything works just fine (although I'm using lighttpd..:) ---------------- [2007-11-15 14:02:38] davidb at chelsea dot net Greetings. I provided this input (or at least, I could swear I did). Here it is again. I feel like a bit of a broken record, as this is clearly related to the major FastCGI work that was done in 5.2.1'ish. Here's the output: Server API CGI/FastCGI The run_configure is IDENTICAL for 5.2.0 and 5.2.4. Also, please note that php doesn't seem to be figuring out it's running as a FastCGI application. Please let me know if there's anything else I can do to help debug this. [2007-11-01 17:47:13] [EMAIL PROTECTED] Was your php compiled with --enable-fastcgi? Try the following command: $ sapi/cgi/php-cgi -i | grep "Server API" Do you see CGI/FastCGI? [2007-11-01 17:35:43] [EMAIL PROTECTED] Dmitry, you know it best. :) -------------------- [2007-11-01 13:43:51] davidb at chelsea dot net Description: I don't seem to be able to reopen the previous bug, #43086, as it was marked "bogus". Unfortunately, while this fixed the problem of the semaphore behavior change, it still didn't work. When php tries to read from the socket now, it gets an invalid descriptor: 17997: read(0, 0x007BBA0C, 8192) Err#134 ENOTCONN It actually looks like it's not behaving as the proc manager, but behaving as a regular PHP client. I note that the working php version of 5.2.0 goes into an accept() instead of a read: 18364: fcntl(0, F_SETLKW, 0xFFBEDA38) (sleeping...) Which is the correct behavior. Are there configuration changes that were made that I've missed in the documentation affecting the default behavior under FastCGI? Is it not detecting that it should be running in FastCGI mode right now? The run_configure, build, and Apache environment for 5.2.0 and 5.2.4 are identical, so something has changed in the PHP code. Please advise. -- Edit this bug report at http://bugs.php.net/?id=43173&edit=1
#43173 [NoF->Opn]: FastCGI Broken due to session file - Redux
ID: 43173 User updated by: davidb at chelsea dot net Reported By: davidb at chelsea dot net -Status: No Feedback +Status: Open Bug Type: CGI related Operating System: Solaris 2.8 PHP Version: 5.2.4 Assigned To: dmitry New Comment: Greetings. I provided this input (or at least, I could swear I did). Here it is again. I feel like a bit of a broken record, as this is clearly related to the major FastCGI work that was done in 5.2.1'ish. Here's the output: Server API CGI/FastCGI The run_configure is IDENTICAL for 5.2.0 and 5.2.4. Also, please note that php doesn't seem to be figuring out it's running as a FastCGI application. Please let me know if there's anything else I can do to help debug this. Previous Comments: [2007-11-09 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". [2007-11-01 17:47:13] [EMAIL PROTECTED] Was your php compiled with --enable-fastcgi? Try the following command: $ sapi/cgi/php-cgi -i | grep "Server API" Do you see CGI/FastCGI? [2007-11-01 17:35:43] [EMAIL PROTECTED] Dmitry, you know it best. :) ---------------- [2007-11-01 13:43:51] davidb at chelsea dot net Description: I don't seem to be able to reopen the previous bug, #43086, as it was marked "bogus". Unfortunately, while this fixed the problem of the semaphore behavior change, it still didn't work. When php tries to read from the socket now, it gets an invalid descriptor: 17997: read(0, 0x007BBA0C, 8192) Err#134 ENOTCONN It actually looks like it's not behaving as the proc manager, but behaving as a regular PHP client. I note that the working php version of 5.2.0 goes into an accept() instead of a read: 18364: fcntl(0, F_SETLKW, 0xFFBEDA38) (sleeping...) Which is the correct behavior. Are there configuration changes that were made that I've missed in the documentation affecting the default behavior under FastCGI? Is it not detecting that it should be running in FastCGI mode right now? The run_configure, build, and Apache environment for 5.2.0 and 5.2.4 are identical, so something has changed in the PHP code. Please advise. -- Edit this bug report at http://bugs.php.net/?id=43173&edit=1
#43173 [NEW]: FastCGI Broken due to session file - Redux
From: davidb at chelsea dot net Operating system: Solaris 2.8 PHP version: 5.2.4 PHP Bug Type: CGI related Bug description: FastCGI Broken due to session file - Redux Description: I don't seem to be able to reopen the previous bug, #43086, as it was marked "bogus". Unfortunately, while this fixed the problem of the semaphore behavior change, it still didn't work. When php tries to read from the socket now, it gets an invalid descriptor: 17997: read(0, 0x007BBA0C, 8192) Err#134 ENOTCONN It actually looks like it's not behaving as the proc manager, but behaving as a regular PHP client. I note that the working php version of 5.2.0 goes into an accept() instead of a read: 18364: fcntl(0, F_SETLKW, 0xFFBEDA38) (sleeping...) Which is the correct behavior. Are there configuration changes that were made that I've missed in the documentation affecting the default behavior under FastCGI? Is it not detecting that it should be running in FastCGI mode right now? The run_configure, build, and Apache environment for 5.2.0 and 5.2.4 are identical, so something has changed in the PHP code. Please advise. -- Edit bug report at http://bugs.php.net/?id=43173&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43173&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43173&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43173&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43173&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43173&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43173&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43173&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43173&r=needscript Try newer version:http://bugs.php.net/fix.php?id=43173&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43173&r=support Expected behavior:http://bugs.php.net/fix.php?id=43173&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43173&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43173&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43173&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43173&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43173&r=dst IIS Stability:http://bugs.php.net/fix.php?id=43173&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43173&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43173&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43173&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43173&r=mysqlcfg
#43086 [Fbk->Opn]: FastCGI Broken due to session file
ID: 43086
User updated by: davidb at chelsea dot net
Reported By: davidb at chelsea dot net
-Status: Feedback
+Status: Open
Bug Type: CGI related
Operating System: Solaris 2.8
PHP Version: 5.2.4
New Comment:
I thought I updated this, but I don't see my comments.
The /var/tmp/fastcgi files were where I saved the output when running
truss on the php processes. I looked for the session filenames.
Previously, it seems PHP was opening the session file in the cgi-bin
directory that the php launch script was located in. Now, with the "/"
in front, it's opening it in the root directory which doesn't work.
Previous Comments:
[2007-10-25 12:28:48] [EMAIL PROTECTED]
Exactly where does this /var/tmp/fastcgi.out file come from? (It's
definately not something PHP outputs!)
----
[2007-10-23 15:37:40] davidb at chelsea dot net
Description:
PHP 5.2.1 and forward (I think) breaks under the FastCGI/apache proc
manager. When the parent is launched, it fails to open the socket due
to trying to open the socket in a directory that doesn't allow it. If I
compare two traces of an older version (5.2.0) and the newer version
(running 5.2.4):
Working:
/var/tmp/fastcgi.out:1786: unlink("session_mm_cgi-fcgi3357.sem")
= 0
/var/tmp/fastcgi.out:1786: open("session_mm_cgi-fcgi3357.sem",
O_RDWR|O_CREAT, 0600) = 3
Broken:
/var/tmp/fastcgi1.out:1648: unlink("/session_mm_cli4416.sem")
Err#2 ENOENT
/var/tmp/fastcgi1.out:1648: open("/session_mm_cli4416.sem",
O_RDWR|O_CREAT, 0600) Err#13 EACCES
Note that this puts the "/" in place, which is a bad assumption.
Is it possible this is related to bug 42815 in some way? It's more
severe, in that php won't even run, though.
Reproduce code:
---
PHP fails to start.
Expected result:
I think that this should be hard-coded to a /tmp directory, or else
somewhere else that the php process will have the ability to write to.
Unless there's a way to fix this behavior with a correct php.ini setup.
We're running with vhosts and suexec, so the owner of the php process
manager won't be able to write to the ServerRoot or the root filesystem
(nor do we want it to!)
--
Edit this bug report at http://bugs.php.net/?id=43086&edit=1
#43086 [NEW]: FastCGI Broken due to session file
From: davidb at chelsea dot net
Operating system: Solaris 2.8
PHP version: 5.2.4
PHP Bug Type: CGI related
Bug description: FastCGI Broken due to session file
Description:
PHP 5.2.1 and forward (I think) breaks under the FastCGI/apache proc
manager. When the parent is launched, it fails to open the socket due to
trying to open the socket in a directory that doesn't allow it. If I
compare two traces of an older version (5.2.0) and the newer version
(running 5.2.4):
Working:
/var/tmp/fastcgi.out:1786: unlink("session_mm_cgi-fcgi3357.sem")
= 0
/var/tmp/fastcgi.out:1786: open("session_mm_cgi-fcgi3357.sem",
O_RDWR|O_CREAT, 0600) = 3
Broken:
/var/tmp/fastcgi1.out:1648: unlink("/session_mm_cli4416.sem")
Err#2 ENOENT
/var/tmp/fastcgi1.out:1648: open("/session_mm_cli4416.sem",
O_RDWR|O_CREAT, 0600) Err#13 EACCES
Note that this puts the "/" in place, which is a bad assumption.
Is it possible this is related to bug 42815 in some way? It's more
severe, in that php won't even run, though.
Reproduce code:
---
PHP fails to start.
Expected result:
I think that this should be hard-coded to a /tmp directory, or else
somewhere else that the php process will have the ability to write to.
Unless there's a way to fix this behavior with a correct php.ini setup.
We're running with vhosts and suexec, so the owner of the php process
manager won't be able to write to the ServerRoot or the root filesystem
(nor do we want it to!)
--
Edit bug report at http://bugs.php.net/?id=43086&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=43086&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=43086&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=43086&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=43086&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=43086&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=43086&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=43086&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=43086&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=43086&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=43086&r=support
Expected behavior:http://bugs.php.net/fix.php?id=43086&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=43086&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=43086&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=43086&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43086&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=43086&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=43086&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=43086&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=43086&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=43086&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=43086&r=mysqlcfg
