#44102 [Fbk->Opn]: Problem with compiling SQL Relay & PHP
ID: 44102 User updated by: admin at relax-info dot com Reported By: admin at relax-info dot com -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: MAC OS X Leopard 10.5.2 -PHP Version: 5.2.5 +PHP Version: 5.2.6RC3-dev New Comment: Thank you for answer! I was successfully recompiled PHP5 (with --enable-static) to lastets (PHP Version 5.2.6RC3-dev). Then I run search for "libphp*"... and I see result: - libphp5.module.in - libphp5.so - libphp5.bundle But I do not found libphp.dylib or libphp5.dylib or libphp.a or libphp5.a. Ok... I run compile SQL Relay now: _console errors_ ... ld: library not found for -lphp collect2: ld returned 1 exit status make[4]: *** [libsql_relay.la] Error 1 Hmm, then I copy libphp5.so to /usr/lib/libphp.a and try to compile SQLRelay: ... _console error_ ... ld: warning in /usr/lib/libphp.a, file is not of required architecture Undefined symbols: "_convert_to_double", referenced from: What now? Previous Comments: [2008-03-11 22:28:05] [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-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=44102&edit=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 = "foo"; $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=44411&edit=1
#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=44372&edit=1
#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 is working 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=44413&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44413&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44413&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44413&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44413&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44413&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44413&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44413&r=needscript Try newer version:http://bugs.php.net/fix.php?id=44413&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44413&r=support Expected behavior:http://bugs.php.net/fix.php?id=44413&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44413&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44413&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44413&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44413&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44413&r=dst IIS Stability:http://bugs.php.net/fix.php?id=44413&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44413&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44413&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44413&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44413&r=mysqlcfg
#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: --- 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=44412&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44412&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44412&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44412&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44412&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44412&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44412&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44412&r=needscript Try newer version:http://bugs.php.net/fix.php?id=44412&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44412&r=support Expected behavior:http://bugs.php.net/fix.php?id=44412&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44412&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44412&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44412&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44412&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44412&r=dst IIS Stability:http://bugs.php.net/fix.php?id=44412&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44412&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44412&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44412&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44412&r=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: asd"; 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 asdhttp://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: --- asd"; output_add_rewrite_var('a', 'b'); echo $string; ob_flush(); ob_end_clean(); Expected result: asd Actual result: -- asdhttp://bugs.php.net/?id=44394&edit=1
#44408 [Fbk->Opn]: make works, 'make test' core dumps
ID: 44408 User updated by: charlesg at unixrealm dot com Reported By: charlesg at unixrealm dot com -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: Solaris 10 PHP Version: 5.2.5 New Comment: I ran the CVS snapshot and it produced a report. I will email to [EMAIL PROTECTED] Is there a way to attach it to the ticket? Previous Comments: [2008-03-11 21:30:44] [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-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, retva
#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 = "foo"; $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=44411&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44411&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44411&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44411&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44411&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44411&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44411&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44411&r=needscript Try newer version:http://bugs.php.net/fix.php?id=44411&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44411&r=support Expected behavior:http://bugs.php.net/fix.php?id=44411&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44411&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44411&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44411&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44411&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44411&r=dst IIS Stability:http://bugs.php.net/fix.php?id=44411&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44411&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44411&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44411&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44411&r=mysqlcfg
#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: 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=44273&edit=1
#44138 [Fbk->Opn]: zlib.compression causes blank screens
ID: 44138 User updated by: owner at dragon-hearts dot net Reported By: owner at dragon-hearts dot net -Status: Feedback +Status: Open Bug Type: Zlib Related Operating System: CentOs 4 PHP Version: 5.2.5 New Comment: I have read the instructions What I did Enabled zlib.compression What happens zlib.compression is enabled - sometimes pages come up blank What should happen Pages should load normally If you rummage through the bug database there appear to have been bugs similar reported for previous PHP versions which haven't been fixed and ignored. Previous Comments: [2008-03-11 22:39:49] [EMAIL PROTECTED] PLEASE read the instructions found at http://bugs.php.net/how-to-report.php and provide the basic information needed. [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=44138&edit=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=44138&edit=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: asd"; 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 asdhttp://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: --- asd"; output_add_rewrite_var('a', 'b'); echo $string; ob_flush(); ob_end_clean(); Expected result: asd Actual result: -- asdhttp://bugs.php.net/?id=44394&edit=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=44102&edit=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: DocumentRoot /var/www/php1 ServerName php1.net DocumentRoot /var/www/php2 ServerName php2.net 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--- 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=44237&edit=1
#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 1>&5 /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=44249&edit=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/Lin
#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: 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=44273&edit=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: 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 'public: '.$a['public']; print 'private: '.$a["\0test\0private"]; print 'protected: '.$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=44273&edit=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=44293&edit=1
#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: --- \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 ContentHTTP/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 It works! 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) -- Edit this bug report at http://bugs.php.net/?id=44335&edit=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)
#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=44343&edit=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 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=44349&edit=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=44375&edit=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: --- asd"; output_add_rewrite_var('a', 'b'); echo $string; ob_flush(); ob_end_clean(); Expected result: asd Actual result: -- asdhttp://bugs.php.net/?id=44394&edit=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: --- 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=44398&edit=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: --- 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=44402&edit=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 user&company_name=ABC Output after including the 'require' statement: %20reply=valid user&company_name=ABC Reproduce code: --- And the sample code for the required file userpass.php: Expected result: reply=valid user&company_name=ABC Actual result: -- %20reply=valid user&company_name=ABC -- Edit this bug report at http://bugs.php.net/?id=44406&edit=1
#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 user&company_name=ABC Output after including the 'require' statement: %20reply=valid user&company_name=ABC Reproduce code: --- And the sample code for the required file userpass.php: Expected result: reply=valid user&company_name=ABC Actual result: -- %20reply=valid user&company_name=ABC -- Edit this bug report at http://bugs.php.net/?id=44406&edit=1
#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
#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=44410&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44410&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44410&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44410&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44410&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44410&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44410&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44410&r=needscript Try newer version:http://bugs.php.net/fix.php?id=44410&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44410&r=support Expected behavior:http://bugs.php.net/fix.php?id=44410&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44410&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44410&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44410&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44410&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44410&r=dst IIS Stability:http://bugs.php.net/fix.php?id=44410&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44410&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44410&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44410&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44410&r=mysqlcfg
#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=44409&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44409&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44409&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44409&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44409&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44409&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44409&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44409&r=needscript Try newer version:http://bugs.php.net/fix.php?id=44409&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44409&r=support Expected behavior:http://bugs.php.net/fix.php?id=44409&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44409&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44409&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44409&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44409&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44409&r=dst IIS Stability:http://bugs.php.net/fix.php?id=44409&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44409&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44409&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44409&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44409&r=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=44408&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44408&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44408&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): htt
#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=44407&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44407&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44407&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44407&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44407&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44407&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44407&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44407&r=needscript Try newer version:http://bugs.php.net/fix.php?id=44407&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44407&r=support Expected behavior:http://bugs.php.net/fix.php?id=44407&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44407&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44407&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44407&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44407&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44407&r=dst IIS Stability:http://bugs.php.net/fix.php?id=44407&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44407&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44407&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44407&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44407&r=mysqlcfg
#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: --- 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=44402&edit=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=44372&edit=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=44372&edit=1
#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: --- 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=44402&edit=1
#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 user&company_name=ABC Output after including the 'require' statement: %20reply=valid user&company_name=ABC Reproduce code: --- And the sample code for the required file userpass.php: Expected result: reply=valid user&company_name=ABC Actual result: -- %20reply=valid user&company_name=ABC -- Edit bug report at http://bugs.php.net/?id=44406&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44406&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44406&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44406&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44406&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44406&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44406&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44406&r=needscript Try newer version:http://bugs.php.net/fix.php?id=44406&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44406&r=support Expected behavior:http://bugs.php.net/fix.php?id=44406&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44406&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44406&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44406&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44406&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44406&r=dst IIS Stability:http://bugs.php.net/fix.php?id=44406&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44406&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44406&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44406&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44406&r=mysqlcfg
#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: -- Edit this bug report at http://bugs.php.net/?id=44405&edit=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: -- Edit bug report at http://bugs.php.net/?id=44405&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44405&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44405&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44405&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44405&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44405&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44405&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44405&r=needscript Try newer version:http://bugs.php.net/fix.php?id=44405&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44405&r=support Expected behavior:http://bugs.php.net/fix.php?id=44405&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44405&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44405&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44405&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44405&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44405&r=dst IIS Stability:http://bugs.php.net/fix.php?id=44405&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44405&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44405&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44405&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44405&r=mysqlcfg
#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 my
#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