#44352 [Opn]: mysqli_connect_error() false negative for host errors
ID: 44352
User updated by: stein at visibone dot com
Reported By: stein at visibone dot com
Status: Open
Bug Type: MySQLi related
Operating System: Windows 2000
PHP Version: 5.2.5
Assigned To: andrey
New Comment:
...and with warnings (no @ sign) I get:
string(46) mysqlnd 5.0.1-beta - 070402 - $Revision: 321 $
PHP Warning: mysqli::mysqli(): php_network_getaddresses: getaddrinfo
failed: No such host is known. in Command line code on line 1
Warning: mysqli::mysqli(): php_network_getaddresses: getaddrinfo
failed: No such host is known. in Command line code on line 1
PHP Warning: mysqli::mysqli(): (0/0): in Command line code on
line 1
Warning: mysqli::mysqli(): (0/0): in Command line code on line 1
string(0)
Previous Comments:
[2008-03-11 09:40:33] stein at visibone dot com
Good test case. For windows command line I swapped the quote marks.
With warnings suppressed I get:
C:\php -r var_dump(mysqli_get_client_info());[EMAIL PROTECTED]
mysqli('bogushost.com');var_dump(mysqli_connect_error());
string(46) mysqlnd 5.0.1-beta - 070402 - $Revision: 321 $
string(0)
[2008-03-10 19:15:14] [EMAIL PROTECTED]
I can't reproduce the problem with mysqli/libmysql - neither 5.2 nor
5.3-dev. However, I saw it with mysqli/mysqlnd, which is due to a bug in
PHP's streams. I will fix the bug. Can you give more information?
I am using mysql 5.1.24-rc server and client library (+headers).
Libmysql reports a problem in the resolution of `bogushost.com`
I haven't still checked the problem with isset($mysqli-error)
[EMAIL PROTECTED]:~/dev/php5_3 ./php -r
'var_dump(mysqli_get_client_info());$c=new
mysqli(bogushost.com);var_dump(mysqli_connect_error());'
string(9) 5.1.24-rc
Warning: mysqli::mysqli(): (HY000/2005): Unknown MySQL server host
'bogushost.com' (1) in Command line code on line 1
string(45) Unknown MySQL server host 'bogushost.com' (1)
--
[EMAIL PROTECTED]:~/dev/vanilla/php5_2 ./php -r
'var_dump(mysqli_get_client_info());$c=new
mysqli(bogushost.com);var_dump(mysqli_connect_error());'
string(9) 5.1.24-rc
Warning: mysqli::mysqli(): (HY000/2005): Unknown MySQL server host
'bogushost.com' (1) in Command line code on line 1
string(45) Unknown MySQL server host 'bogushost.com' (1)
--
[2008-03-08 22:26:54] [EMAIL PROTECTED]
Assigned to primary maintainer
[2008-03-06 17:35:48] stein at visibone dot com
Description:
If you don't like this cramming of 4 bugs in 1, please consider this
solely a report of bug #1 which is the most serious. Fix the first two
assert()'s in the reproduce code and call it a solved.
I think the mysqli connect-time error handling has a lot of bugs. I
hope you'll bear with this report of 4 separate bugs. They all
contribute to a very difficult time for PHP code to detect connection
failure (as opposed humans detecting it from warning messages in the
output). I hope someone will find this a useful analysis of what goes
wrong when connections go wrong.
Bug #1: a bad host (misspelled domain, server down) can't be detected
by mysqli_connect_error() or mysqli_connect_errno() -- they return empty
string and zero. I have a hunch that in bug #30051 he actually detected
this problem at first, but then he brought up his server on localhost
and it went away so he closed his submission. I think bug #31163
reported this problem and then died of neglect. Bug #31745 may have
suffered from it, but it seems to be more about exceptions versus error
messages.
Again, bug 1 is the most serious. It breaks Example#1 on
http://www.php.net/manual/en/function.mysqli-connect.php when there's no
MySQL server running on localhost. Bugs 2,3,4 make workarounds hard.
Bug #2: the object oriented constructor new mysqli never returns
FALSE. This was reported in bug #32818 but waived off as a non-bug
without explanation. The documentation for this constructor is smooshed
in with that of mysqli_connect(), where it states Returns ... FALSE if
the connection failed. So I believe bug #32818 was not bogus, or the
documentation is.
Bug #3 $mysqli-error member never passes the isset() nor
property_exists() tests. Not when the connection fails, nor when it
works, nor after a good query, nor a bad. Maybe all mysqli properties
suffer from this. The reproduce code demonstrates the same lapse for
mysqli::error, mysqli::errno, and mysqli_result::num_rows. So this may
be a defect of mysqli or some faux pas of the PHP5 object model itself.
I could find no existing bug that described it.
Bug #4 mysqli object limbo. Connection
#44352 [Fbk-Opn]: mysqli_connect_error() false negative for host errors
ID: 44352
User updated by: stein at visibone dot com
Reported By: stein at visibone dot com
-Status: Feedback
+Status: Open
Bug Type: MySQLi related
Operating System: Windows 2000
PHP Version: 5.2.5
Assigned To: andrey
New Comment:
Good test case. For windows command line I swapped the quote marks.
With warnings suppressed I get:
C:\php -r var_dump(mysqli_get_client_info());[EMAIL PROTECTED]
mysqli('bogushost.com');var_dump(mysqli_connect_error());
string(46) mysqlnd 5.0.1-beta - 070402 - $Revision: 321 $
string(0)
Previous Comments:
[2008-03-10 19:15:14] [EMAIL PROTECTED]
I can't reproduce the problem with mysqli/libmysql - neither 5.2 nor
5.3-dev. However, I saw it with mysqli/mysqlnd, which is due to a bug in
PHP's streams. I will fix the bug. Can you give more information?
I am using mysql 5.1.24-rc server and client library (+headers).
Libmysql reports a problem in the resolution of `bogushost.com`
I haven't still checked the problem with isset($mysqli-error)
[EMAIL PROTECTED]:~/dev/php5_3 ./php -r
'var_dump(mysqli_get_client_info());$c=new
mysqli(bogushost.com);var_dump(mysqli_connect_error());'
string(9) 5.1.24-rc
Warning: mysqli::mysqli(): (HY000/2005): Unknown MySQL server host
'bogushost.com' (1) in Command line code on line 1
string(45) Unknown MySQL server host 'bogushost.com' (1)
--
[EMAIL PROTECTED]:~/dev/vanilla/php5_2 ./php -r
'var_dump(mysqli_get_client_info());$c=new
mysqli(bogushost.com);var_dump(mysqli_connect_error());'
string(9) 5.1.24-rc
Warning: mysqli::mysqli(): (HY000/2005): Unknown MySQL server host
'bogushost.com' (1) in Command line code on line 1
string(45) Unknown MySQL server host 'bogushost.com' (1)
--
[2008-03-08 22:26:54] [EMAIL PROTECTED]
Assigned to primary maintainer
[2008-03-06 17:35:48] stein at visibone dot com
Description:
If you don't like this cramming of 4 bugs in 1, please consider this
solely a report of bug #1 which is the most serious. Fix the first two
assert()'s in the reproduce code and call it a solved.
I think the mysqli connect-time error handling has a lot of bugs. I
hope you'll bear with this report of 4 separate bugs. They all
contribute to a very difficult time for PHP code to detect connection
failure (as opposed humans detecting it from warning messages in the
output). I hope someone will find this a useful analysis of what goes
wrong when connections go wrong.
Bug #1: a bad host (misspelled domain, server down) can't be detected
by mysqli_connect_error() or mysqli_connect_errno() -- they return empty
string and zero. I have a hunch that in bug #30051 he actually detected
this problem at first, but then he brought up his server on localhost
and it went away so he closed his submission. I think bug #31163
reported this problem and then died of neglect. Bug #31745 may have
suffered from it, but it seems to be more about exceptions versus error
messages.
Again, bug 1 is the most serious. It breaks Example#1 on
http://www.php.net/manual/en/function.mysqli-connect.php when there's no
MySQL server running on localhost. Bugs 2,3,4 make workarounds hard.
Bug #2: the object oriented constructor new mysqli never returns
FALSE. This was reported in bug #32818 but waived off as a non-bug
without explanation. The documentation for this constructor is smooshed
in with that of mysqli_connect(), where it states Returns ... FALSE if
the connection failed. So I believe bug #32818 was not bogus, or the
documentation is.
Bug #3 $mysqli-error member never passes the isset() nor
property_exists() tests. Not when the connection fails, nor when it
works, nor after a good query, nor a bad. Maybe all mysqli properties
suffer from this. The reproduce code demonstrates the same lapse for
mysqli::error, mysqli::errno, and mysqli_result::num_rows. So this may
be a defect of mysqli or some faux pas of the PHP5 object model itself.
I could find no existing bug that described it.
Bug #4 mysqli object limbo. Connection failure is undetectable without
generating a warning. new mysql returns what is by every diagnostic a
mysqli object. (get_class(), instanceof, and is_a() all say it is.) But
if the connection failed, doing anything with the instance will give you
the ubiquitous and inscrutible Couldn't fetch mysqli warning.
Drastic workaround for object oriented (works around all four bugs):
$mysqli = @new mysqli(...);
if (NULL === @$mysqli-error) {
die('connect fail: ' . mysqli_connect_error());
}
This may break someday. It's undocumented what the error member should
do if the connection
#44405 [Opn-Bgs]: Math calculation problem with 1.19 - 1
ID: 44405
Updated by: [EMAIL PROTECTED]
Reported By: thbley at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: *General Issues
Operating System: WinVista
PHP Version: 5.2.5
New Comment:
Floating point values have a limited precision. Hence a value might
not have the same string representation after any processing. That also
includes writing a floating point value in your script and directly
printing it without any mathematical operations.
If you would like to know more about floats and what IEEE
754 is, read this:
http://docs.sun.com/source/806-3568/ncg_goldberg.html
Thank you for your interest in PHP.
Previous Comments:
[2008-03-11 11:04:00] thbley at gmail dot com
Description:
There seems to be a problem with the numeric calculation:
if ( (1.19 - 1) == 0.19 ) {
echo @@;
}
The expression (1.19 - 1) == 0.19 does not evaluate to true.
My environments (problem exists on both platforms):
WinVista: PHP 5.25
Debian: 5.2.0-8+etch10
Reproduce code:
---
if ( (1.19 - 1) == 0.19 ) {
echo @@;
}
Expected result:
output: @@
Actual result:
--
output: nothing
--
Edit this bug report at http://bugs.php.net/?id=44405edit=1
#44405 [NEW]: Math calculation problem with 1.19 - 1
From: thbley at gmail dot com
Operating system: WinVista
PHP version: 5.2.5
PHP Bug Type: *General Issues
Bug description: Math calculation problem with 1.19 - 1
Description:
There seems to be a problem with the numeric calculation:
if ( (1.19 - 1) == 0.19 ) {
echo @@;
}
The expression (1.19 - 1) == 0.19 does not evaluate to true.
My environments (problem exists on both platforms):
WinVista: PHP 5.25
Debian: 5.2.0-8+etch10
Reproduce code:
---
if ( (1.19 - 1) == 0.19 ) {
echo @@;
}
Expected result:
output: @@
Actual result:
--
output: nothing
--
Edit bug report at http://bugs.php.net/?id=44405edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44405r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44405r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44405r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44405r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44405r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44405r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44405r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44405r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44405r=support
Expected behavior:http://bugs.php.net/fix.php?id=44405r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44405r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44405r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44405r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44405r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44405r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44405r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44405r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44405r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44405r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44405r=mysqlcfg
#44406 [NEW]: Problem with use of 'require' or 'include'
From: dennis at studiomagenta dot co dot th Operating system: Linux Apache 1.3.41 PHP version: 5.2.5 PHP Bug Type: Scripting Engine problem Bug description: Problem with use of 'require' or 'include' Description: After including a 'require' statement in my PHP script I found that an echoed output of variables in the same script inserted an unwanted and unexpected space character (%20) before the first variable name. I found the same problem when using 'include' instead of 'require'. The included PHP script is located in the root of the web server, not in the public area. This space character effectively corrupted the name of the variable which caused it not to be recognised by my receiving Flash program. Output before including the 'require' statement: reply=valid usercompany_name=ABC Output after including the 'require' statement: %20reply=valid usercompany_name=ABC Reproduce code: --- ?php require '../../userpass.php'; echo reply=valid usercompany_name=ABC; ? And the sample code for the required file userpass.php: ?php $mySQLdatabase = 'some_database'; $mySQLusername = 'some_login'; $mySQLpassword = 'some_password'; ? Expected result: reply=valid usercompany_name=ABC Actual result: -- %20reply=valid usercompany_name=ABC -- Edit bug report at http://bugs.php.net/?id=44406edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44406r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44406r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44406r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44406r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44406r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44406r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44406r=needscript Try newer version:http://bugs.php.net/fix.php?id=44406r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44406r=support Expected behavior:http://bugs.php.net/fix.php?id=44406r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44406r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44406r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44406r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44406r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44406r=dst IIS Stability:http://bugs.php.net/fix.php?id=44406r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44406r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44406r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44406r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44406r=mysqlcfg
#44402 [Opn-Fbk]: Declare crashes Apache
ID: 44402 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: Windows Vista PHP Version: 5.2.5 New Comment: Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. Previous Comments: [2008-03-11 00:12:02] [EMAIL PROTECTED] Changed category to Preproducible Crash [2008-03-11 00:09:32] [EMAIL PROTECTED] Description: Using the declare construct causes Apache to crash on Windows Vista, aslong the declare(ticks=n) is present anywhere in the code it seems to crash Apache. I havn't tried this under IIS though and any other operating systems. Reproduce code: --- ?php declare(ticks=1); ? Or even the example on the documentation page Expected result: No crash Actual result: -- Windows promts me saying Apache has crashed with this message: Problem signature: Problem type: APPCRASH Program name: httpd.exe Program version: 2.2.6.0 Timestamp for program: 46deb625 Error module name: StackHash_d351 Error module version: 0.0.0.0 Timestamp on error module: Exception code: c005 Exception Shifting: 666f7270 OS version: 6.0.6000.2.0.0.256.1 Country standard id: 1030 More information 1: d351 More information 2: e4c68b1163c602091f1022ca6cd48c47 More information 3: a7a4 More information 4: e8322cccddd45a35753f145051c9d41d This is a translation of the box I retrive from Windows when executing any of the above examples. -- Edit this bug report at http://bugs.php.net/?id=44402edit=1
#44372 [Opn]: Extension compile failed
ID: 44372 User updated by: petr at hroch dot info Reported By: petr at hroch dot info Status: Open Bug Type: OCI8 related Operating System: Linux Debian Etch 4.0 PHP Version: 5.3CVS-2008-03-08 (snap) New Comment: This line oci8.c:1381: error: too many arguments to function 'OCIPing' causes the problem. I tryied to remove one argument from the OCIPing function arguments than extension compiled successfully, but I'm only guessing. Petr Previous Comments: [2008-03-10 23:36:05] [EMAIL PROTECTED] Let me re-open this since I think I can guess what the problem is and will fix it. Note to original poster: without any information about how you were building PHP, I can only hope my guess about your problem is right. [2008-03-08 22:18:33] [EMAIL PROTECTED] Pleas report issues with the pecl version on the pecl site. [2008-03-08 12:53:48] petr at hroch dot info Description: Extension compile failed using latest cvs snapshot Actual result: -- sit:/usr/install/src/oci8-1.3.1# make /bin/sh /usr/install/src/oci8-1.3.1/libtool --mode=compile gcc -I. -I/usr/install/src/oci8-1.3.1 -DPHP_ATOM_INC -I/usr/install/src/oci8-1.3.1/include -I/usr/install/src/oci8-1.3.1/main -I/usr/install/src/oci8-1.3.1 -I/usr/local/php/include/php -I/usr/local/php/include/php/main -I/usr/local/php/include/php/TSRM -I/usr/local/php/include/php/Zend -I/usr/local/php/include/php/ext -I/usr/local/php/include/php/ext/date/lib -I/usr/local/oracle/home1/rdbms/public -I/usr/local/oracle/home1/rdbms/demo -DHAVE_CONFIG_H -g -O2 -c /usr/install/src/oci8-1.3.1/oci8.c -o oci8.lo mkdir .libs gcc -I. -I/usr/install/src/oci8-1.3.1 -DPHP_ATOM_INC -I/usr/install/src/oci8-1.3.1/include -I/usr/install/src/oci8-1.3.1/main -I/usr/install/src/oci8-1.3.1 -I/usr/local/php/include/php -I/usr/local/php/include/php/main -I/usr/local/php/include/php/TSRM -I/usr/local/php/include/php/Zend -I/usr/local/php/include/php/ext -I/usr/local/php/include/php/ext/date/lib -I/usr/local/oracle/home1/rdbms/public -I/usr/local/oracle/home1/rdbms/demo -DHAVE_CONFIG_H -g -O2 -c /usr/install/src/oci8-1.3.1/oci8.c -fPIC -DPIC -o .libs/oci8.o /usr/install/src/oci8-1.3.1/oci8.c: In function 'php_oci_do_connect_ex': /usr/install/src/oci8-1.3.1/oci8.c:1150: warning: cast from pointer to integer of different size /usr/install/src/oci8-1.3.1/oci8.c:1346: warning: cast to pointer from integer of different size /usr/install/src/oci8-1.3.1/oci8.c: In function 'php_oci_connection_ping': /usr/install/src/oci8-1.3.1/oci8.c:1381: error: too many arguments to function 'OCIPing' make: *** [oci8.lo] Error 1 -- Edit this bug report at http://bugs.php.net/?id=44372edit=1
#44372 [Opn]: Extension compile failed
ID: 44372 User updated by: petr at hroch dot info Reported By: petr at hroch dot info Status: Open Bug Type: OCI8 related Operating System: Linux Debian Etch 4.0 PHP Version: 5.3CVS-2008-03-08 (snap) New Comment: To your previous comment: Extension was compiled externaly using phpize. P. Previous Comments: [2008-03-11 12:38:46] petr at hroch dot info This line oci8.c:1381: error: too many arguments to function 'OCIPing' causes the problem. I tryied to remove one argument from the OCIPing function arguments than extension compiled successfully, but I'm only guessing. Petr [2008-03-10 23:36:05] [EMAIL PROTECTED] Let me re-open this since I think I can guess what the problem is and will fix it. Note to original poster: without any information about how you were building PHP, I can only hope my guess about your problem is right. [2008-03-08 22:18:33] [EMAIL PROTECTED] Pleas report issues with the pecl version on the pecl site. [2008-03-08 12:53:48] petr at hroch dot info Description: Extension compile failed using latest cvs snapshot Actual result: -- sit:/usr/install/src/oci8-1.3.1# make /bin/sh /usr/install/src/oci8-1.3.1/libtool --mode=compile gcc -I. -I/usr/install/src/oci8-1.3.1 -DPHP_ATOM_INC -I/usr/install/src/oci8-1.3.1/include -I/usr/install/src/oci8-1.3.1/main -I/usr/install/src/oci8-1.3.1 -I/usr/local/php/include/php -I/usr/local/php/include/php/main -I/usr/local/php/include/php/TSRM -I/usr/local/php/include/php/Zend -I/usr/local/php/include/php/ext -I/usr/local/php/include/php/ext/date/lib -I/usr/local/oracle/home1/rdbms/public -I/usr/local/oracle/home1/rdbms/demo -DHAVE_CONFIG_H -g -O2 -c /usr/install/src/oci8-1.3.1/oci8.c -o oci8.lo mkdir .libs gcc -I. -I/usr/install/src/oci8-1.3.1 -DPHP_ATOM_INC -I/usr/install/src/oci8-1.3.1/include -I/usr/install/src/oci8-1.3.1/main -I/usr/install/src/oci8-1.3.1 -I/usr/local/php/include/php -I/usr/local/php/include/php/main -I/usr/local/php/include/php/TSRM -I/usr/local/php/include/php/Zend -I/usr/local/php/include/php/ext -I/usr/local/php/include/php/ext/date/lib -I/usr/local/oracle/home1/rdbms/public -I/usr/local/oracle/home1/rdbms/demo -DHAVE_CONFIG_H -g -O2 -c /usr/install/src/oci8-1.3.1/oci8.c -fPIC -DPIC -o .libs/oci8.o /usr/install/src/oci8-1.3.1/oci8.c: In function 'php_oci_do_connect_ex': /usr/install/src/oci8-1.3.1/oci8.c:1150: warning: cast from pointer to integer of different size /usr/install/src/oci8-1.3.1/oci8.c:1346: warning: cast to pointer from integer of different size /usr/install/src/oci8-1.3.1/oci8.c: In function 'php_oci_connection_ping': /usr/install/src/oci8-1.3.1/oci8.c:1381: error: too many arguments to function 'OCIPing' make: *** [oci8.lo] Error 1 -- Edit this bug report at http://bugs.php.net/?id=44372edit=1
#44402 [Fbk-Opn]: Declare crashes Apache
ID: 44402 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: Windows Vista PHP Version: 5.2.5 New Comment: When I run the debug tool I get this if its what you mean: Function Arg 1 Arg 2 Arg 3 Source 0x025f7816 0001 018a6fa2 06edf990 php5ts!php_remove_tick_function+8f 06edf990 01d1fb74 025e6c80 php5ts!zend_llist_apply_with_argument+22 025f85ec 018c1620 01d1fb74 php5ts!php_remove_tick_function+7b 06edbd00 06edbb30 php5ts!zend_llist_del_element+94 06edbb30 025e6c80 php5ts!zend_execute_scripts+107 Heres a full screenshot of the debug report: http://www.kalleload.com/uploads/kooaogvfial.jpg I had to attach it to httpd.exe as I wasn't able to reproduce this in cli mode. Previous Comments: [2008-03-11 12:08:25] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. [2008-03-11 00:12:02] [EMAIL PROTECTED] Changed category to Preproducible Crash [2008-03-11 00:09:32] [EMAIL PROTECTED] Description: Using the declare construct causes Apache to crash on Windows Vista, aslong the declare(ticks=n) is present anywhere in the code it seems to crash Apache. I havn't tried this under IIS though and any other operating systems. Reproduce code: --- ?php declare(ticks=1); ? Or even the example on the documentation page Expected result: No crash Actual result: -- Windows promts me saying Apache has crashed with this message: Problem signature: Problem type: APPCRASH Program name: httpd.exe Program version: 2.2.6.0 Timestamp for program: 46deb625 Error module name: StackHash_d351 Error module version: 0.0.0.0 Timestamp on error module: Exception code: c005 Exception Shifting: 666f7270 OS version: 6.0.6000.2.0.0.256.1 Country standard id: 1030 More information 1: d351 More information 2: e4c68b1163c602091f1022ca6cd48c47 More information 3: a7a4 More information 4: e8322cccddd45a35753f145051c9d41d This is a translation of the box I retrive from Windows when executing any of the above examples. -- Edit this bug report at http://bugs.php.net/?id=44402edit=1
#44407 [NEW]: When using FETCH_CLASS|CLASS_TYPE 'MyClass' an array of stdClass returned
From: robert dot allen at zircote dot com Operating system: Windows XP PHP version: 5.2.5 PHP Bug Type: PDO related Bug description: When using FETCH_CLASS|CLASS_TYPE 'MyClass' an array of stdClass returned Description: Windows XP / PHP 5.2.5 / PDO_ODBC When setFetchMode is called with FETCH_CLASS and the Object type specified the Object type is returned as stdClass in the array for fetchAll() however for fetch() returns the expected result of the defined object. Reproduce code: --- $stmt-setFetchMode(PDO :: FETCH_CLASS | PDO :: FETCH_CLASSTYPE, 'MyClass'); $stmt-execute(); $all = $stmt-fetchAll(); Expected result: return: Array ( [0] = MyClass Object (. Actual result: -- return: Array ( [0] = stdClass Object (. -- Edit bug report at http://bugs.php.net/?id=44407edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44407r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44407r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44407r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44407r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44407r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44407r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44407r=needscript Try newer version:http://bugs.php.net/fix.php?id=44407r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44407r=support Expected behavior:http://bugs.php.net/fix.php?id=44407r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44407r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44407r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44407r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44407r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44407r=dst IIS Stability:http://bugs.php.net/fix.php?id=44407r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44407r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44407r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44407r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44407r=mysqlcfg
#44408 [NEW]: make works, 'make test' core dumps
From: charlesg at unixrealm dot com Operating system: Solaris 10 PHP version: 5.2.5 PHP Bug Type: *Compile Issues Bug description: make works, 'make test' core dumps Description: Ran config like this: ./configure --with-mysql=/usr/local/mysql --with-oci8=/usr/pkgs/oracle/product/10.2.0/Db_1 --with-openssl=/usr/local/ssl --with-apxs2=/usr/pkgs/apache/2.2.8/mendel/bin/apxs Same synthax was used on a Solaris 10 SPARC. This is a Solaris 10 x86 platform: SunOS mendel 5.10 Generic_127112-07 i86pc i386 i86pc [EMAIL PROTECTED] isainfo amd64 i386 Here is the output of 'make test': [EMAIL PROTECTED] make test Build complete. Don't forget to run 'make test'. Segmentation Fault - core dumped *** Error code 139 (ignored) The following command caused the error: if test ! -z test -x ; then \ TEST_PHP_EXECUTABLE= \ TEST_PHP_SRCDIR=/usr/local/src/apache/php-5.2.5 \ CC=gcc \ -d 'open_basedir=' -d 'output_buffering=0' -d 'memory_limit=-1' /usr/local/src/apache/php-5.2.5/run-tests.php -U -d extension_dir=modules/ ` if test x != x; then for i in ; do . $i; /usr/local/src/apache/php-5.2.5/build/shtool echo -n -- -d extension=$dlname; done; fi` tests/; \ elif test ! -z sapi/cli/php test -x sapi/cli/php; then \ INI_FILE=`/usr/local/src/apache/php-5.2.5/sapi/cli/php -r 'echo php_ini_loaded_file();'`; \ if test $INI_FILE; then \ egrep -v '^extension[\t\ ]*=' $INI_FILE /usr/local/src/apache/php-5.2.5/tmp-php.ini; \ else \ echo /usr/local/src/apache/php-5.2.5/tmp-php.ini; \ fi; \ TEST_PHP_EXECUTABLE=/usr/local/src/apache/php-5.2.5/sapi/cli/php \ TEST_PHP_SRCDIR=/usr/local/src/apache/php-5.2.5 \ CC=gcc \ /usr/local/src/apache/php-5.2.5/sapi/cli/php -d 'open_basedir=' -d 'output_buffering=0' -d 'memory_limit=-1' /usr/local/src/apache/php-5.2.5/run-tests.php -c /usr/local/src/apache/php-5.2.5/tmp-php.ini -U -d extension_dir=/usr/local/src/apache/php-5.2.5/modules/ ` if test x != x; then for i in ; do . $i; /usr/local/src/apache/php-5.2.5/build/shtool echo -n -- -d extension=$dlname; done; fi` ; \ else \ echo ERROR: Cannot run tests without CLI sapi.; \ fi I tried to troubleshoot using dbx: [EMAIL PROTECTED] dbx sapi/cli/php core For information about new features see `help changes' To remove this message, put `dbxenv suppress_startup_message 7.5' in your .dbxrc Reading php core file header read successfully Reading ld.so.1 Reading librt.so.1 Reading libmysqlclient.so.15.0.0 Reading libsocket.so.1 Reading libnsl.so.1 Reading libm.so.2 Reading libintl.so.8.0.2 Reading libsec.so.1 Reading libc.so.1 Reading libz.so Reading libssl.so.0.9.8 Reading libcrypto.so.0.9.8 Reading libresolv.so.2 Reading libkstat.so.1 Reading libgen.so.1 Reading libdl.so.1 Reading libsched.so.1 Reading libclntsh.so.10.1 dbx: internal warning: (null)::srcname(InfoOrigin_CMDLINE): value ntcontab.c being set to nt.c Reading libxml2.so.2 Reading libpthread.so.1 Reading libiconv.so.2.4.0 Reading libaio.so.1 Reading libmd.so.1 Reading libgcc_s.so.1 Reading libavl.so.1 Reading libnnz10.so Reading libz.so.1 Reading iso_8859_1.so.3 [EMAIL PROTECTED] ([EMAIL PROTECTED]) program terminated by signal SEGV (no mapping at the fault address) 0xfecd515f: _memcpy+0x012f: movups 0x0020(%esi),%xmm2 Current function is php_date_parse_tzfile 550 tzi = timelib_parse_tzfile(formal_tzname, tzdb); (dbx) where [1] _memcpy(0x8047cc1, 0x8400fe0, 0xb, 0x8043368), at 0xfecd515f =[2] php_date_parse_tzfile(formal_tzname = (nil), tzdb = 0x8400fe0), line 550 in php_date.c [3] get_timezone_info(), line 650 in php_date.c [4] php_format_date(format = 0x8430cf4 Ymd_Hi, format_len = 6, ts = 0, localtime = 1), line 879 in php_date.c [5] php_date(ht = 0, return_value = (nil), return_value_ptr = (nil), this_ptr = (nil), return_value_used = 1, localtime = 1), line 864 in php_date.c [6] zend_do_fcall_common_helper_SPEC(execute_data = 0x80463a0), line 200 in zend_vm_execute.h [7] execute(op_array = (nil)), line 92 in zend_vm_execute.h [8] zend_execute_scripts(type = 8, retval = (nil), file_count = 3, ...), line 1134 in zend.c [9] php_execute_script(primary_file = 0x8046b54), line 2004 in main.c [10] main(argc = 13, argv = 0x8046bc4), line 1140 in php_cli.c (dbx) Reproduce code: --- Run: ./configure --with-mysql=/usr/local/mysql --with-oci8=/usr/pkgs/oracle/product/10.2.0/Db_1 --with-openssl=/usr/local/ssl --with-apxs2=/usr/pkgs/apache/2.2.8/mendel/bin/apxs make make test on a Solaris 10 i386 machine. -- Edit bug report at http://bugs.php.net/?id=44408edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44408r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44408r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44408r=trysnapshot60 Fixed in CVS:
#44409 [NEW]: PDO::FETCH_SERIALIZE calls __construct()
From: uwendel at mysql dot com
Operating system:
PHP version: 5.3CVS-2008-03-11 (CVS)
PHP Bug Type: PDO related
Bug description: PDO::FETCH_SERIALIZE calls __construct()
Description:
There seems to be very few documentation about PDO::FETCH_SERIALIZE in the
PHP manual but playing the guessing game from the code it seems that this
feature aims to support SPL/Serialize interface. As I'm not sure about the
purpose of PDO::FETCH_SERIALIZE I'm not sure if the following is a bug or
not. However, it seems to me that PDO::FETCH_SERIALIZE unintentionally
calls __construct().
One of the main ideas behind SPL/Serialize interface seems to be that for
unserialization the constructor of a class does not get called. The
constructor of a class has a different meaning than a helper function like
unserialize() and thus should not be called automatically. Let's check:
class myclass implements Serialize {
public function __construct() {
printf(%s()\n, __METHOD__);
}
public function serialize() {
printf(%s()\n, __METHOD__);
return any data from serialize();
}
public function unserialize($dat) {
printf(%s(%s)\n, __METHOD__, var_export($dat, true));
}
}
$obj1 = new myclass()
--- myclass::__construct()
$tmp = serialize($obj1)
$obj2 = unserialize($tmp)
--- myclass::unserialize('any data from serizalize()')
__construct() gets called only once for object creation but not again
during unserialization. Let's try that with PDO:
[...]
$stmt = $db-query(SELECT dat FROM test);
$rows = $stmt-fetchAll(PDO::FETCH_CLASS|PDO::FETCH_SERIZALIZE,
myclass);
-- myclass::unserialize(data from DB)
-- myclass::__construct()
[...]
PDO first calls unserialize() as its supposed to do. But then it also
calls __construct() which is against the idea of the Serialize interface
not to call the constructor automatically during unserialization.
Reproduce code:
---
sapi/cli/php -r '$db = new PDO(sqlite:/tmp/foo); $db-exec(DROP TABLE
test); $db-exec(CREATE TABLE test(dat VARCHAR(100))); $db-exec(INSERT
INTO test(dat) VALUES (\Data from DB\)); class myclass implements
Serializable { public function __construct() { printf(%s()\n,
__METHOD__); } public function serialize() { return any data from
serizalize(); } public function unserialize($dat) { printf(%s(%s)\n,
__METHOD__, var_export($dat, true)); }} $stmt = $db-query(SELECT * FROM
test); var_dump($stmt-fetchAll(PDO::FETCH_CLASS|PDO::FETCH_SERIALIZE,
myclass)); $obj = new myclass();
var_dump(unserialize(serialize($obj)));'
myclass::unserialize('Data from DB')
myclass::__construct()
array(1) {
[0]=
object(myclass)#3 (0) {
}
}
myclass::__construct()
myclass::unserialize('any data from serizalize()')
object(myclass)#4 (0) {
}
--
Edit bug report at http://bugs.php.net/?id=44409edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44409r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44409r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44409r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44409r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44409r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44409r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44409r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44409r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44409r=support
Expected behavior:http://bugs.php.net/fix.php?id=44409r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44409r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44409r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44409r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44409r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44409r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44409r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44409r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44409r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44409r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44409r=mysqlcfg
#44410 [NEW]: Java integration
From: pradeepb at shaw dot ca Operating system: Windows XP SP2 PHP version: 5.2.5 PHP Bug Type: *Configuration Issues Bug description: Java integration Description: When running a simple php script to load java.lang.System,it crashes with error Apache HTTP Server has encountered a problem Noticed it happens when loading jvm.dll on php.ini. Has this been fixed on latest releases? or java integration has been removed altogether from PHP5xx. -- Edit bug report at http://bugs.php.net/?id=44410edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44410r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44410r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44410r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44410r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44410r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44410r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44410r=needscript Try newer version:http://bugs.php.net/fix.php?id=44410r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44410r=support Expected behavior:http://bugs.php.net/fix.php?id=44410r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44410r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44410r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44410r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44410r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44410r=dst IIS Stability:http://bugs.php.net/fix.php?id=44410r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44410r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44410r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44410r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44410r=mysqlcfg
#44408 [Opn-Fbk]: make works, 'make test' core dumps
ID: 44408 Updated by: [EMAIL PROTECTED] Reported By: charlesg at unixrealm dot com -Status: Open +Status: Feedback -Bug Type: *Compile Issues +Bug Type: Reproducible crash Operating System: Solaris 10 PHP Version: 5.2.5 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: [2008-03-11 17:25:22] charlesg at unixrealm dot com Description: Ran config like this: ./configure --with-mysql=/usr/local/mysql --with-oci8=/usr/pkgs/oracle/product/10.2.0/Db_1 --with-openssl=/usr/local/ssl --with-apxs2=/usr/pkgs/apache/2.2.8/mendel/bin/apxs Same synthax was used on a Solaris 10 SPARC. This is a Solaris 10 x86 platform: SunOS mendel 5.10 Generic_127112-07 i86pc i386 i86pc [EMAIL PROTECTED] isainfo amd64 i386 Here is the output of 'make test': [EMAIL PROTECTED] make test Build complete. Don't forget to run 'make test'. Segmentation Fault - core dumped *** Error code 139 (ignored) The following command caused the error: if test ! -z test -x ; then \ TEST_PHP_EXECUTABLE= \ TEST_PHP_SRCDIR=/usr/local/src/apache/php-5.2.5 \ CC=gcc \ -d 'open_basedir=' -d 'output_buffering=0' -d 'memory_limit=-1' /usr/local/src/apache/php-5.2.5/run-tests.php -U -d extension_dir=modules/ ` if test x != x; then for i in ; do . $i; /usr/local/src/apache/php-5.2.5/build/shtool echo -n -- -d extension=$dlname; done; fi` tests/; \ elif test ! -z sapi/cli/php test -x sapi/cli/php; then \ INI_FILE=`/usr/local/src/apache/php-5.2.5/sapi/cli/php -r 'echo php_ini_loaded_file();'`; \ if test $INI_FILE; then \ egrep -v '^extension[\t\ ]*=' $INI_FILE /usr/local/src/apache/php-5.2.5/tmp-php.ini; \ else \ echo /usr/local/src/apache/php-5.2.5/tmp-php.ini; \ fi; \ TEST_PHP_EXECUTABLE=/usr/local/src/apache/php-5.2.5/sapi/cli/php \ TEST_PHP_SRCDIR=/usr/local/src/apache/php-5.2.5 \ CC=gcc \ /usr/local/src/apache/php-5.2.5/sapi/cli/php -d 'open_basedir=' -d 'output_buffering=0' -d 'memory_limit=-1' /usr/local/src/apache/php-5.2.5/run-tests.php -c /usr/local/src/apache/php-5.2.5/tmp-php.ini -U -d extension_dir=/usr/local/src/apache/php-5.2.5/modules/ ` if test x != x; then for i in ; do . $i; /usr/local/src/apache/php-5.2.5/build/shtool echo -n -- -d extension=$dlname; done; fi` ; \ else \ echo ERROR: Cannot run tests without CLI sapi.; \ fi I tried to troubleshoot using dbx: [EMAIL PROTECTED] dbx sapi/cli/php core For information about new features see `help changes' To remove this message, put `dbxenv suppress_startup_message 7.5' in your .dbxrc Reading php core file header read successfully Reading ld.so.1 Reading librt.so.1 Reading libmysqlclient.so.15.0.0 Reading libsocket.so.1 Reading libnsl.so.1 Reading libm.so.2 Reading libintl.so.8.0.2 Reading libsec.so.1 Reading libc.so.1 Reading libz.so Reading libssl.so.0.9.8 Reading libcrypto.so.0.9.8 Reading libresolv.so.2 Reading libkstat.so.1 Reading libgen.so.1 Reading libdl.so.1 Reading libsched.so.1 Reading libclntsh.so.10.1 dbx: internal warning: (null)::srcname(InfoOrigin_CMDLINE): value ntcontab.c being set to nt.c Reading libxml2.so.2 Reading libpthread.so.1 Reading libiconv.so.2.4.0 Reading libaio.so.1 Reading libmd.so.1 Reading libgcc_s.so.1 Reading libavl.so.1 Reading libnnz10.so Reading libz.so.1 Reading iso_8859_1.so.3 [EMAIL PROTECTED] ([EMAIL PROTECTED]) program terminated by signal SEGV (no mapping at the fault address) 0xfecd515f: _memcpy+0x012f: movups 0x0020(%esi),%xmm2 Current function is php_date_parse_tzfile 550 tzi = timelib_parse_tzfile(formal_tzname, tzdb); (dbx) where [1] _memcpy(0x8047cc1, 0x8400fe0, 0xb, 0x8043368), at 0xfecd515f =[2] php_date_parse_tzfile(formal_tzname = (nil), tzdb = 0x8400fe0), line 550 in php_date.c [3] get_timezone_info(), line 650 in php_date.c [4] php_format_date(format = 0x8430cf4 Ymd_Hi, format_len = 6, ts = 0, localtime = 1), line 879 in php_date.c [5] php_date(ht = 0, return_value = (nil), return_value_ptr = (nil), this_ptr = (nil), return_value_used = 1, localtime = 1), line 864 in php_date.c [6] zend_do_fcall_common_helper_SPEC(execute_data = 0x80463a0), line 200 in zend_vm_execute.h [7] execute(op_array = (nil)), line 92 in zend_vm_execute.h [8] zend_execute_scripts(type = 8, retval = (nil), file_count = 3, ...), line 1134 in zend.c [9] php_execute_script(primary_file = 0x8046b54), line 2004 in main.c [10] main(argc = 13, argv = 0x8046bc4), line 1140 in php_cli.c (dbx) Reproduce code: --- Run: ./configure --with-mysql=/usr/local/mysql
#44406 [Opn-Fbk]: Problem with use of 'require' or 'include'
ID: 44406 Updated by: [EMAIL PROTECTED] Reported By: dennis at studiomagenta dot co dot th -Status: Open +Status: Feedback Bug Type: Scripting Engine problem Operating System: Linux Apache 1.3.41 PHP Version: 5.2.5 New Comment: Try removing the trailing ? (it's optional anyway..) Previous Comments: [2008-03-11 11:35:44] dennis at studiomagenta dot co dot th Description: After including a 'require' statement in my PHP script I found that an echoed output of variables in the same script inserted an unwanted and unexpected space character (%20) before the first variable name. I found the same problem when using 'include' instead of 'require'. The included PHP script is located in the root of the web server, not in the public area. This space character effectively corrupted the name of the variable which caused it not to be recognised by my receiving Flash program. Output before including the 'require' statement: reply=valid usercompany_name=ABC Output after including the 'require' statement: %20reply=valid usercompany_name=ABC Reproduce code: --- ?php require '../../userpass.php'; echo reply=valid usercompany_name=ABC; ? And the sample code for the required file userpass.php: ?php $mySQLdatabase = 'some_database'; $mySQLusername = 'some_login'; $mySQLpassword = 'some_password'; ? Expected result: reply=valid usercompany_name=ABC Actual result: -- %20reply=valid usercompany_name=ABC -- Edit this bug report at http://bugs.php.net/?id=44406edit=1
#44406 [Fbk]: Problem with use of 'require' or 'include'
ID: 44406 Updated by: [EMAIL PROTECTED] Reported By: dennis at studiomagenta dot co dot th Status: Feedback Bug Type: Scripting Engine problem Operating System: Linux Apache 1.3.41 PHP Version: 5.2.5 New Comment: Note: In _both_ files! Previous Comments: [2008-03-11 21:32:35] [EMAIL PROTECTED] Try removing the trailing ? (it's optional anyway..) [2008-03-11 11:35:44] dennis at studiomagenta dot co dot th Description: After including a 'require' statement in my PHP script I found that an echoed output of variables in the same script inserted an unwanted and unexpected space character (%20) before the first variable name. I found the same problem when using 'include' instead of 'require'. The included PHP script is located in the root of the web server, not in the public area. This space character effectively corrupted the name of the variable which caused it not to be recognised by my receiving Flash program. Output before including the 'require' statement: reply=valid usercompany_name=ABC Output after including the 'require' statement: %20reply=valid usercompany_name=ABC Reproduce code: --- ?php require '../../userpass.php'; echo reply=valid usercompany_name=ABC; ? And the sample code for the required file userpass.php: ?php $mySQLdatabase = 'some_database'; $mySQLusername = 'some_login'; $mySQLpassword = 'some_password'; ? Expected result: reply=valid usercompany_name=ABC Actual result: -- %20reply=valid usercompany_name=ABC -- Edit this bug report at http://bugs.php.net/?id=44406edit=1
#44402 [Opn-Bgs]: Declare crashes Apache
ID: 44402 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Reproducible crash Operating System: Windows Vista PHP Version: 5.2.5 New Comment: Please check the manual: http://www.php.net/register_tick_function (and especially the note about threaded servers..) Not bug. Previous Comments: [2008-03-11 15:31:49] [EMAIL PROTECTED] When I run the debug tool I get this if its what you mean: Function Arg 1 Arg 2 Arg 3 Source 0x025f7816 0001 018a6fa2 06edf990 php5ts!php_remove_tick_function+8f 06edf990 01d1fb74 025e6c80 php5ts!zend_llist_apply_with_argument+22 025f85ec 018c1620 01d1fb74 php5ts!php_remove_tick_function+7b 06edbd00 06edbb30 php5ts!zend_llist_del_element+94 06edbb30 025e6c80 php5ts!zend_execute_scripts+107 Heres a full screenshot of the debug report: http://www.kalleload.com/uploads/kooaogvfial.jpg I had to attach it to httpd.exe as I wasn't able to reproduce this in cli mode. [2008-03-11 12:08:25] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. [2008-03-11 00:12:02] [EMAIL PROTECTED] Changed category to Preproducible Crash [2008-03-11 00:09:32] [EMAIL PROTECTED] Description: Using the declare construct causes Apache to crash on Windows Vista, aslong the declare(ticks=n) is present anywhere in the code it seems to crash Apache. I havn't tried this under IIS though and any other operating systems. Reproduce code: --- ?php declare(ticks=1); ? Or even the example on the documentation page Expected result: No crash Actual result: -- Windows promts me saying Apache has crashed with this message: Problem signature: Problem type: APPCRASH Program name: httpd.exe Program version: 2.2.6.0 Timestamp for program: 46deb625 Error module name: StackHash_d351 Error module version: 0.0.0.0 Timestamp on error module: Exception code: c005 Exception Shifting: 666f7270 OS version: 6.0.6000.2.0.0.256.1 Country standard id: 1030 More information 1: d351 More information 2: e4c68b1163c602091f1022ca6cd48c47 More information 3: a7a4 More information 4: e8322cccddd45a35753f145051c9d41d This is a translation of the box I retrive from Windows when executing any of the above examples. -- Edit this bug report at http://bugs.php.net/?id=44402edit=1
#44398 [Opn-Fbk]: ssl:// transport is not registered even when libeay32.dll in PATH
ID: 44398 Updated by: [EMAIL PROTECTED] Reported By: cmouse at desteem dot org -Status: Open +Status: Feedback Bug Type: Streams related Operating System: Windows XP SP 2 PHP Version: 5.2.5 New Comment: Did you enable openssl extension? Previous Comments: [2008-03-10 18:34:48] cmouse at desteem dot org Description: Even with php_curl.dll enabled and libeay32.dll and ssleay32.dll in PATH, PHP does not register ssl:// transport. Reproduce code: --- ?php $fp = fsockopen(ssl://www.cacert.org,443); fclose($fp); ? Expected result: For it to do just about nothing. Actual result: -- H:\php test.php.txt PHP Warning: fsockopen(): unable to connect to ssl://www.cacert.org/:443 (Unable to find the socket transport ssl - did you forget to enable it when you configured PHP?) in H:\test.php.txt on line 3 Warning: fsockopen(): unable to connect to ssl://www.cacert.org/:443 (Unable to find the socket transport ssl - did you forget to enable it when you configured PHP?) in H:\test.php on line 3 PHP Warning: fclose(): supplied argument is not a valid stream resource in H:\test.php on line 4 Warning: fclose(): supplied argument is not a valid stream resource in H:\test.php on line 4 -- Edit this bug report at http://bugs.php.net/?id=44398edit=1
#44394 [Opn-Fbk]: Last two bytes missing from output
ID: 44394
Updated by: [EMAIL PROTECTED]
Reported By: weirdan at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: Output Control
Operating System: Windows XP
PHP Version: 5.2.5
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:
[2008-03-10 16:03:29] weirdan at gmail dot com
Description:
It seems like a regression of http://bugs.php.net/bug.php?id=26862 -
two last bytes missing from output when using ob_flush() +
ob_end_clean(). ob_end_flush() works as expected though.
The same issue is observed on PHP 5.2.3 / Linux
Reproduce code:
---
?php
$string = a href='a?q=1'asd/a;
output_add_rewrite_var('a', 'b');
echo $string;
ob_flush();
ob_end_clean();
Expected result:
a href='a?q=1a=b'asd/a
Actual result:
--
a href='a?q=1a=b'asd/
--
Edit this bug report at http://bugs.php.net/?id=44394edit=1
#44375 [Opn-Fbk]: LDAP extension load failed
ID: 44375 Updated by: [EMAIL PROTECTED] Reported By: petr at hroch dot info -Status: Open +Status: Feedback Bug Type: LDAP related Operating System: Linux Debian Etch 4.0 PHP Version: 5.3CVS-2008-03-08 (CVS) New Comment: Did you 'make install' before re-phpizing the ldap module? And why do do you phpize ldap anyway, it's stock extension, just build it as static into the PHP.. Previous Comments: [2008-03-10 12:17:50] petr at hroch dot info I've found that this problem occures only if LDAP extension is compiled externaly using phpize. If it's compiled together with php core using general configure script, extension works fine. I don't know where might be a problem. Petr [2008-03-10 12:01:31] [EMAIL PROTECTED] Odd... Compile with success here. [2008-03-10 09:19:20] petr at hroch dot info Hi, problem still remains. Compiled PHP from source http://snaps.php.net/php5.3-latest.tar.gz php -m PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/php/lib/php/extensions/ldap.so' - /usr/local/php/lib/php/extensions/ldap.so: undefined symbol: third_arg_force_ref in Unknown on line 0 [PHP Modules] calendar ctype date dom ereg filter hash iconv json libxml openssl pcntl pcre PDO pdo_sqlite posix Reflection session SimpleXML sockets SPL SQLite standard sysvmsg sysvsem sysvshm tokenizer xml xmlreader xmlwriter zlib [Zend Modules] In PHP 5.2.5 everything works fine. Regards Petr [2008-03-08 20:49:43] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.3-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.3-win32-installer-latest.msi Hello, with a new checkout it works fine for me. [2008-03-08 14:49:15] petr at hroch dot info Correction for my previous post: php -m PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/php/lib/php/extensions/ldap.so' - /usr/local/php/lib/php/extensions/ldap.so: undefined symbol: third_arg_force_ref in Unknown on line 0 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/44375 -- Edit this bug report at http://bugs.php.net/?id=44375edit=1
#44349 [Opn-Asn]: Parse error with installer generated php.ini
ID: 44349 Updated by: [EMAIL PROTECTED] Reported By: jcs at austin dot rr dot com -Status: Open +Status: Assigned Bug Type: PHP options/info functions Operating System: Windows XP PHP Version: 5.2.5 Assigned To: jmertic Previous Comments: [2008-03-08 22:29:15] [EMAIL PROTECTED] Assigned to installer maintainer [2008-03-07 06:10:44] jcs at austin dot rr dot com OK, SOME PROGRESS: 1) I THINK THE ERROR THAT WAS GIVEN WAS BOGUS...THERE ARE MANY POSTS ON THE WEB THAT SHOW PARSE ERRORS TO LINES THAT DON'T EXIST IN PHI.INI FILES 2) GOT IT TO WORK BY: - COPYING THE ZIP INSTALL TO THE C:\PHP DIRECTORY. problem: could not figure out how to tell windows that PHP was there so every time I loaded a page it didn't know how to interpret a .php file. so: - WITHOUT ERASING, WROTE OVER THIS WITH THE INSTALL VERSION. this configured windows correctly but left the correct configuration in place. 3) in my opinion the installer is buggy. 4) The ZIP version is OK but maybe you should make it more clear to folks how to hook into Windows. 5) Why not have pay as you go tech support for install problems. I would have very happily PayPal-ed you guys $100 bucks to help me through this...it has been several nights to figure this out and read through all the postings out there. I STILL DON'T KNOW WHY IT WORKED OR WHAT WAS WRONG BUT I WILL TAKE THE WIN FOR NOW. Regards. [2008-03-06 04:19:05] jcs at austin dot rr dot com Description: Hi, I am having a hard time getting PHP to read the phi.ini file which I want to enable MySQL extensions with. If I run phpinfo(), I see it is lookong in C:\WINDOWS for the file but there is no loaded file. Copying the php.ini file to C:\WINDOWS does not help. OK: PHP installed to: 1) C:\PHP 2) extensions in: C:\PHP\ext 3) php.ini file in C:\PHP This was the installer generated file. 4) In a command window at the command line in C:\PHP I run php -c . php.ini I get the following: PHP Parse error: syntax error, unexpected T_LOGICAL_AND in C:\PHP\php.ini on line 126 The line is just a comment...I don't get it (see below). ; NOTE: Using short tags should be avoided when developing applications or Please help, I have wasted so much time on this. I think the loading of the php.ini is failing which is why my extensions don't work. Regards. Reproduce code: --- ; since short tags may not be supported on the target server. ; Language Options ; ; Enable the PHP scripting language engine under Apache. engine = On ; Enable compatibility mode with Zend Engine 1 (PHP 4.x) zend.ze1_compatibility_mode = Off ; Allow the ? tag. Otherwise, only ?php and script tags are recognized. ; NOTE: Using short tags should be avoided when developing applications or ; libraries that are meant for redistribution, or deployment on PHP ; servers which are not under your control, because short tags may not ; be supported on the target server. For portable, redistributable code, ; be sure not to use short tags. short_open_tag = Off ; Allow ASP-style % % tags. asp_tags = Off ; The number of significant digits displayed in floating point numbers. precision= 14 ; Enforce year 2000 compliance (will cause problems with non-compliant browsers) y2k_compliance = On ; Output buffering allows you to send header lines (including cookies) even -- Edit this bug report at http://bugs.php.net/?id=44349edit=1
#44343 [Opn-Bgs]: Session data is lost going from one page to another in Windows Server 2003.
ID: 44343 Updated by: [EMAIL PROTECTED] Reported By: ianwalter at jacksriver dot net -Status: Open +Status: Bogus Bug Type: Session related Operating System: Windows Server 2003 / Apache 2 PHP Version: 5.2.5 New Comment: Sessions work just fine when a) configured properly b) used properly. You don't give any additional info in this report. Please don't resubmit same report twice. Add comment to the earlier report instead. Thank you. Previous Comments: [2008-03-05 20:02:34] ianwalter at jacksriver dot net Description: Session data is lost going from one page to another in Windows Server 2003. This is a PHP bug, when are you going to address it? This is ridiculous. You're only hurting your own language (please dont make me go back to .NET) Whoever labeled bug #40964 'bogus' isn't cool. http://bugs.php.net/bug.php?id=40964 PS -- Your captcha SUCKS. -- Edit this bug report at http://bugs.php.net/?id=44343edit=1
#44342 [Opn-Fbk]: PHP crashes Apache 2.2
ID: 44342 Updated by: [EMAIL PROTECTED] Reported By: i dot galic at brainsware dot org -Status: Open +Status: Feedback -Bug Type: Unknown/Other Function +Bug Type: Reproducible crash Operating System: Solaris 10, Update 6, Sparc 64 PHP Version: 5.2.5 New Comment: ANY 3rd party modification not coming from php.net is not supported by php.net. So please, provide the trace without suhosin. And cut down your configure line to shortest possible. And don't define any CFLAGS / etc. either. Previous Comments: [2008-03-09 00:36:21] i dot galic at brainsware dot org So far my digging has born the idea that the reason is --enable-maintainer-zts, which enforces thread safety upon PHP by killing it ruthlessly, if it just so happens to behave in a thread-unsafe-manner. Now, I still would classify this as bug, because I only have PHP core modules loaded, namely: mysql.so mysqli.so pdo.so pdo_mysql.so bcmath.so gd.so php.net claims that it's core modules *are* thread safe -- unless noted otherwise. As not even the notorious gd: http://php.net/gd states to be thread-unsafe, this is either a bug, or lack of documentation. Whatever it is, I do not like the idea that this happens after a call to a destructor. It suggests to me the possibility of a potentially exploitable buffer-overflow or an otherwise corrupted memory. So I don't quite know which of the evils to choose (I have already recompiled PHP without the -zts flag, but haven't gotten yet to test it). [2008-03-05 19:54:13] i dot galic at brainsware dot org Description: Running a PHP Application (Zabbix) on Apache 2.2 with PHP 5.2.5 with Suhosin-Patch on Solaris 10, Update 6, Sparc, compiled for 64 bit. I do not know exactly how to reproduce the crash, I have however however several core dumps all of which look the same. Reproduce code: --- I built PHP http://dpaste.com/hold/38122/ (please consider that the paste will only retain for 30 days after nobody looked at it.) The Bug report tool says: Always disable any Zend or other 3rd party extensions (Turck MMCache, ionCube loader, Xdebug, APC) before submitting a *PHP* bug. I am not sure if --enable-maintainer-zts --enable-zend-multibyte are part of this restriction, as they are provided by standard PHP or Suhosin in my for that matter, as it does (unfortunately) not interfere here (see stack trace). Actual result: -- core 'core_asp1inmon001_httpd_1_12_1204718387_521' of 521: /opt/baw/bin/httpd -k start 7d6619dc t_splay (1003f7200, 69, 188c88, 68, 0, 1003f7220) + 24 7d66182c t_delete (1003f7200, a1, 188828, 7d661ca4, 7d7ea000, 0) + 60 7d6613f8 realfree (1003f7188, 69, 188c88, 68, 7d7ea000, 1003f7188) + 94 7d661ca4 _free_unlocked (7d7fb060, 2000, 2280, 7d7f9b08, 7d7ea000, 1003fbdb0) + c0 7d661bcc free (1003fbdb0, 2270, 188458, 776cfcc0, 7d7ea000, 2000) + 30 776b1014 zend_function_dtor (1004539a0, 10041e488, 0, 0, 10017c170, 10041e4b8) + 12c 776cfcc0 zend_hash_destroy (1001e7d50, 1, 100453930, 100453aa0, 77a458b0, 0) + 28 776bdea0 (10026bbb0, 77ad7798, 387a44, 800, 0, 9b8) 77635d10 tsrm_shutdown (91470, 77ad6d20, a0, 28, 77a458b0, 0) + b0 77748738 (0, 77642340, 77a458b0, 504c8, 2fd1a4, 50400) 7e51ce6c apr_pool_destroy (1003c33f8, 1003cd420, 0, 0, 1003c34c0, 0) + 26c 00010005315c (100178000, 100175000, 2, 100175, 10, 100178) 7d6d23c4 __sighndlr (f, 0, 7fff5040, 10005312c, 0, e) + c 7d6c6630 call_user_handler (7ae00200, 7ae00200, 7fff5040, 0, 0, 0) + 3e0 7d6d31b0 _read (e, 1009cbf20, 4000, 0, 7810c370, 780719a8) + c 77e6a6a4 (1009cbe20, 1009cff30, 4, 0, 1, 7) 77e6c8fc (1009cb920, 7fff55f8, 1009cff30, 4, 7810c370, 780719a8) 77e6cc3c (1009cb920, 77e62528, 780719a8, 10c494, 1, 1009cb920) 77e622f8 (1009cb920, 100766c50, 110538, 1009cbe20, 7810c370, 780719a8) 77e6639c (1009cb920, 77e62528, 780719a8, 10c494, 1, 1009cb920) 77e6686c (1009cb920, 100766c50, 13f, 77e66380, 7810c370, 780719a8) 78107978 (10022db88, e, , 0, 1, 1009716e0) 78107c24 (2, 1009716e0, 0, 0, 1, 10017c170) 776f8efc (7fff5db0, 10017c170, 78107b28, 0, 10090b9a0, 7fff5db0) 776f8a7c execute (100317680, 10017c170, 10026c390, 188, 10026c390, 10090b9a0)
#44335 [Opn-Fbk]: fsockopen on localhost on Vista
ID: 44335
Updated by: [EMAIL PROTECTED]
Reported By: php at smarinier dot net
-Status: Open
+Status: Feedback
Bug Type: Network related
Operating System: Windows Vista
PHP Version: 5.2.5
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:
[2008-03-05 11:16:54] php at smarinier dot net
Description:
A Localhost (or 127.0.0.1) connection with fsockopen failed on Vist
(see simple code later). As far as i can see, this:
- doesn't work with php 5.2.5, 5.2.1, 5.1.6, 5.0.3 : on Vista
- works with PHP 4.4.8 on Vista, or with any PHP on Windows Server
2003.
This is not the same problem as the getaddrinfo(localhost)-127.0.0.1,
wich is a (stupid) security protection from Windows.
Reproduce code:
---
?php
$fp = fsockopen('localhost', 80, $errno, $errstr, 30);
if (!$fp) {
echo $errstr ($errno)br /\n;
} else {
$out = GET / HTTP/1.1\r\nHost: localhost\r\nConnection:
Close\r\n\r\n;
fwrite($fp, $out);
while (!feof($fp)) {
echo fgets($fp, 128);
}
fclose($fp);
}
?
Expected result:
X-Powered-By: PHP/4.4.8
Content-type: text/html
Contentbr/HTTP/1.1 200 OK
Date: Wed, 05 Mar 2008 10:46:31 GMT
Server: Apache/2.2.8 (Win32) PHP/5.2.1
Last-Modified: Sat, 20 Nov 2004 13:16:26 GMT
ETag: 1be49-2c-3e9506e38be80
Accept-Ranges: bytes
Content-Length: 44
Connection: close
Content-Type: text/html
htmlbodyh1It works!/h1/body/html
Actual result:
--
PHP Warning: fsockopen(): unable to connect to localhost:80 (A
connection attempt failed \
because the connected party did not properly respond after a period of
time, or \
established connection failed because connected host has failed to
respond
) in C:\PHP\test.php on line 2
A connection attempt failed \
because the connected party did not properly respond after a period of
time, or \
established connection failed because connected host has failed to
respond. (10060)br /
--
Edit this bug report at http://bugs.php.net/?id=44335edit=1
#44293 [Opn-Bgs]: realpath does not follow Virtual directory
ID: 44293 Updated by: [EMAIL PROTECTED] Reported By: mmichel at chez dot com -Status: Open +Status: Bogus Bug Type: Filesystem function related Operating System: Win2003 PHP Version: 5.2.5 New Comment: Well, there's the problem: realpath() is an OS filesystem function and doesn't give a damn about any virtual stuff IIS might provide. No bug. Previous Comments: [2008-03-06 12:45:44] mmichel at chez dot com yes there is. Elsewhere could be accessed with ../../Elsewhere from the root directory of the website. Virtual Directories in IIS try to mimic symlinks, but they are not real files that can be tracked down like symlinks. This may be the problem determining the realpath. [2008-03-05 09:28:21] [EMAIL PROTECTED] So is there some path in your filesystem called Elsewhere which is relative to the current working directory? If there is, then this is a bug, but if there isn't, then it's not a bug. [2008-03-03 15:03:10] mmichel at chez dot com Try adding the trailing slash in the directory.. No change. [2008-03-03 14:48:34] [EMAIL PROTECTED] Try adding the trailing slash in the directory.. [2008-03-03 14:31:58] mmichel at chez dot com Addendum from my 3 Mar 1:56pm UTC comment: Whilst php is able to give me the realpath of the script http://localhost/elsewhere/test.php , asking for the realpath of http://localhost/elsewhere in the http://localhost/local/test.php script fails. 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/44293 -- Edit this bug report at http://bugs.php.net/?id=44293edit=1
#44273 [Opn-Bgs]: access to private and protected class variables allowed when casting to array
ID: 44273
Updated by: [EMAIL PROTECTED]
Reported By: paulscheltema at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Windows XP / Linux Debian
PHP Version: 5.2.5
New Comment:
Maybe this explains it better:
?php
class test {
public $public = 'public';
private $private = 'private';
protected $protected = 'protected';
}
$t = new test;
var_dump($t);
?
And this will output everything, and it's expected and the correct
behaviour. It's about the properties being isible/not-visible/writable
to other classes. PPP is not meant for providing any security.
(I admit, I'm bad at explaining things. :)
Previous Comments:
[2008-03-05 14:25:25] paulscheltema at gmail dot com
well, i guess its ok then, its just not what im used to with some other
languages
but i still think its wierd using protected to protect the data from
the outside world, but not quite doing so.
i now know storing vital information such as passwords inside class
variables even protected ones, doesnt help much.
so giving another developer access to an api doesnt protect me anymore
either
but if its no bug since changing the data isnt possible that way, so be
it.
and i have to say dont change the point:
first you say its about visibility,
i explain why it is,
next you say it doesnt matter because you cant change its value
[2008-03-05 14:03:01] [EMAIL PROTECTED]
Yes, but can you _change_ it? (answer: no, not via that array..)
[2008-03-04 13:27:58] paulscheltema at gmail dot com
I think the bug is that I CAN access private / protected class data at
runtime which neglects the whole point of private or protected data
inside classes. It is to be protected!
Why else use private data if you can access it anyway? its useless
then. its just obstruction instead of security. (security in terms of
data integrity)
On the positive side at least i can not change the data.
And to refer to your reaction precisely, lets have two classes A and B
A is instanciated and has a private property x which is set, class B
casts class A to an array and gains access to class A's private property
x. This is not directly about visibility but it allows class B to view
class A's private property x.
[2008-03-03 13:41:02] [EMAIL PROTECTED]
Private/protected is about visibility between _classes_ not with a
class cast to an array. So what's the bug here?
[2008-02-27 20:49:25] paulscheltema at gmail dot com
Description:
Hello dear developer(s),
When i setup a simple class with a protected/private var,
instanciate the class, and cast the instance to an array
i can access the protected/private var.
Reproduce code:
---
class test {
public $public = 'public';
private $private = 'private';
protected $protected = 'protected';
}
$t = new test;
$a = (array)$t;
print 'brpublic: '.$a['public'];
print 'brprivate: '.$a[\0test\0private];
print 'brprotected: '.$a[\0*\0protected];
Expected result:
Expected:
public: public
Or at most an Error like:
Cannot access private property test::$private
as the value of the private property
Actual result:
--
Result:
public: public
private: private
protected: protected
--
Edit this bug report at http://bugs.php.net/?id=44273edit=1
#44273 [Bgs]: access to private and protected class variables allowed when casting to array
ID: 44273
Updated by: [EMAIL PROTECTED]
Reported By: paulscheltema at gmail dot com
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Windows XP / Linux Debian
PHP Version: 5.2.5
New Comment:
And last but not least, here's an excerpt from the manual
(http://www.php.net/manual/en/language.oop5.visibility.php):
The visibility of a property or method can be defined by prefixing the
declaration with the keywords: public, protected or private. Public
declared items can be accessed everywhere. Protected limits access to
inherited and parent classes (and to the class that defines the item).
Private limits visibility only to the class that defines the item.
Previous Comments:
[2008-03-11 22:04:36] [EMAIL PROTECTED]
Maybe this explains it better:
?php
class test {
public $public = 'public';
private $private = 'private';
protected $protected = 'protected';
}
$t = new test;
var_dump($t);
?
And this will output everything, and it's expected and the correct
behaviour. It's about the properties being isible/not-visible/writable
to other classes. PPP is not meant for providing any security.
(I admit, I'm bad at explaining things. :)
[2008-03-05 14:25:25] paulscheltema at gmail dot com
well, i guess its ok then, its just not what im used to with some other
languages
but i still think its wierd using protected to protect the data from
the outside world, but not quite doing so.
i now know storing vital information such as passwords inside class
variables even protected ones, doesnt help much.
so giving another developer access to an api doesnt protect me anymore
either
but if its no bug since changing the data isnt possible that way, so be
it.
and i have to say dont change the point:
first you say its about visibility,
i explain why it is,
next you say it doesnt matter because you cant change its value
[2008-03-05 14:03:01] [EMAIL PROTECTED]
Yes, but can you _change_ it? (answer: no, not via that array..)
[2008-03-04 13:27:58] paulscheltema at gmail dot com
I think the bug is that I CAN access private / protected class data at
runtime which neglects the whole point of private or protected data
inside classes. It is to be protected!
Why else use private data if you can access it anyway? its useless
then. its just obstruction instead of security. (security in terms of
data integrity)
On the positive side at least i can not change the data.
And to refer to your reaction precisely, lets have two classes A and B
A is instanciated and has a private property x which is set, class B
casts class A to an array and gains access to class A's private property
x. This is not directly about visibility but it allows class B to view
class A's private property x.
[2008-03-03 13:41:02] [EMAIL PROTECTED]
Private/protected is about visibility between _classes_ not with a
class cast to an array. So what's the bug here?
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/44273
--
Edit this bug report at http://bugs.php.net/?id=44273edit=1
#44250 [Opn-Fbk]: PHP CLI :: *** glibc detected *** realloc():
ID: 44250 Updated by: [EMAIL PROTECTED] Reported By: toni at igmweb dot com -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: Red Hat Enterprise Linux ES rele PHP Version: 5.2.5 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 And note: --enable-dmalloc is for debugging purposes only! Do not use if you don't really need it. Previous Comments: [2008-02-26 14:35:37] toni at igmweb dot com After some tests. I found that without --enable-dmalloc PHP CLI runs OK. No more realloc() errors on make test. But appears a message saying that it found a possible PHP error. I pasted the text below. -- = FAILED TEST SUMMARY - Error message handling (with ZendOptimizer) [tests/run-test/test008.phpt] Convert warnings to exceptions [tests/lang/038.phpt] Bug #32828 (Throwing exception in output_callback function with ob_start and ob_end_clean leads to segfault) [tests/lang/bug32828.phpt] Bug #32290 (calling call_user_func_array() ends in infinite loop within child class) [Zend/tests/bug32290.phpt] Bug #36268 (Object destructors called even after fatal errors) [Zend/tests/bug36268.phpt] Bug #41421 (Uncaught exception from a stream wrapper segfaults) [Zend/tests/bug41421.phpt] easter_date() [ext/calendar/tests/easter_date.phpt] unixtojd() [ext/calendar/tests/unixtojd.phpt] date OO cloning [ext/date/tests/oo_002.phpt] Bug #38474 (getAttribute select attribute by order, even when prefixed) (OK to fail with libxml2 2.6.2x) [ext/dom/tests/bug38474.phpt] Bug #42082 (NodeList length zero should be empty) [ext/dom/tests/bug42082.phpt] iconv stream filter [ext/iconv/tests/iconv_stream_filter.phpt] Bug #41567 (json_encode() double conversion is inconsistent with PHP) [ext/json/tests/bug41567.phpt] SPL: spl_autoload() with methods [ext/spl/tests/spl_autoload_005.phpt] SPL: spl_autoload() with inaccessible methods [ext/spl/tests/spl_autoload_007.phpt] SPL: spl_autoload() with exceptions [ext/spl/tests/spl_autoload_008.phpt] Test array_map() function [ext/standard/tests/array/array_map.phpt] Test array_reverse() function : usage variations - assoc. array with diff. value for 'array' argument [ext/standard/tests/array/array_reverse_variation5.phpt] Test array_unshift() function : usage variations - assoc. array with diff values for 'array' argument [ext/standard/tests/array/array_unshift_variation5.phpt] Bug #35821 (array_map() segfaults when exception is throwed from the callback) [ext/standard/tests/array/bug35821.phpt] Bug #38450 (constructor is not called for classes used in userspace stream wrappers) [ext/standard/tests/file/bug38450_2.phpt] proc_open() regression test 1 (proc_open() leak) [ext/standard/tests/file/proc_open01.phpt] register_shutdown_function() __call [ext/standard/tests/general_functions/010.phpt] Bug #32647 (Using register_shutdown_function() with invalid callback can crash PHP) [ext/standard/tests/general_functions/bug32647.phpt] Bug #40398 (parent and self callback functions erroneously called statically) [ext/standard/tests/general_functions/bug40398.phpt] Test is_callable() function [ext/standard/tests/general_functions/is_callable.phpt] htmlentities() test 2 (setlocale / fr_FR.ISO-8859-15) [ext/standard/tests/strings/htmlentities02.phpt] (warn: possibly braindead libc) htmlentities() test 4 (setlocale / ja_JP.EUC-JP) [ext/standard/tests/strings/htmlentities04.phpt] (warn: possibly braindead libc) htmlentities() test 15 (setlocale / KOI8-R) [ext/standard/tests/strings/htmlentities15.phpt] (warn: possibly braindead libc) Test vsprintf() function : usage variations - string formats with non-string values [ext/standard/tests/strings/vsprintf_variation8.phpt] Bug #32001 (xml_parse*() goes into infinite loop when autodetection in effect), using UTF-* [ext/xml/tests/bug32001.phpt] CLI long options [sapi/cli/tests/015.phpt] = You may have found a problem in PHP. We would like to send this report automatically to the PHP QA team, to give us a better understanding of how the test cases are doing. If you don't want to send it immediately, you can choose s to save the report to a file that you can send us later. Do you want to send this report now? [Yns]: Y [2008-02-26 10:29:41] toni at igmweb dot com Description: I compile php 5.2.5 on a RedHat Enterprise Linux htsphp1 2.6.9-42.ELsmp #1 SMP Wed Jul 12 23:32:02 EDT 2006 x86_64 x86_64 x86_64 GNU/Linux
#44249 [Opn-Fbk]: build test failed
ID: 44249
Updated by: [EMAIL PROTECTED]
Reported By: jthrom2 at uiuc dot edu
-Status: Open
+Status: Feedback
Bug Type: Compile Failure
Operating System: Fedora 7
PHP Version: 5.2.5
New Comment:
Is this a 64 bit system? If so, check that you have all devel stuff
installed and that they're 64bit too.
This might reveal some info:
# rpm -ql zlib-devel
Previous Comments:
[2008-02-26 04:10:43] jthrom2 at uiuc dot edu
Description:
Installing PHP to use with MythWeb
Reproduce code:
---
./configure --with-mysql --with-apache=../apache_1.3.41
this appears down the page
Configuring extensions
checking whether to enable LIBXML support... yes
checking libxml2 install dir... no
checking for xml2-config path... /usr/bin/xml2-config
checking whether libxml build works... no
configure: error: build test failed. Please check the config.log for
details.
Actual result:
--
from config.log
configure:20055: gcc -o conftest -g -O2 conftest.c
-lresolv -lm -ldl -lnsl -lxml2 -lz -lm 15
/usr/bin/ld: skipping incompatible /usr/lib/libz.so when searching for
-lz
/usr/bin/ld: skipping incompatible /usr/lib/libz.a when searching for
-lz
/usr/bin/ld: cannot find -lz
collect2: ld returned 1 exit status
configure: failed program was:
#line 20044 configure
#include confdefs.h
char xmlInitParser();
int main() {
xmlInitParser();
return 0;
}
--
Edit this bug report at http://bugs.php.net/?id=44249edit=1
#44237 [Opn-Fbk]: mbstring.func_overload
ID: 44237
Updated by: [EMAIL PROTECTED]
Reported By: lip at lip dot net dot ua
-Status: Open
+Status: Feedback
Bug Type: Apache2 related
Operating System: Debian 4.0
PHP Version: 5.2.5
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:
[2008-02-25 13:29:36] baco at infomaniak dot ch
As workaround try to force mbstring.func_overload = 0 in your php.ini
and use this patch.
PHP5
unix_mbstring_func_overload.patch
--- ext/mbstring/mbstring.c 2007-09-24 13:51:36.0 +0200
+++ ext/mbstring/mbstring.c 2007-12-04 18:00:10.023564681 +0100
@@ -765,8 +765,8 @@
PHP_INI_ENTRY(mbstring.script_encoding, NULL, PHP_INI_ALL,
OnUpdate_mbstring_script_encoding)
#endif /* ZEND_MULTIBYTE */
PHP_INI_ENTRY(mbstring.substitute_character, NULL,
PHP_INI_ALL, OnUpdate_mbstring_substitute_character)
-STD_PHP_INI_ENTRY(mbstring.func_overload, 0,
PHP_INI_SYSTEM |
-PHP_INI_PERDIR, OnUpdateLong, func_overload,
zend_mbstring_globals, mbstring_globals)
+STD_PHP_INI_ENTRY(mbstring.func_overload, 0,
+PHP_INI_SYSTEM, OnUpdateLong, func_overload,
zend_mbstring_globals, mbstring_globals)
STD_PHP_INI_BOOLEAN(mbstring.encoding_translation, 0,
PHP_INI_SYSTEM | PHP_INI_PERDIR,
OnUpdate_mbstring_encoding_translation,
PHP4
--- ext/mbstring/mbstring.c 2007-04-04 17:28:18.0 +0200
+++ ext/mbstring/mbstring.c 2007-12-04 18:05:29.363559316 +0100
@@ -815,8 +815,8 @@
PHP_INI_ENTRY(mbstring.script_encoding, NULL, PHP_INI_ALL,
OnUpdate_mbstring_script_encoding)
#endif /* ZEND_MULTIBYTE */
PHP_INI_ENTRY(mbstring.substitute_character, NULL,
PHP_INI_ALL, OnUpdate_mbstring_substitute_character)
-STD_PHP_INI_ENTRY(mbstring.func_overload, 0,
PHP_INI_SYSTEM |
-PHP_INI_PERDIR, OnUpdateInt, func_overload,
zend_mbstring_globals, mbstring_globals)
+STD_PHP_INI_ENTRY(mbstring.func_overload, 0,
+PHP_INI_SYSTEM, OnUpdateInt, func_overload,
zend_mbstring_globals, mbstring_globals)
STD_PHP_INI_BOOLEAN(mbstring.encoding_translation, 0,
PHP_INI_SYSTEM | PHP_INI_PERDIR,
OnUpdate_mbstring_encoding_translation,
[2008-02-24 22:23:08] lip at lip dot net dot ua
Expected result:
php1.net - Warning: mb_ereg() function.mb-ereg: mbregex compile err:
premature end of char-class in /var/www/php2/mb.php
php2.net - galaD
Actual result:
--
php1.net - Warning
php2.net - Warning
[2008-02-24 22:03:13] lip at lip dot net dot ua
Description:
PHP 5.2.5
Apache/2.2.8
If I use mbstring.func_overload in .htaccess
other virtual-host doesn't work.
For example:
VirtualHost *:80
DocumentRoot /var/www/php1
ServerName php1.net
/VirtualHost
VirtualHost *:80
DocumentRoot /var/www/php2
ServerName php2.net
/VirtualHost
in /var/www/php1/.htaccess
php_value mbstring.func_overload 6
In this situation php2.net/mb.php doesn't work when I refresh few
times php1.net/mb.php and php2.net/mb.php
Reproduce code:
---
--mb.php---
?php
$re0 = '(^|()+|[^\])';
$dbname_to_test = 'galaD';
if (ereg($re0,$dbname_to_test))
{
var_dump ($dbname_to_test);
}
?
Expected result:
galaD
Actual result:
--
Warning: mb_ereg() function.mb-ereg: mbregex compile err: premature
end of char-class in /var/www/php2/mb.php
--
Edit this bug report at http://bugs.php.net/?id=44237edit=1
#44102 [Opn-Fbk]: Problem with compiling SQL Relay PHP
ID: 44102 Updated by: [EMAIL PROTECTED] Reported By: admin at relax-info dot com -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: MAC OS X Leopard 10.5.2 PHP Version: 5.2.5 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: [2008-03-03 17:53:56] admin at relax-info dot com Also, then I run searh for libphp* on my file system. Search result: ./sapi/apache_hooks/ libphp5.module.in ./sapi/apache/ libphp5.module.in ./libs/ libphp5.bundle libphp5.so [2008-03-03 17:43:27] admin at relax-info dot com Hmm, the linker of libraries in MAC OS X search for libx.dylib or libx.a in the library search path. But when I finished compile process with - -enable-static, I do not found libphp.dylib or libphp5.dylib or libphp.a or libphp5.a. Then SQLRelay can't compile because dl could not found PHP5 libraries. P.S: Mac OS X ld manual: http://developer.apple.com/documentation/Darwin/Reference/ManPages/man1/ ld.1.html [2008-02-13 16:50:31] [EMAIL PROTECTED] Exactly what does this has to do with PHP? Your log is for something else than building PHP, AFAICT. You should propably be asking support from the sql relay folks.. [2008-02-11 22:18:56] admin at relax-info dot com Description: After PHP compilation the libphp.a are not present on MAC OS X Reproduce code: --- The PHP configure options: /configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --mandir=/usr/share/man --infodir=/usr/share/info --with-apxs2=/usr/sbin/apxs --with-curl --with-gd --enable-exif --enable-cli --enable-zip --with-jpeg-dir=/usr/src/libjpeg --with-zlib=/usr --with-config-file-path=/etc --with-openssl --with-xmlrpc --with-xsl=/usr --without-pear --with-mysql=/usr/local/mysql --with-mysql-sock=/var/mysql --with-mysqli=/usr/local/mysql/bin/mysql_config --disable-ipv6 Expected result: Compile SQL Relay as Additional Modules Actual result: -- first try errors : ld: library not found for -lphp collect2: ld returned 1 exit status make[4]: *** [libsql_relay.la] Error 1 Full log: http://relax-info.com/data/file/Installing_sql_relay.txt -- Edit this bug report at http://bugs.php.net/?id=44102edit=1
#44394 [Fbk-Opn]: Last two bytes missing from output
ID: 44394
User updated by: weirdan at gmail dot com
Reported By: weirdan at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: Output Control
Operating System: Windows XP
PHP Version: 5.2.5
New Comment:
not fixed on WinXP, tested with this script:
?php
echo phpversion() . \n;
$string = a href='a?q=1'asd/a;
output_add_rewrite_var('a', 'b');
echo $string;
ob_flush();
ob_end_clean();
Results:
C:\Windows\system32\cmd.exe /c .\php.exe q.php | more
5.2.6RC3-dev
a href='a?q=1a=b'asd/
Hit any key to close this window...
Previous Comments:
[2008-03-11 21:36:52] [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
[2008-03-10 16:03:29] weirdan at gmail dot com
Description:
It seems like a regression of http://bugs.php.net/bug.php?id=26862 -
two last bytes missing from output when using ob_flush() +
ob_end_clean(). ob_end_flush() works as expected though.
The same issue is observed on PHP 5.2.3 / Linux
Reproduce code:
---
?php
$string = a href='a?q=1'asd/a;
output_add_rewrite_var('a', 'b');
echo $string;
ob_flush();
ob_end_clean();
Expected result:
a href='a?q=1a=b'asd/a
Actual result:
--
a href='a?q=1a=b'asd/
--
Edit this bug report at http://bugs.php.net/?id=44394edit=1
#44138 [Opn-Fbk]: zlib.compression causes blank screens
ID: 44138 Updated by: [EMAIL PROTECTED] Reported By: owner at dragon-hearts dot net -Status: Open +Status: Feedback Bug Type: Zlib Related Operating System: CentOs 4 PHP Version: 5.2.5 New Comment: PLEASE read the instructions found at http://bugs.php.net/how-to-report.php and provide the basic information needed. Previous Comments: [2008-02-24 20:23:28] owner at dragon-hearts dot net There's not much more I can give since it seems quite random, from reading something about safari which mentions something about content-length being incorrect. All I know is disableing zlib.compression does stop it. [2008-02-24 20:06:03] [EMAIL PROTECTED] 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. [2008-02-16 17:36:27] owner at dragon-hearts dot net Description: When zlib.compression is enabled randomly pages will appear blank (a completely white screen) this happens on Internet Explorer 6 and 7, Firefox 2 and in Safari 3 a similar issue happens but it shows an error message of bad server response (NSURLErrorDomain:-1011. Without zlib.compression everything loads fine. When using apache's mod_deflate to compress output everything works fine. -- Edit this bug report at http://bugs.php.net/?id=44138edit=1
#44273 [Bgs]: access to private and protected class variables allowed when casting to array
ID: 44273
User updated by: paulscheltema at gmail dot com
Reported By: paulscheltema at gmail dot com
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Windows XP / Linux Debian
PHP Version: 5.2.5
New Comment:
ok, sorry for your time.
It came on to me as being very strange behaviour.
Its just really annoying you cant hide variables inside classes that
way.
But as the manual says its just about classes, nothing else.
Strange to see then that in newer php versions it is recommended (even
throws an error using strict) to use private/protected/public when
really it doesn't add anything but obstruction.
but again sorry for your time, and ty for the awnser.
regards,
paul
Previous Comments:
[2008-03-11 22:06:32] [EMAIL PROTECTED]
And last but not least, here's an excerpt from the manual
(http://www.php.net/manual/en/language.oop5.visibility.php):
The visibility of a property or method can be defined by prefixing the
declaration with the keywords: public, protected or private. Public
declared items can be accessed everywhere. Protected limits access to
inherited and parent classes (and to the class that defines the item).
Private limits visibility only to the class that defines the item.
[2008-03-11 22:04:36] [EMAIL PROTECTED]
Maybe this explains it better:
?php
class test {
public $public = 'public';
private $private = 'private';
protected $protected = 'protected';
}
$t = new test;
var_dump($t);
?
And this will output everything, and it's expected and the correct
behaviour. It's about the properties being isible/not-visible/writable
to other classes. PPP is not meant for providing any security.
(I admit, I'm bad at explaining things. :)
[2008-03-05 14:25:25] paulscheltema at gmail dot com
well, i guess its ok then, its just not what im used to with some other
languages
but i still think its wierd using protected to protect the data from
the outside world, but not quite doing so.
i now know storing vital information such as passwords inside class
variables even protected ones, doesnt help much.
so giving another developer access to an api doesnt protect me anymore
either
but if its no bug since changing the data isnt possible that way, so be
it.
and i have to say dont change the point:
first you say its about visibility,
i explain why it is,
next you say it doesnt matter because you cant change its value
[2008-03-05 14:03:01] [EMAIL PROTECTED]
Yes, but can you _change_ it? (answer: no, not via that array..)
[2008-03-04 13:27:58] paulscheltema at gmail dot com
I think the bug is that I CAN access private / protected class data at
runtime which neglects the whole point of private or protected data
inside classes. It is to be protected!
Why else use private data if you can access it anyway? its useless
then. its just obstruction instead of security. (security in terms of
data integrity)
On the positive side at least i can not change the data.
And to refer to your reaction precisely, lets have two classes A and B
A is instanciated and has a private property x which is set, class B
casts class A to an array and gains access to class A's private property
x. This is not directly about visibility but it allows class B to view
class A's private property x.
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/44273
--
Edit this bug report at http://bugs.php.net/?id=44273edit=1
#44411 [NEW]: Broken Compatibility
From: phpbugs at steve dot ipapp dot com
Operating system: ANY
PHP version: 5.2.5
PHP Bug Type: SimpleXML related
Bug description: Broken Compatibility
Description:
In PHP 5.0.x and 5.1.x two SimpleXMLElement objects were considered equal
if they represented the same data.
In PHP 5.2.x this does not seem to be the case anymore. This was
previously listed as bug 39866 [http://bugs.php.net/bug.php?id=39866], but
for some reason this was listed as bogus. In that bug it was noted that we
should look at Example 5 at http://php.net/simplexml. I'm assuming this is
Example 6 now [Comparing Elements and Attributes with Text] , but this is
incorrect as comparision will implicity cast
it to string anyway.
According to
http://www.php.net/manual/en/language.oop5.object-comparison.php:
When using the comparison operator (==), object variables are compared in
a simple manner, namely: Two object instances are equal if they have the
same attributes and values, and are instances of the same class... On the
other hand, when using the identity operator (===), object variables are
identical if and only if they refer to the same instance of the same
class.
Furthermore this backwards incompatible change is not listed in :
http://us.php.net/manual/en/migration52.incompatible.php.
Currently there is no equals method that we can call to get the previous
functionality back, and at the present moment this makes == no longer
transitive as especially since this makes == no longer transitive as 'doc'
== x1, 'doc' == x2, but x1 != x2.
I do not understand why ==, nor do I see value in, doing a strict
comparison for SimpleXMLObjects as ==, when according to the PHP Object
Comparison manual this should be ===.
Therefore I believe this is a bug.
Reproduce code:
---
$xmldoc = xmlvaluefoo/value/xml;
$sax1 = new SimpleXMLElement($xmldoc);
$sax2 = new SimpleXMLElement($xmldoc);
if($sax1 == $sax2)
{
echo TRUE;
} else
{
echo FALSE;
}
echo \n\n\n;
Expected result:
TRUE
Actual result:
--
FALSE
--
Edit bug report at http://bugs.php.net/?id=44411edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44411r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44411r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44411r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44411r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44411r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44411r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44411r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44411r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44411r=support
Expected behavior:http://bugs.php.net/fix.php?id=44411r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44411r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44411r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44411r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44411r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44411r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44411r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44411r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44411r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44411r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44411r=mysqlcfg
#44394 [Opn-Csd]: Last two bytes missing from output
ID: 44394
Updated by: [EMAIL PROTECTED]
Reported By: weirdan at gmail dot com
-Status: Open
+Status: Closed
Bug Type: Output Control
Operating System: Windows XP
PHP Version: 5.2.6RC2
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.
Fixed in 5_3 and HEAD.
Previous Comments:
[2008-03-11 22:31:42] weirdan at gmail dot com
not fixed on WinXP, tested with this script:
?php
echo phpversion() . \n;
$string = a href='a?q=1'asd/a;
output_add_rewrite_var('a', 'b');
echo $string;
ob_flush();
ob_end_clean();
Results:
C:\Windows\system32\cmd.exe /c .\php.exe q.php | more
5.2.6RC3-dev
a href='a?q=1a=b'asd/
Hit any key to close this window...
[2008-03-11 21:36:52] [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
[2008-03-10 16:03:29] weirdan at gmail dot com
Description:
It seems like a regression of http://bugs.php.net/bug.php?id=26862 -
two last bytes missing from output when using ob_flush() +
ob_end_clean(). ob_end_flush() works as expected though.
The same issue is observed on PHP 5.2.3 / Linux
Reproduce code:
---
?php
$string = a href='a?q=1'asd/a;
output_add_rewrite_var('a', 'b');
echo $string;
ob_flush();
ob_end_clean();
Expected result:
a href='a?q=1a=b'asd/a
Actual result:
--
a href='a?q=1a=b'asd/
--
Edit this bug report at http://bugs.php.net/?id=44394edit=1
#44412 [NEW]: file_exists():PHP got 100% cpu load.
From: yarodin at gmail dot com
Operating system: Windows XP PRO/5.1.2600
PHP version: 5.2.5
PHP Bug Type: Directory function related
Bug description: file_exists():PHP got 100% cpu load.
Description:
Apache 2.2.8/mod_php5
file_exist() func make 100% cpu load on some buggy string passed as param.
See reproduce code.
Reproduce code:
---
?
if
(file_exists(e107_images/newspost_images/http://gpa.ptungr.office.ttg/e107_images/pcmag.png;))
{
print_r(YAY\n);
} else {
print_r(NOONE\n);
}
?
Expected result:
high cpu loadby php.
--
Edit bug report at http://bugs.php.net/?id=44412edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44412r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44412r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44412r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44412r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44412r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44412r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44412r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44412r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44412r=support
Expected behavior:http://bugs.php.net/fix.php?id=44412r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44412r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44412r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44412r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44412r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44412r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44412r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44412r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44412r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44412r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44412r=mysqlcfg
#44413 [NEW]: PHP has encountered an Access Violation at 0446932E
From: m dot r dot black at aggiemail dot usu dot edu Operating system: Windows Server 2003 PHP version: 5.2.5 PHP Bug Type: IIS related Bug description: PHP has encountered an Access Violation at 0446932E Description: PHP has encountered an Access Violation at 0446932E I've follow what help i could online to install PHP on IIS including verifying my .ini file and all i get is this code. I tried messing around with capitalization and stuff because i heard from some that's what they had to do but still no luck and i've googled the violation and no one has posted that specific error. You're welcome to check for yourself at: http://www.snowstomp.info/MYPHP.PHP Reproduce code: --- html body pHTML is working/p br ?php echo PHP is working; ? /html /body Expected result: The two lines of code. Actual result: -- PHP has encountered an Access Violation at 0446932E -- Edit bug report at http://bugs.php.net/?id=44413edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44413r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44413r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44413r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44413r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44413r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44413r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44413r=needscript Try newer version:http://bugs.php.net/fix.php?id=44413r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44413r=support Expected behavior:http://bugs.php.net/fix.php?id=44413r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44413r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44413r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44413r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44413r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44413r=dst IIS Stability:http://bugs.php.net/fix.php?id=44413r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44413r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44413r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44413r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44413r=mysqlcfg
#44372 [Opn-Csd]: Extension compile failed
ID: 44372 Updated by: [EMAIL PROTECTED] Reported By: petr at hroch dot info -Status: Open +Status: Closed Bug Type: OCI8 related Operating System: Linux Debian Etch 4.0 PHP Version: 5.3CVS-2008-03-08 (snap) 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. +-- | Fixed in PHP 5.3 PHP 6. Not fixed in 5.2, which wasn't affected. +-- Previous Comments: [2008-03-11 12:41:02] petr at hroch dot info To your previous comment: Extension was compiled externaly using phpize. P. [2008-03-11 12:38:46] petr at hroch dot info This line oci8.c:1381: error: too many arguments to function 'OCIPing' causes the problem. I tryied to remove one argument from the OCIPing function arguments than extension compiled successfully, but I'm only guessing. Petr [2008-03-10 23:36:05] [EMAIL PROTECTED] Let me re-open this since I think I can guess what the problem is and will fix it. Note to original poster: without any information about how you were building PHP, I can only hope my guess about your problem is right. [2008-03-08 22:18:33] [EMAIL PROTECTED] Pleas report issues with the pecl version on the pecl site. [2008-03-08 12:53:48] petr at hroch dot info Description: Extension compile failed using latest cvs snapshot Actual result: -- sit:/usr/install/src/oci8-1.3.1# make /bin/sh /usr/install/src/oci8-1.3.1/libtool --mode=compile gcc -I. -I/usr/install/src/oci8-1.3.1 -DPHP_ATOM_INC -I/usr/install/src/oci8-1.3.1/include -I/usr/install/src/oci8-1.3.1/main -I/usr/install/src/oci8-1.3.1 -I/usr/local/php/include/php -I/usr/local/php/include/php/main -I/usr/local/php/include/php/TSRM -I/usr/local/php/include/php/Zend -I/usr/local/php/include/php/ext -I/usr/local/php/include/php/ext/date/lib -I/usr/local/oracle/home1/rdbms/public -I/usr/local/oracle/home1/rdbms/demo -DHAVE_CONFIG_H -g -O2 -c /usr/install/src/oci8-1.3.1/oci8.c -o oci8.lo mkdir .libs gcc -I. -I/usr/install/src/oci8-1.3.1 -DPHP_ATOM_INC -I/usr/install/src/oci8-1.3.1/include -I/usr/install/src/oci8-1.3.1/main -I/usr/install/src/oci8-1.3.1 -I/usr/local/php/include/php -I/usr/local/php/include/php/main -I/usr/local/php/include/php/TSRM -I/usr/local/php/include/php/Zend -I/usr/local/php/include/php/ext -I/usr/local/php/include/php/ext/date/lib -I/usr/local/oracle/home1/rdbms/public -I/usr/local/oracle/home1/rdbms/demo -DHAVE_CONFIG_H -g -O2 -c /usr/install/src/oci8-1.3.1/oci8.c -fPIC -DPIC -o .libs/oci8.o /usr/install/src/oci8-1.3.1/oci8.c: In function 'php_oci_do_connect_ex': /usr/install/src/oci8-1.3.1/oci8.c:1150: warning: cast from pointer to integer of different size /usr/install/src/oci8-1.3.1/oci8.c:1346: warning: cast to pointer from integer of different size /usr/install/src/oci8-1.3.1/oci8.c: In function 'php_oci_connection_ping': /usr/install/src/oci8-1.3.1/oci8.c:1381: error: too many arguments to function 'OCIPing' make: *** [oci8.lo] Error 1 -- Edit this bug report at http://bugs.php.net/?id=44372edit=1
#44411 [Com]: Broken Compatibility
ID: 44411
Comment by: hubert dot roksor at gmail dot com
Reported By: phpbugs at steve dot ipapp dot com
Status: Open
Bug Type: SimpleXML related
Operating System: ANY
PHP Version: 5.2.5
New Comment:
As per the manual chapter you quoted, the comparison operator compares
_objects_, and that's the key word here. You expect two equal XML trees
to be represented by two equal objects, and even though this expectation
is understandable, it is simply not the case. Those objects are
different. In fact, even if $sax1-value is equal to $sax1-value and
they come from the same tree, they are not identical. ($sax1-value !==
$sax1-value)
The bottom line is the comparison operator compares objects. If you
need an operator that understands the underlying data you will have to
use another mean. The solution proposed in the other bug report (compare
them as XML strings) sounds reasonable.
It would be nice to mention this quirk in the manual though, perhaps as
a new example? Comparing Elements and Elements
Previous Comments:
[2008-03-12 01:35:37] phpbugs at steve dot ipapp dot com
Description:
In PHP 5.0.x and 5.1.x two SimpleXMLElement objects were considered
equal if they represented the same data.
In PHP 5.2.x this does not seem to be the case anymore. This was
previously listed as bug 39866 [http://bugs.php.net/bug.php?id=39866],
but for some reason this was listed as bogus. In that bug it was noted
that we should look at Example 5 at http://php.net/simplexml. I'm
assuming this is Example 6 now [Comparing Elements and Attributes with
Text] , but this is incorrect as comparision will implicity cast
it to string anyway.
According to
http://www.php.net/manual/en/language.oop5.object-comparison.php:
When using the comparison operator (==), object variables are compared
in a simple manner, namely: Two object instances are equal if they have
the same attributes and values, and are instances of the same class...
On the other hand, when using the identity operator (===), object
variables are identical if and only if they refer to the same instance
of the same class.
Furthermore this backwards incompatible change is not listed in :
http://us.php.net/manual/en/migration52.incompatible.php.
Currently there is no equals method that we can call to get the
previous functionality back, and at the present moment this makes == no
longer transitive as especially since this makes == no longer
transitive as 'doc' == x1, 'doc' == x2, but x1 != x2.
I do not understand why ==, nor do I see value in, doing a strict
comparison for SimpleXMLObjects as ==, when according to the PHP Object
Comparison manual this should be ===.
Therefore I believe this is a bug.
Reproduce code:
---
$xmldoc = xmlvaluefoo/value/xml;
$sax1 = new SimpleXMLElement($xmldoc);
$sax2 = new SimpleXMLElement($xmldoc);
if($sax1 == $sax2)
{
echo TRUE;
} else
{
echo FALSE;
}
echo \n\n\n;
Expected result:
TRUE
Actual result:
--
FALSE
--
Edit this bug report at http://bugs.php.net/?id=44411edit=1
