#44676 [NEW]: instanceof operator is case insensitive
From: ctx2002 at gmail dot com Operating system: Mac ox 10.5 PHP version: 5.2.5 PHP Bug Type: Scripting Engine problem Bug description: instanceof operator is case insensitive Description: PHP is a case sensitive language, but instanceOf is case insensitive. actual php version is 5.2.4, but there is not such version number in drop down list Reproduce code: --- Expected result: bool(false) Actual result: -- bool(true) -- Edit bug report at http://bugs.php.net/?id=44676&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44676&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44676&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44676&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44676&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44676&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44676&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44676&r=needscript Try newer version:http://bugs.php.net/fix.php?id=44676&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44676&r=support Expected behavior:http://bugs.php.net/fix.php?id=44676&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44676&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44676&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44676&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44676&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44676&r=dst IIS Stability:http://bugs.php.net/fix.php?id=44676&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44676&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44676&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44676&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44676&r=mysqlcfg
#44675 [Bgs]: no output from exec()
ID: 44675
User updated by: lagunaloire at argentina dot com
Reported By: lagunaloire at argentina dot com
Status: Bogus
Bug Type: Output Control
Operating System: Linux
PHP Version: 5.2.5
New Comment:
Newly. To call exec from "some.php" you cannot do a require in this
manner:
chdir("somedir");
require("some.php");
You must do it in this manner:
require("somedir/some.php");
And exec() will work in "some.php".
Previous Comments:
[2008-04-08 22:11:57] lagunaloire at argentina dot com
I found the problem. The problem is YOU CANNOT CALL exec() FROM A
REQUIRED PHP. That mean if you require("somepage.php"); in somepage.php
you cannot call exec();
[2008-04-08 22:06:42] lagunaloire at argentina dot com
Not not! I mistake! I just put something in the array like this:
$output=array("nothing here", "nothing there");
And I see that but that does not mean what I'm seing that from the
program what I executed! Just I was seing it from the self php script.
Sorry!! =S It is not working still! I don't get filled the array with
the output for the external program.
[2008-04-08 22:01:15] lagunaloire at argentina dot com
A compilation problem. First I was compiled apache newly and forget to
recompile PHP. I recompiled PHP and it is working now.
[2008-04-08 21:44:28] lagunaloire at argentina dot com
Description:
The exec() function does not fill the &$output array!
I don't get the output from any program what I try to execute in Safe
mode or not.
Reproduce code:
---
exec("program", $output);
print_r($output);
Expected result:
Array
(
[0] => line1
[1] => line2
[2] => line3
)
Actual result:
--
Array () sometimes or nothing at all.
--
Edit this bug report at http://bugs.php.net/?id=44675&edit=1
#44675 [Bgs]: no output from exec()
ID: 44675
User updated by: lagunaloire at argentina dot com
Reported By: lagunaloire at argentina dot com
Status: Bogus
Bug Type: Output Control
Operating System: Linux
PHP Version: 5.2.5
New Comment:
I found the problem. The problem is YOU CANNOT CALL exec() FROM A
REQUIRED PHP. That mean if you require("somepage.php"); in somepage.php
you cannot call exec();
Previous Comments:
[2008-04-08 22:06:42] lagunaloire at argentina dot com
Not not! I mistake! I just put something in the array like this:
$output=array("nothing here", "nothing there");
And I see that but that does not mean what I'm seing that from the
program what I executed! Just I was seing it from the self php script.
Sorry!! =S It is not working still! I don't get filled the array with
the output for the external program.
[2008-04-08 22:01:15] lagunaloire at argentina dot com
A compilation problem. First I was compiled apache newly and forget to
recompile PHP. I recompiled PHP and it is working now.
[2008-04-08 21:44:28] lagunaloire at argentina dot com
Description:
The exec() function does not fill the &$output array!
I don't get the output from any program what I try to execute in Safe
mode or not.
Reproduce code:
---
exec("program", $output);
print_r($output);
Expected result:
Array
(
[0] => line1
[1] => line2
[2] => line3
)
Actual result:
--
Array () sometimes or nothing at all.
--
Edit this bug report at http://bugs.php.net/?id=44675&edit=1
#44675 [Bgs]: no output from exec()
ID: 44675
User updated by: lagunaloire at argentina dot com
Reported By: lagunaloire at argentina dot com
Status: Bogus
Bug Type: Output Control
Operating System: Linux
PHP Version: 5.2.5
New Comment:
Not not! I mistake! I just put something in the array like this:
$output=array("nothing here", "nothing there");
And I see that but that does not mean what I'm seing that from the
program what I executed! Just I was seing it from the self php script.
Sorry!! =S It is not working still! I don't get filled the array with
the output for the external program.
Previous Comments:
[2008-04-08 22:01:15] lagunaloire at argentina dot com
A compilation problem. First I was compiled apache newly and forget to
recompile PHP. I recompiled PHP and it is working now.
[2008-04-08 21:44:28] lagunaloire at argentina dot com
Description:
The exec() function does not fill the &$output array!
I don't get the output from any program what I try to execute in Safe
mode or not.
Reproduce code:
---
exec("program", $output);
print_r($output);
Expected result:
Array
(
[0] => line1
[1] => line2
[2] => line3
)
Actual result:
--
Array () sometimes or nothing at all.
--
Edit this bug report at http://bugs.php.net/?id=44675&edit=1
#44675 [Opn->Bgs]: no output from exec()
ID: 44675
User updated by: lagunaloire at argentina dot com
Reported By: lagunaloire at argentina dot com
-Status: Open
+Status: Bogus
Bug Type: Output Control
Operating System: Linux
PHP Version: 5.2.5
New Comment:
A compilation problem. First I was compiled apache newly and forget to
recompile PHP. I recompiled PHP and it is working now.
Previous Comments:
[2008-04-08 21:44:28] lagunaloire at argentina dot com
Description:
The exec() function does not fill the &$output array!
I don't get the output from any program what I try to execute in Safe
mode or not.
Reproduce code:
---
exec("program", $output);
print_r($output);
Expected result:
Array
(
[0] => line1
[1] => line2
[2] => line3
)
Actual result:
--
Array () sometimes or nothing at all.
--
Edit this bug report at http://bugs.php.net/?id=44675&edit=1
#44669 [Bgs]: object not immediately destructed on error
ID: 44669 User updated by: ob dot php at daevel dot fr Reported By: ob dot php at daevel dot fr Status: Bogus Bug Type: PDO related Operating System: Debian Lenny (testing) PHP Version: 5.2.5 New Comment: But here no object is returned... And thince PHP 5 objects are destroyed when the last "reference" is destroyed, no ? This example is the only case where I see PHP 5 not destroy correctly an object. Previous Comments: [2008-04-08 19:31:29] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php [2008-04-08 19:14:29] crrodriguez at suse dot de This is the expected behaviuor, objects are destroyed at script shutdown. [2008-04-08 08:58:57] ob dot php at daevel dot fr Description: Hello, when catching a connection error in a class extending PDO, the object is not destroyed before end of script. It's really not a big bug, but as the instance is not usable (no instance is returned at all) it should be destroyed no ? Reproduce code: --- Expected result: CONSTRUCT there is an error... but continue the script DESTRUCT NULL SOME WORKS Actual result: -- CONSTRUCT there is an error... but continue the script NULL SOME WORKS DESTRUCT -- Edit this bug report at http://bugs.php.net/?id=44669&edit=1
#44675 [NEW]: no output from exec()
From: lagunaloire at argentina dot com
Operating system: Linux
PHP version: 5.2.5
PHP Bug Type: Output Control
Bug description: no output from exec()
Description:
The exec() function does not fill the &$output array!
I don't get the output from any program what I try to execute in Safe mode
or not.
Reproduce code:
---
exec("program", $output);
print_r($output);
Expected result:
Array
(
[0] => line1
[1] => line2
[2] => line3
)
Actual result:
--
Array () sometimes or nothing at all.
--
Edit bug report at http://bugs.php.net/?id=44675&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44675&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44675&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44675&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44675&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44675&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44675&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44675&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44675&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44675&r=support
Expected behavior:http://bugs.php.net/fix.php?id=44675&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44675&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44675&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44675&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44675&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44675&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44675&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44675&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44675&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44675&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44675&r=mysqlcfg
#44670 [Opn->Bgs]: sed not found
ID: 44670 Updated by: [EMAIL PROTECTED] Reported By: mark at detrick dot com -Status: Open +Status: Bogus -Bug Type: *Directory/Filesystem functions +Bug Type: Compile Failure Operating System: Solaris 10 PHP Version: 5.2.5 New Comment: instdso.sh is an Apache script. PHP has nothing to do with it. Previous Comments: [2008-04-08 13:23:09] mark at detrick dot com Description: Configure does not find sed for use during installation. Defaults to looking in /usr/local/bin/sed. Expected result: No errors during installation. Actual result: -- cesium-bash /appl/php/php-5.2.5 # make install Installing PHP SAPI module: apache2handler /usr/local/apache2/build/instdso.sh SH_LIBTOOL='/usr/local/apache2/build/libtool' libphp5.la /usr/local/apache2/modules /usr/local/apache2/build/libtool --mode=install cp libphp5.la /usr/local/apache2/modules/ /usr/local/apache2/build/libtool: line 387: /usr/local/bin/sed: No such file or directory /usr/local/apache2/build/libtool: line 752: /usr/local/bin/sed: No such file or directory *** Warning: inferring the mode of operation is deprecated. *** Future versions of Libtool will require --mode=MODE be specified. /usr/local/apache2/build/libtool: line 6091: /usr/local/bin/sed: No such file or directory /usr/local/apache2/build/libtool: line 6174: /usr/local/bin/sed: No such file or directory /usr/local/apache2/build/libtool: line 6182: /usr/local/bin/sed: No such file or directory /usr/local/apache2/build/libtool: line 6184: /usr/local/bin/sed: No such file or directory : install: `.' must be an absolute directory name Try ` --help --mode=install' for more information. apxs:Error: Command failed with rc=65536 . make: *** [install-sapi] Error 1 -- Edit this bug report at http://bugs.php.net/?id=44670&edit=1
#44673 [NEW]: argv/argc starts from arguments, not from script
From: jc at chenailler dot com Operating system: gentoo PHP version: 5.2.6RC4 PHP Bug Type: Unknown/Other Function Bug description: argv/argc starts from arguments, not from script Description: Hy, With PHP-5.2.6RC4 i have this probleme when using in command line : usage : php -q test.php a b c d with php <= 5.2.5 this probleme didn't exists. configure for both versions : './configure' '--with-fastcgi=/usr/local' '--enable-simplexml' '--enable-fastcgi' '--enable-force-cgi-redirect' '--prefix=/usr/local/php5' '--disable-cli' '--with-filepro' '--with-mysql=/usr' '--with-xml' '--disable-exif' '--enable-ftp' '--enable-bcmath' '--enable-calendar' '--with-gd' '--enable-gd-native-ttf' '--with-freetype-dir' '--with-gettext' '--with-zlib-dir' '--enable-trans-sid' '--with-kerberos' '--with-openssl' '--enable-sysvsem' '--enable-sysvshm' '--with-gettext' '--with-dom' '--with-mcrypt' '--with-iconv' '--enable-mbstring=all' '--enable-mbregex' '--with-png-dir=/usr' '--with-jpeg-dir=/usr' '--with-mime-magic=/usr/share/misc/file/magic.mime' '--with-config-file-scan-dir=/etc/php.d' '--disable-pdo' '--without-sqlite' '--enable-inline-optimization' Reproduce code: --- Expected result: PHP_VERSION=5.2.5 argc=5 argv=Array ( [0] => test.php [1] => a [2] => b [3] => c [4] => d ) Actual result: -- PHP_VERSION=5.2.6RC4 argc=4 argv=Array ( [0] => a [1] => b [2] => c [3] => d ) -- Edit bug report at http://bugs.php.net/?id=44673&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44673&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44673&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44673&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44673&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44673&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44673&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44673&r=needscript Try newer version:http://bugs.php.net/fix.php?id=44673&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44673&r=support Expected behavior:http://bugs.php.net/fix.php?id=44673&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44673&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44673&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44673&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44673&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44673&r=dst IIS Stability:http://bugs.php.net/fix.php?id=44673&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44673&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44673&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44673&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44673&r=mysqlcfg
#41350 [Com]: Error in my_thread_global_end()
ID: 41350 Comment by: spambox at shad dot pp dot ru Reported By: graham at directhostinguk dot com Status: No Feedback Bug Type: MySQL related Operating System: Windows 2003 PHP Version: 5.2.3 New Comment: Same bug just happened to me in this example: C:\>echo "" |php "MSD" Error in my_thread_global_end(): 1 threads didn't exit MySQL extension was enabled in php.ini, but I didn't use any of it's functions in example. PHP is 5.2.5, no other mysql related dll's are available on system. I posted this just to confirm that bug exists on my system too. Previous Comments: [2008-03-28 22:23:40] stein at visibone dot com Brilliant, Scottmac, I did have some crufty lurking libmysql.dll's. But I'm still getting the 5 second hang. Using the 5.2.5 php_mysql.dll and php_mysqli.dll's the hang happens with a dirt-simple hello-world. With 5.2.1 it happens if I mysql_connect(). Could it be having both mysql and mysqli enabled? I'm using both for unit testing. -- Bob Stein, VisiBone [2008-03-26 20:56:53] lizwatson02452 at yahoo dot com Following up briefly on my previous postchanging to an earlier libmysql.dll appears to have fixed the problem for us, even though we don't use MySQL. Two difficulties with that: 1) It was hard for me to believe that was the solution. 2) It took some doing to persuade our hoster that changing the .dll was not merely a fool's errand. [2008-03-22 22:01:12] lizwatson02452 at yahoo dot com I have this problem, and I am *not* using MySQL. I'm on PHP 5.2.4, with SQL Server. Are there any workarounds that are not MySQL-specific? [2008-03-20 20:05:06] [EMAIL PROTECTED] Try PHP 5.2.5 with the libmysql.dll from http://dev.mysql.com/downloads/mysql/5.0.html#win32 Make sure there are no other libmysql.dll lurking around your path. [2008-03-20 19:39:43] stein at visibone dot com ...free PHP cheatsheet or wall chart to anyone who helps me get around this. ;-) 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/41350 -- Edit this bug report at http://bugs.php.net/?id=41350&edit=1
#44666 [Bgs]: apache2 module seems to ignore --with-tidy compilation option
ID: 44666 User updated by: geoffrey dot hughes at otago dot ac dot nz Reported By: geoffrey dot hughes at otago dot ac dot nz Status: Bogus Bug Type: Apache2 related Operating System: Mac OS X 10.5.2 PHP Version: 5.2.5 New Comment: If it's a misconfigured system, why does phpcli link to the correct libtidy but libphp5.so doesn't when using --with-tidy=/opt/local Previous Comments: [2008-04-08 11:07:24] geoffrey dot hughes at otago dot ac dot nz phpcli returns a loaded libtidy at /opt/local/lib whereas libphp5.so returns a libtidy loaded from /usr/lib It seems you are correct but my next question is why is libphp5.so linked against that one when I've specified a path to tidy in the configure statement. [2008-04-08 10:57:06] [EMAIL PROTECTED] And that's supposed to be *nix? pff.. Well, if you had bothered to use google you would have found that the equivalent for ldd is: otool -L Anyway, as I'm sure this is just a misconfigured system and not a PHP bug -> bogus. [2008-04-08 10:42:25] geoffrey dot hughes at otago dot ac dot nz No ldd in OS X 10.5 [2008-04-08 08:06:02] [EMAIL PROTECTED] I would guess /opt/local/lib is not in your LD_LIBRARY_PATH, hence the shared apache2 module uses whatever it finds in the path. And CLI is propably linked as static..? Try this: # ldd /path/to/cli/binary and # ldd /path/to/libphp5.so [2008-04-08 02:48:15] geoffrey dot hughes at otago dot ac dot nz Description: PHPCLI uses the correct libtidy version when compiled with --with- tidy=/opt/local but the apache2 module uses the leopard default libtidy whether you use --with-tidy=/opt/local or not. PHPCLI Info: libTidy Release => 22 March 2008 Apache2 phpinfo.php: libTidy Release31 October 2006 - Apple Inc. build 13 -- Edit this bug report at http://bugs.php.net/?id=44666&edit=1
#44669 [Opn->Bgs]: object not immediately destructed on error
ID: 44669 Updated by: [EMAIL PROTECTED] Reported By: ob dot php at daevel dot fr -Status: Open +Status: Bogus Bug Type: PDO related Operating System: Debian Lenny (testing) PHP Version: 5.2.5 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Previous Comments: [2008-04-08 19:14:29] crrodriguez at suse dot de This is the expected behaviuor, objects are destroyed at script shutdown. [2008-04-08 08:58:57] ob dot php at daevel dot fr Description: Hello, when catching a connection error in a class extending PDO, the object is not destroyed before end of script. It's really not a big bug, but as the instance is not usable (no instance is returned at all) it should be destroyed no ? Reproduce code: --- Expected result: CONSTRUCT there is an error... but continue the script DESTRUCT NULL SOME WORKS Actual result: -- CONSTRUCT there is an error... but continue the script NULL SOME WORKS DESTRUCT -- Edit this bug report at http://bugs.php.net/?id=44669&edit=1
#44669 [Com]: object not immediately destructed on error
ID: 44669 Comment by: crrodriguez at suse dot de Reported By: ob dot php at daevel dot fr Status: Open Bug Type: PDO related Operating System: Debian Lenny (testing) PHP Version: 5.2.5 New Comment: This is the expected behaviuor, objects are destroyed at script shutdown. Previous Comments: [2008-04-08 08:58:57] ob dot php at daevel dot fr Description: Hello, when catching a connection error in a class extending PDO, the object is not destroyed before end of script. It's really not a big bug, but as the instance is not usable (no instance is returned at all) it should be destroyed no ? Reproduce code: --- Expected result: CONSTRUCT there is an error... but continue the script DESTRUCT NULL SOME WORKS Actual result: -- CONSTRUCT there is an error... but continue the script NULL SOME WORKS DESTRUCT -- Edit this bug report at http://bugs.php.net/?id=44669&edit=1
#43403 [Fbk->Opn]: $_SERVER['PHP_SELF'] gives incorrect value
ID: 43403 User updated by: postmaster at itsacon dot net Reported By: postmaster at itsacon dot net -Status: Feedback +Status: Open Bug Type: CGI related Operating System: Windows XP Pro 64bit PHP Version: 5.2.5 Assigned To: dmitry New Comment: Installed the snapshot, but bug still persists. One note however: Server is no longer running XP Pro 64bit. It is now running win2k again (as XP64 + PHP was too slow). Previous Comments: [2008-04-08 11:40:23] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi [2007-11-26 13:51:17] postmaster at itsacon dot net Yeah server is slow as hell. Seems to be the combination of PHP 32 bit on a 64 bit Windows, HTML files parse at normal speed. Server is Xitami 2.5c2 (32 bit) Problem looks a bit like bug 43030 (http://bugs.php.net/bug.php?id=43030), only now just the path is duplicated. That bug concerns Windows 2003, which uses roughly the same kernel as XP 64 bit, so they might be related. Hope this helps. (PS: unrelated, but are there plans to release 64 bit Windows binaries in the future?) [2007-11-26 11:46:26] [EMAIL PROTECTED] I missed the phpinfo() url. And it's slow as hell so pasting the relevant info here: Server API CGI/FastCGI Dmitry, something missed in fixing this? [2007-11-26 11:44:54] [EMAIL PROTECTED] What SAPI are you using? CGI or something else? [2007-11-26 11:19:32] postmaster at itsacon dot net Upgrading to latest CVS snapshow (5.2.6-dev) does NOT solve the problem. See scripts in bug report, path is still repeated at end of PHP_SELF value. 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/43403 -- Edit this bug report at http://bugs.php.net/?id=43403&edit=1
#44650 [Asn->Csd]: escaepshellscmd() does not check arg count
ID: 44650
Updated by: [EMAIL PROTECTED]
Reported By: wharmby at uk dot ibm dot com
-Status: Assigned
+Status: Closed
Bug Type: Scripting Engine problem
Operating System: Windows XP
PHP Version: 5.2.6RC4
Assigned To: iliaa
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2008-04-06 13:55:51] [EMAIL PROTECTED]
Will be fixed post 5.2.6
[2008-04-06 08:40:52] wharmby at uk dot ibm dot com
Description:
Calling escapeshellcmd() with more than 1 argument does not result in
expected warning msg; any spurious arguments are just ignored.
Suggest changing code to:
PHP_FUNCTION(escapeshellcmd)
{
zval **arg1;
char *cmd = NULL;
if (ZEND_NUM_ARGS()!=1 || zend_get_parameters_ex(1, &arg1) ==
FAILURE)
{
WRONG_PARAM_COUNT;
}
convert_to_string_ex(arg1);
if (Z_STRLEN_PP(arg1)) {
cmd = php_escape_shell_cmd(Z_STRVAL_PP(arg1));
RETVAL_STRING(cmd, 1);
efree(cmd);
}
}
or better still the following based on the code now in PHP 6 :
PHP_FUNCTION(escapeshellcmd)
{
char *command
int command_len;
char *cmd = NULL;
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "s", &command,
&command_len) == FAILURE) {
return;
}
if (command_len) {
cmd = php_escape_shell_cmd(command);
RETVAL_STRING(cmd, 0);
} else {
RETVAL_EMPTY_STRING();
}
}
Reproduce code:
---
Expected result:
A warning msg. With suggested fix the following output will result:
Warning: escapeshellcmd() expects exactly 1 parameter, 2 given in
<...> on line nn
NULL
Actual result:
--
Actual Output:
---
string(9) "Mr O Neil"
--
Edit this bug report at http://bugs.php.net/?id=44650&edit=1
#44671 [Opn->Bgs]: Session clears when limited conections is hit
ID: 44671 User updated by: ShmoeSOLID at gmail dot com Reported By: ShmoeSOLID at gmail dot com -Status: Open +Status: Bogus Bug Type: Session related Operating System: Server 2003 PHP Version: 5.2.5 New Comment: Sorry. I discovered this problem is elsewhere. Seems to be an issue with php file handling. Previous Comments: [2008-04-08 14:50:12] ShmoeSOLID at gmail dot com Description: Couldn't find anything on this. I don't know if this is suppose to happen or not. Session data is cleared when "Connections limited to:" is set and reached. Tested with IIS 6. -- Edit this bug report at http://bugs.php.net/?id=44671&edit=1
#16263 [Com]: session.start() create new empty session file and not resume existing session
ID: 16263 Comment by: mlavoice at netsync dot net Reported By: kur at natur dot cuni dot cz Status: No Feedback Bug Type: Session related Operating System: ANY PHP Version: 4.3.0-dev New Comment: I have this issue PHP Version 5.1.6 Previous Comments: [2008-03-07 15:41:09] josuaher at hotmail dot com I have the same problem, a new session is created everytime a page is load. I'm using PHP 5.2.5 on Apache 2.0.63 Windows XP. I just don`t know what else to try!! [2008-03-06 22:51:22] smola85 at o2 dot pl Same problem here. Debian 4.0 Apache 2.0 Handler PHP 4.3.10 It works only if I'm not using session_regenerate_id(). When I put session_regenerate_id() before $_SESSION... it doesn't work. [2008-02-20 04:22:24] snakk at inet dot co dot th My same code is work fine on following system. FreeBSD 5.4-RELEASE Apache 2.0 Handler PHP 4.3.10 [2008-02-20 04:18:32] snakk at inet dot co dot th I'm facing the same problem. Waiting for solution or suggestion, please. FreeBSD 6.0-RELEASE Apache 2.0.59 PHP 5.2.4 [2008-01-22 11:51:12] costa_brava at gmx dot net I think that part of the problem is, at least on Windows, that the session.save_path (and upload_tmp_dir) are being created within the user's 'Temp' area. (By the Windows msi installer?) But this directory is occasionally cleaned out (either manually or by system / 3rd party disk cleaners). This BTW, is the idea of a temp area, that you may delete old data without regrets. Well, since php does not re-create the sub directories structure as needed, it would be better to change these paths to a less temporary place, like "user\application data\php". Or store the files directly in the temp folder, not in subdirectories therein. 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/16263 -- Edit this bug report at http://bugs.php.net/?id=16263&edit=1
#44624 [Com]: Encoding translation does't work when posted multipart/form-data
ID: 44624
Comment by: script-kid at hotmail dot co dot jp
Reported By: sh_tanaka at mail dot goo dot ne dot jp
Status: Open
Bug Type: mbstring related
Operating System: Solaris 8
PHP Version: 5.2.5
New Comment:
Hi. I have the same problem with PHP-5.2.5 on RedHasES4.
I guess that sapi_module.input_filter in main/rfc1867.c seem to be
return 0 when post multipart/form-data. I confirmed this by putting
Debug code.
main/rfc1867.c:925
> if (sapi_module.input_filter(PARSE_POST, param, &value,
value_len, &new_val_len TSRMLS_CC)) {
> if (php_rfc1867_callback != NULL) {
> multipart_event_formdata event_formdata;
> size_t newlength = 0;
>
> event_formdata.post_bytes_processed = SG(read_post_bytes);
> event_formdata.name = param;
> event_formdata.value = &value;
> event_formdata.length = new_val_len;
> event_formdata.newlength = &newlength;
> if (php_rfc1867_callback(MULTIPART_EVENT_FORMDATA,
&event_formdata, &event_extra_data TSRMLS_CC) == FAILURE) {
> efree(param);
> efree(value);
> continue;
> }
> new_val_len = newlength;
> }
So, The follow process is not done.
main/rfc1867.c:943
>#if HAVE_MBSTRING && !defined(COMPILE_DL_MBSTRING)
> if (php_mb_encoding_translation(TSRMLS_C)) {
> php_mb_gpc_stack_variable(param, value, &val_list,
&len_list,
> &num_vars, &num_vars_max TSRMLS_CC);
> } else {
> safe_php_register_variable(param, value, new_val_len,
array_ptr, 0 TSRMLS_CC);
> }
>#else
> safe_php_register_variable(param, value, new_val_len,
array_ptr, 0 TSRMLS_CC);
>#endif
> } else if (php_rfc1867_callback != NULL) {
It seem to work properly when I tyr to change code like that.
$ diff -u main/rfc1867.c.org main/rfc1867.c
--- main/rfc1867.c.org 2007-07-18 08:46:40.0 +0900
+++ main/rfc1867.c 2008-04-08 21:55:05.0 +0900
@@ -937,33 +937,34 @@
efree(value);
continue;
}
new_val_len = newlength;
}
-#if HAVE_MBSTRING && !defined(COMPILE_DL_MBSTRING)
- if (php_mb_encoding_translation(TSRMLS_C)) {
-php_mb_gpc_stack_variable(param, value, &val_list,
&len_list,
- &num_vars, &num_vars_max TSRMLS_CC);
- } else {
-safe_php_register_variable(param, value, new_val_len,
array_ptr, 0 TSRMLS_CC);
- }
-#else
- safe_php_register_variable(param, value, new_val_len,
array_ptr, 0 TSRMLS_CC);
-#endif
} else if (php_rfc1867_callback != NULL) {
multipart_event_formdata event_formdata;
event_formdata.post_bytes_processed = SG(read_post_bytes);
event_formdata.name = param;
event_formdata.value = &value;
event_formdata.length = value_len;
event_formdata.newlength = NULL;
php_rfc1867_callback(MULTIPART_EVENT_FORMDATA,
&event_formdata, &event_extra_data TSRMLS_CC);
}
+#if HAVE_MBSTRING && !defined(COMPILE_DL_MBSTRING)
+ if (php_mb_encoding_translation(TSRMLS_C)) {
+php_mb_gpc_stack_variable(param, value, &val_list,
&len_list,
+ &num_vars, &num_vars_max TSRMLS_CC);
+ } else {
+safe_php_register_variable(param, value, new_val_len,
array_ptr, 0 TSRMLS_CC);
+ }
+#else
+ safe_php_register_variable(param, value, new_val_len,
array_ptr, 0 TSRMLS_CC);
+#endif
+
if (!strcasecmp(param, "MAX_FILE_SIZE")) {
max_file_size = atol(value);
}
Previous Comments:
[2008-04-03 05:38:45] sh_tanaka at mail dot goo dot ne dot jp
Description:
Encoding translation of incomming posted data does't work when enctype
attribute in from element is set to multipart/form-data.
We are plannning to upgrade PHP4.3.11 to 5.2.5 and now we are testing
all applications.
Translation of PHP4.3.11 is OK, but NO translation occurrs on
PHP5.2.5.
Online manual( http://www.php.net/manual/en/ref.mbstring.php ) says,
> Note: In PHP 4.3.2 or earlier versions, there was a limitation in
> this functionality that mbstring does not perform character
> encoding conversion in POST data if the enctype attribute in the
> form element is set to multipart/form-data.
If conversion in PHP 5.2.5 is as same as PHP4.3.2 or earlier versions,
online manual should be corrected.
--
Edit this bug report at http://bugs.php.net/?id=44624&edit=1
#44671 [NEW]: Session clears when limited conections is hit
From: ShmoeSOLID at gmail dot com Operating system: Server 2003 PHP version: 5.2.5 PHP Bug Type: Session related Bug description: Session clears when limited conections is hit Description: Couldn't find anything on this. I don't know if this is suppose to happen or not. Session data is cleared when "Connections limited to:" is set and reached. Tested with IIS 6. -- Edit bug report at http://bugs.php.net/?id=44671&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44671&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44671&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44671&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44671&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44671&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44671&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44671&r=needscript Try newer version:http://bugs.php.net/fix.php?id=44671&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44671&r=support Expected behavior:http://bugs.php.net/fix.php?id=44671&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44671&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44671&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44671&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44671&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44671&r=dst IIS Stability:http://bugs.php.net/fix.php?id=44671&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44671&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44671&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44671&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44671&r=mysqlcfg
#44670 [NEW]: sed not found
From: mark at detrick dot com Operating system: Solaris 10 PHP version: 5.2.5 PHP Bug Type: *Directory/Filesystem functions Bug description: sed not found Description: Configure does not find sed for use during installation. Defaults to looking in /usr/local/bin/sed. Expected result: No errors during installation. Actual result: -- cesium-bash /appl/php/php-5.2.5 # make install Installing PHP SAPI module: apache2handler /usr/local/apache2/build/instdso.sh SH_LIBTOOL='/usr/local/apache2/build/libtool' libphp5.la /usr/local/apache2/modules /usr/local/apache2/build/libtool --mode=install cp libphp5.la /usr/local/apache2/modules/ /usr/local/apache2/build/libtool: line 387: /usr/local/bin/sed: No such file or directory /usr/local/apache2/build/libtool: line 752: /usr/local/bin/sed: No such file or directory *** Warning: inferring the mode of operation is deprecated. *** Future versions of Libtool will require --mode=MODE be specified. /usr/local/apache2/build/libtool: line 6091: /usr/local/bin/sed: No such file or directory /usr/local/apache2/build/libtool: line 6174: /usr/local/bin/sed: No such file or directory /usr/local/apache2/build/libtool: line 6182: /usr/local/bin/sed: No such file or directory /usr/local/apache2/build/libtool: line 6184: /usr/local/bin/sed: No such file or directory : install: `.' must be an absolute directory name Try ` --help --mode=install' for more information. apxs:Error: Command failed with rc=65536 . make: *** [install-sapi] Error 1 -- Edit bug report at http://bugs.php.net/?id=44670&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44670&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44670&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44670&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44670&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44670&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44670&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44670&r=needscript Try newer version:http://bugs.php.net/fix.php?id=44670&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44670&r=support Expected behavior:http://bugs.php.net/fix.php?id=44670&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44670&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44670&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44670&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44670&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44670&r=dst IIS Stability:http://bugs.php.net/fix.php?id=44670&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44670&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44670&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44670&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44670&r=mysqlcfg
#44574 [Asn]: parse_ini_file eof problem
ID: 44574 Updated by: [EMAIL PROTECTED] Reported By: letssurf at gmail dot com Status: Assigned Bug Type: Filesystem function related Operating System: Linux 2.6.9-34 PHP Version: 5.3CVS-2008-03-31 (snap) Assigned To: helly New Comment: Added this missing case to ext/standard/tests/general_funcs/parse_ini_file.phpt. Previous Comments: [2008-04-02 10:25:05] [EMAIL PROTECTED] Apparently the transition from flex -> re2c caused this since I can't reproduce this with php build made prior that. Marcus..? [2008-04-02 10:21:48] letssurf at gmail dot com Retested with builds Win32 build Apr 2 2008 04:17:01, same problem Linux built php5.3-200804020830, same problem -- file: test1.php -- Array ( [name] => value ) ) Actual result: -- Warning: syntax error, unexpected $end in eof.ini on line 2 in test.php on line 2 Array ( [section1] => Array ( ) ) -- Edit this bug report at http://bugs.php.net/?id=44574&edit=1
#43403 [Asn->Fbk]: $_SERVER['PHP_SELF'] gives incorrect value
ID: 43403 Updated by: [EMAIL PROTECTED] Reported By: postmaster at itsacon dot net -Status: Assigned +Status: Feedback Bug Type: CGI related Operating System: Windows XP Pro 64bit PHP Version: 5.2.5 Assigned To: dmitry New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi Previous Comments: [2007-11-26 13:51:17] postmaster at itsacon dot net Yeah server is slow as hell. Seems to be the combination of PHP 32 bit on a 64 bit Windows, HTML files parse at normal speed. Server is Xitami 2.5c2 (32 bit) Problem looks a bit like bug 43030 (http://bugs.php.net/bug.php?id=43030), only now just the path is duplicated. That bug concerns Windows 2003, which uses roughly the same kernel as XP 64 bit, so they might be related. Hope this helps. (PS: unrelated, but are there plans to release 64 bit Windows binaries in the future?) [2007-11-26 11:46:26] [EMAIL PROTECTED] I missed the phpinfo() url. And it's slow as hell so pasting the relevant info here: Server API CGI/FastCGI Dmitry, something missed in fixing this? [2007-11-26 11:44:54] [EMAIL PROTECTED] What SAPI are you using? CGI or something else? [2007-11-26 11:19:32] postmaster at itsacon dot net Upgrading to latest CVS snapshow (5.2.6-dev) does NOT solve the problem. See scripts in bug report, path is still repeated at end of PHP_SELF value. [2007-11-25 22:28:29] postmaster at itsacon dot net Description: In directories below document root, PHP_SELF returns an incorrect value (path repeated at end of string) Reproduce code: --- /* Place this code in a SUBDIRECTORY (such as localhost/testdir/test.php */ /* or see http://www2.bijscharp.nl/bugdemo/winxp64_php_self.php (script contains code above) For info on server, see http://www2.bijscharp.nl/bugdemo/phpinfo.php */ Expected result: The result should be: /bugdemo/winxp64_php_self.php Actual result: -- The result is: bugdemo/winxp64_php_self.php/bugdemo -- Edit this bug report at http://bugs.php.net/?id=43403&edit=1
#43309 [Opn->Fbk]: PHP needs list folder access of all directories leading up to the script dir
ID: 43309 Updated by: [EMAIL PROTECTED] Reported By: don dot lebert at gmail dot com -Status: Open +Status: Feedback Bug Type: Filesystem function related Operating System: Windows 2003 SP2 PHP Version: 5.2CVS-2007-11-15 New Comment: 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. Previous Comments: [2008-01-23 22:04:55] don dot lebert at gmail dot com Just sort of a follow up: PHP 5.2.5 still acts this way, as does the latest php6. [2007-11-15 23:07:26] don dot lebert at gmail dot com Thank you for your timely reply; unfortunately, the problem persists after making use of the CVS. [2007-11-15 22:35:28] don dot lebert at gmail dot com Description: As of php 5.2.4 the language suddenly wants full pathing rights to where ever the .php file is run. The best way to see this problem is to use as simple script, no point in getting all complicated. What I have setup is a D:\inetpub folder which only has administrator and system rights. Within there I have the websites, so lets say wwwroot. This site has rights for Administrator, System, and the Internet Guest Account. Within this wwwroot I have a test.php, which contents are: Typically(Pre php 5.2.4) this would return D:\inetpub\wwwroot(The directory from which the script was run via IIS, and the way I imagine it should work) As of PHP 5.2.4 and above, this now returns C:\windows\system32\inetsrv The reason? PHP now wants to have 'List Folder Contents' Access to D:\Inetpub for users. -- Edit this bug report at http://bugs.php.net/?id=43309&edit=1
#44666 [Bgs]: apache2 module seems to ignore --with-tidy compilation option
ID: 44666 User updated by: geoffrey dot hughes at otago dot ac dot nz Reported By: geoffrey dot hughes at otago dot ac dot nz Status: Bogus Bug Type: Apache2 related Operating System: Mac OS X 10.5.2 PHP Version: 5.2.5 New Comment: phpcli returns a loaded libtidy at /opt/local/lib whereas libphp5.so returns a libtidy loaded from /usr/lib It seems you are correct but my next question is why is libphp5.so linked against that one when I've specified a path to tidy in the configure statement. Previous Comments: [2008-04-08 10:57:06] [EMAIL PROTECTED] And that's supposed to be *nix? pff.. Well, if you had bothered to use google you would have found that the equivalent for ldd is: otool -L Anyway, as I'm sure this is just a misconfigured system and not a PHP bug -> bogus. [2008-04-08 10:42:25] geoffrey dot hughes at otago dot ac dot nz No ldd in OS X 10.5 [2008-04-08 08:06:02] [EMAIL PROTECTED] I would guess /opt/local/lib is not in your LD_LIBRARY_PATH, hence the shared apache2 module uses whatever it finds in the path. And CLI is propably linked as static..? Try this: # ldd /path/to/cli/binary and # ldd /path/to/libphp5.so [2008-04-08 02:48:15] geoffrey dot hughes at otago dot ac dot nz Description: PHPCLI uses the correct libtidy version when compiled with --with- tidy=/opt/local but the apache2 module uses the leopard default libtidy whether you use --with-tidy=/opt/local or not. PHPCLI Info: libTidy Release => 22 March 2008 Apache2 phpinfo.php: libTidy Release31 October 2006 - Apple Inc. build 13 -- Edit this bug report at http://bugs.php.net/?id=44666&edit=1
#44047 [Opn->Bgs]: IIS Worker Process stopped working
ID: 44047 Updated by: [EMAIL PROTECTED] Reported By: matthew dot horner at redprairie dot com -Status: Open +Status: Bogus Bug Type: Reproducible crash Operating System: Windows Vista PHP Version: 5.2.5 New Comment: We are aware of PHP's problems with stability under IIS and are working to rectify the problem. Unfortunatly your bug report does not contain any extra useful information and we already have enough bug reports open about this issue. If you can provide more detailed information such as a reproducable crash or a backtrace please do so and reopen this bug. Otherwise please keep trying new releases as we are working to resolve the problems on this platform Thanks for your interest in PHP. It's safest to use FastCGI. Even IIS supports it nowadays.. Previous Comments: [2008-04-07 18:21:51] matthew dot horner at redprairie dot com Thank you for your observation. I am not sure if I had originally set it this way or not, but I have changed the category to hopefully represent the issue better. Maybe this will get noticed by someone who will engage the issue and provide a fix. [2008-04-03 20:20:58] nonya at spam dot this I see this topic has been labeled an IIS issue and there was no response from PHP staff. If it is a IIS7 issue, why was it not occurring in PHP4? [2008-03-19 04:22:41] jaedsm at hotmail dot com Having the same issue here too. Installed IIS7 and PHP 5.2.5 the other day on my home system running Vista Home Premium. Didn't consider it would have been caused by some timeout but after reading here that makes sense. No crash message has appeared while I've been working for hours on end, once I stop though it appears a little while later and doesn't appear again unless I load another php page. [2008-03-06 14:00:56] matthew dot horner at redprairie dot com I would still consider this a workaround, as this is not standard procedure for installing ISAPI modules in IIS7. Furthermore, this issue is not an issue with PHP 4. Which to me, would indicate there is something coded differently with PHP 5 to cause the crash when recycling the process. Also, reconfiguring the Application Pool, affects more than just your pool hosting PHP driven applications. What side effects there are, is unclear to me, but certainly not something I would like to find out about once a site is in production. I posted this bug because I would like to have the PHP developers debug this issue and determine if there is indeed a code problem or a problem with IIS7. Not to have a workaround to avoid crashes on IIS7. I am not disputing the fact that your solution works. However, this appears to be an issue and should be addressed at the PHP level first. Thank you for your suggestions. [2008-03-06 10:36:54] satan at dclxvi dot nl to be clear, these are my settings: Recycle time is set to the default every 1740 minutes. Idle timeout is set to '0' Disable Overlapped Recycle is set to 'True' never had the error again... no horrible workarround whatsoever.. it's just that IIS7 is defaultly configured to run MS stuff like ASP.NET etc.. 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/44047 -- Edit this bug report at http://bugs.php.net/?id=44047&edit=1
#44645 [Opn->Fbk]: php5ts.dll Crash (x86_64 base machines)
ID: 44645 Updated by: [EMAIL PROTECTED] Reported By: gary dot wilson at coull dot biz -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: Windows Server 2003 PHP Version: 5.2.5 New Comment: Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. Previous Comments: [2008-04-05 09:11:03] gary dot wilson at coull dot biz Description: Failure case: Making 8 (or more) concurrent requests to Apache/php requesting XML causes php5ts.dll to throw an application error. Event Type: Information Event Source: Application Error Event Category: (100) Event ID: 1004 Date: 02/04/2008 Time: 17:47:03 User: N/A Computer: COULL-WEB01 Description: Reporting queued error: faulting application Apache.exe, version 2.0.55.0, faulting module php5ts.dll, version 5.1.6.6, fault address 0x926a. For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp. Data: : 41 70 70 6c 69 63 61 74 Applicat 0008: 69 6f 6e 20 46 61 69 6c ion Fail 0010: 75 72 65 20 20 41 70 61 ure Apa 0018: 63 68 65 2e 65 78 65 20 che.exe 0020: 32 2e 30 2e 35 35 2e 30 2.0.55.0 0028: 20 69 6e 20 70 68 70 35in php5 0030: 74 73 2e 64 6c 6c 20 35 ts.dll 5 0038: 2e 31 2e 36 2e 36 20 61 .1.6.6 a 0040: 74 20 6f 66 66 73 65 74 t offset 0048: 20 30 30 30 30 39 32 36926 0050: 61a # Event Type: Information Event Source: Application Error Event Category: (100) Event ID: 1004 Date: 05/04/2008 Time: 09:21:48 User: N/A Computer: MEDIAPROC02 Description: Reporting queued error: faulting application httpd.exe, version 2.2.8.0, faulting module php5ts.dll, version 5.2.5.5, fault address 0xacb9. For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp. Data: : 41 70 70 6c 69 63 61 74 Applicat 0008: 69 6f 6e 20 46 61 69 6c ion Fail 0010: 75 72 65 20 20 68 74 74 ure htt 0018: 70 64 2e 65 78 65 20 32 pd.exe 2 0020: 2e 32 2e 38 2e 30 20 69 .2.8.0 i 0028: 6e 20 70 68 70 35 74 73 n php5ts 0030: 2e 64 6c 6c 20 35 2e 32 .dll 5.2 0038: 2e 35 2e 35 20 61 74 20 .5.5 at 0040: 6f 66 66 73 65 74 20 30 offset 0 0048: 30 30 30 61 63 62 39 000acb9 Hardware Manufacture: Dell, HP Machine base: 64 bit Operating System: Windows Server 2003 SP2 (32 bit) Apache versions: 2.0.55, 2.0.59, 2.2.4, 2.2.8 php Versions: 5.1.6, 5.2.5, 5.3.dev Description: This problem was reproducible every time with a combination all the above components. This was reproduced on 3 separate servers, 2 Dell and 1 HP. The failure case CANNOT be reproduced on a machine with the same OS, Apache/php versions/config and code base that is running on a 32 bit base machine this was verified on 5 servers. In our failure case we are generating XML output on every request. It would seem like this is a issue when running 32 bit Win OS on 64 bit base machine. Unfortunately, I am unable to test this on 64 bit Windows 2003, however, I did retrograde a 64 bit OS a few months ago due to a very similar problem (not certain if it was exactly the same). Reproduce code: --- Not a developer. I will try and get our development team to create some code to reproduce, but they are very busy, so it may take some time. -- Edit this bug report at http://bugs.php.net/?id=44645&edit=1
#44648 [Opn->Asn]: All-or-nothing for production checks in DOM interface
ID: 44648
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Assigned
Bug Type: DOM XML related
Operating System: Windows Vista
PHP Version: 5.2.5
Assigned To: rrichards
Previous Comments:
[2008-04-06 14:06:09] geoffers+phpbugs at gmail dot com
While we should be throwing exceptions when strictErrorChecking is
true,
behaviour when it is false is undefined. I would suggest in that case
to
keep allowing everything.
[2008-04-06 04:15:54] [EMAIL PROTECTED]
You're right, that was my mistake.
I suppose that any of the places where the DOM specification could
raise an exception would be the places where there needs to be
error-checking.
Ought of curiosity, how come we don't use gdome2?
[2008-04-05 23:22:24] [EMAIL PROTECTED]
You should read the specs more closely. Names are most certainly
checked
and a DOMException with an INVALID_CHARACTER_ERROR error is thrown.
Some of the others I need to look at because it is perfectly fine to
create non well formed XML using DOM though it should error during
serialization, so for those the bug would onl be in the saveXML
routine.
Other extensions it is not a bug because non-well formed XML support is
required because the output when used in a larger context is well
formed
[2008-04-05 23:02:49] [EMAIL PROTECTED]
One more: ]]> is not allowed in CDATA blocks.
I also suspect that the other XML extensions have bugs here.
[2008-04-05 23:02:02] [EMAIL PROTECTED]
IIRC, DOM does not make any demands on names or things like that.
libxml2, which is known for its strictness, doesn't either. So, I'm
still hoping that you'll let the checks be turned off. :-)
Some things from my investigation:
- Double hyphens (--) are not allowed in comments
- Most of the text inputs don't check for UTF-8 well-formedness.
Haven't tested numeric character entities either, but those are
suspicious
- Fake namespace declarations in attributes
($d->appendChild($d->createElement('foo:bar')); results in invalid XML,
as foo namespace was never defined)
All these result in a $d->saveXML(); that is invalid XML, and probably
some more.
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/44648
--
Edit this bug report at http://bugs.php.net/?id=44648&edit=1
#44665 [Opn->Bgs]: Memory leak in array_push operation
ID: 44665
Updated by: [EMAIL PROTECTED]
Reported By: sasha at integrate dot ru
-Status: Open
+Status: Bogus
Bug Type: Arrays related
Operating System: Linux
PHP Version: 5.2.5
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Previous Comments:
[2008-04-08 00:13:53] sasha at integrate dot ru
sorry - wrong second link
the right link is
http://ver.web.integrate.ru/test2.php
[2008-04-07 22:35:43] sasha at integrate dot ru
Description:
Sorry for my english
php with curl, dbase, dom, gd2, mbstring,pgsql, simplexml,soap,sockets
It running under eAccelerator, but when I turn it off, the result is
just the same.
actually we use only pgsql. we get request (rather big - more than 3000
rows in result) making array of objects and then trying to convert each
object into html string. converted string (each about 2 Kb length) have
been pushed into array
very soon memory usage growing to 64 Mb and script is crushed
This problem is solved by method refact
protected function _refact($arr)
{
$myarr=array();
while(!empty($arr)) $myarr[]=array_shift($arr);
return ($myarr);
}
I call this function after 75, 150, 300 etc iterations, but calling
this function reduce performance. Is that behaviour (I mean memory usage
growing) normal?
Reproduce code:
---
Normal script (crushed)
http://ver.web.integrate.ru/test1.php
Cheated script (with refact method)
http://ver.web.integrate.ru/test1.php
Each script reports tht Init memory (Memory at the begin), how much
objects it proceeds (Now showing), iteration counter (Cicling
iteration), current memry usage (current memory usage) and length of
string we pushed into array (string_length).
Cheated script (in red hrs) show also the length of array we throw to
refact method
Expected result:
I guess that the memory usage won't grow while running this script
because the array of objects poped every turn, and the volume of each
element of this array more than the volume of elements of the result
array
Actual result:
--
U can see it on url I submit
--
Edit this bug report at http://bugs.php.net/?id=44665&edit=1
#44666 [Opn->Bgs]: apache2 module seems to ignore --with-tidy compilation option
ID: 44666 Updated by: [EMAIL PROTECTED] Reported By: geoffrey dot hughes at otago dot ac dot nz -Status: Open +Status: Bogus Bug Type: Apache2 related Operating System: Mac OS X 10.5.2 PHP Version: 5.2.5 Assigned To: fb-req-jani New Comment: And that's supposed to be *nix? pff.. Well, if you had bothered to use google you would have found that the equivalent for ldd is: otool -L Anyway, as I'm sure this is just a misconfigured system and not a PHP bug -> bogus. Previous Comments: [2008-04-08 10:42:25] geoffrey dot hughes at otago dot ac dot nz No ldd in OS X 10.5 [2008-04-08 08:06:02] [EMAIL PROTECTED] I would guess /opt/local/lib is not in your LD_LIBRARY_PATH, hence the shared apache2 module uses whatever it finds in the path. And CLI is propably linked as static..? Try this: # ldd /path/to/cli/binary and # ldd /path/to/libphp5.so [2008-04-08 02:48:15] geoffrey dot hughes at otago dot ac dot nz Description: PHPCLI uses the correct libtidy version when compiled with --with- tidy=/opt/local but the apache2 module uses the leopard default libtidy whether you use --with-tidy=/opt/local or not. PHPCLI Info: libTidy Release => 22 March 2008 Apache2 phpinfo.php: libTidy Release31 October 2006 - Apple Inc. build 13 -- Edit this bug report at http://bugs.php.net/?id=44666&edit=1
#44666 [Fbk->Opn]: apache2 module seems to ignore --with-tidy compilation option
ID: 44666 User updated by: geoffrey dot hughes at otago dot ac dot nz Reported By: geoffrey dot hughes at otago dot ac dot nz -Status: Feedback +Status: Open Bug Type: Apache2 related Operating System: Mac OS X 10.5.2 PHP Version: 5.2.5 Assigned To: fb-req-jani New Comment: No ldd in OS X 10.5 Previous Comments: [2008-04-08 08:06:02] [EMAIL PROTECTED] I would guess /opt/local/lib is not in your LD_LIBRARY_PATH, hence the shared apache2 module uses whatever it finds in the path. And CLI is propably linked as static..? Try this: # ldd /path/to/cli/binary and # ldd /path/to/libphp5.so [2008-04-08 02:48:15] geoffrey dot hughes at otago dot ac dot nz Description: PHPCLI uses the correct libtidy version when compiled with --with- tidy=/opt/local but the apache2 module uses the leopard default libtidy whether you use --with-tidy=/opt/local or not. PHPCLI Info: libTidy Release => 22 March 2008 Apache2 phpinfo.php: libTidy Release31 October 2006 - Apple Inc. build 13 -- Edit this bug report at http://bugs.php.net/?id=44666&edit=1
#44667 [Asn->Csd]: proc_open does not handle pipes with the mode 'wb' correctly
ID: 44667
Updated by: [EMAIL PROTECTED]
Reported By: mike at silverorange dot com
-Status: Assigned
+Status: Closed
Bug Type: Program Execution
Operating System: *
PHP Version: 5.2CVS-2008-04-08 (CVS)
Assigned To: jani
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2008-04-08 08:22:47] [EMAIL PROTECTED]
Fixed, need to merge around.
[2008-04-08 03:21:59] mike at silverorange dot com
Description:
proc_open.c checks if the mode parameter != "w" instead of checking the
first character of the mode parameter. This prevents the mode 'wb' from
working properly.
Reproduce code:
---
array('pipe', 'rb'),
1 => array('pipe', 'wb'),
);
$proc = proc_open('cat', $descriptor_spec, $pipes);
fwrite($pipes[0], 'Hello', 5);
fflush($pipes[0]);
fclose($pipes[0]);
$result = fread($pipes[1], 5);
fclose($pipes[1]);
proc_close($proc);
echo "Result is: ", $result, "\n";
?>
Expected result:
Result is: Hello
Actual result:
--
on stderr:
cat: write error: Bad file descriptor
on stdout:
Result is:
--
Edit this bug report at http://bugs.php.net/?id=44667&edit=1
#44669 [NEW]: object not immediately destructed on error
From: ob dot php at daevel dot fr Operating system: Debian Lenny (testing) PHP version: 5.2.5 PHP Bug Type: PDO related Bug description: object not immediately destructed on error Description: Hello, when catching a connection error in a class extending PDO, the object is not destroyed before end of script. It's really not a big bug, but as the instance is not usable (no instance is returned at all) it should be destroyed no ? Reproduce code: --- Expected result: CONSTRUCT there is an error... but continue the script DESTRUCT NULL SOME WORKS Actual result: -- CONSTRUCT there is an error... but continue the script NULL SOME WORKS DESTRUCT -- Edit bug report at http://bugs.php.net/?id=44669&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44669&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44669&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44669&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44669&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44669&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44669&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44669&r=needscript Try newer version:http://bugs.php.net/fix.php?id=44669&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44669&r=support Expected behavior:http://bugs.php.net/fix.php?id=44669&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44669&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44669&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44669&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44669&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44669&r=dst IIS Stability:http://bugs.php.net/fix.php?id=44669&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44669&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44669&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44669&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44669&r=mysqlcfg
#44667 [Opn->Asn]: proc_open does not handle pipes with the mode 'wb' correctly
ID: 44667
Updated by: [EMAIL PROTECTED]
Reported By: mike at silverorange dot com
-Status: Open
+Status: Assigned
Bug Type: Program Execution
Operating System: Irrelevant
PHP Version: 5.2CVS-2008-04-08 (CVS)
-Assigned To:
+Assigned To: jani
New Comment:
Fixed, need to merge around.
Previous Comments:
[2008-04-08 03:21:59] mike at silverorange dot com
Description:
proc_open.c checks if the mode parameter != "w" instead of checking the
first character of the mode parameter. This prevents the mode 'wb' from
working properly.
Reproduce code:
---
array('pipe', 'rb'),
1 => array('pipe', 'wb'),
);
$proc = proc_open('cat', $descriptor_spec, $pipes);
fwrite($pipes[0], 'Hello', 5);
fflush($pipes[0]);
fclose($pipes[0]);
$result = fread($pipes[1], 5);
fclose($pipes[1]);
proc_close($proc);
echo "Result is: ", $result, "\n";
?>
Expected result:
Result is: Hello
Actual result:
--
on stderr:
cat: write error: Bad file descriptor
on stdout:
Result is:
--
Edit this bug report at http://bugs.php.net/?id=44667&edit=1
#44666 [Opn->Fbk]: apache2 module seems to ignore --with-tidy compilation option
ID: 44666 Updated by: [EMAIL PROTECTED] Reported By: geoffrey dot hughes at otago dot ac dot nz -Status: Open +Status: Feedback Bug Type: Apache2 related Operating System: Mac OS X 10.5.2 PHP Version: 5.2.5 New Comment: I would guess /opt/local/lib is not in your LD_LIBRARY_PATH, hence the shared apache2 module uses whatever it finds in the path. And CLI is propably linked as static..? Try this: # ldd /path/to/cli/binary and # ldd /path/to/libphp5.so Previous Comments: [2008-04-08 02:48:15] geoffrey dot hughes at otago dot ac dot nz Description: PHPCLI uses the correct libtidy version when compiled with --with- tidy=/opt/local but the apache2 module uses the leopard default libtidy whether you use --with-tidy=/opt/local or not. PHPCLI Info: libTidy Release => 22 March 2008 Apache2 phpinfo.php: libTidy Release31 October 2006 - Apple Inc. build 13 -- Edit this bug report at http://bugs.php.net/?id=44666&edit=1
