#44913 [NEW]: Segfault when using return; in combination with nested loops and continue 2;
From: dz at bitxtender dot com Operating system: irrelevant PHP version: 5.2.6 PHP Bug Type: Reproducible crash Bug description: Segfault when using return; in combination with nested loops and continue 2; Description: The code below crashes reproducibly on different PHP versions and different OS (tried OS X, Linux, Windows) including 5.2.6 and 5.3-dev I am suspecting a problem in the bytecode generation, as the crash does not occur if a) XDebug is enabled or b) any statement is put right before the return;, like $foo = 'bar'; c) the return; is not there at all And it only happens in this foreach() / for() combination... two foreach()es, two for()s or a foreach() in a for() works just fine. Also note that on many PHP versions, no segfault will occur right away with just array(1) in the foreach - instead, warnings will pop up saying "invalid argument supplied for foreach()" for this line. Other code may then crash much later due to memory corruption. In more complex test cases, we get random memory output on screen when var_dump()ing variables, or strange undefined index warnings for variables that then, suddenly, are of "unknown type" etc. I also got heap overflow warnings etc once. In any case, something goes wrong deep inside the belly of the beast :) Can provide additional, more complex reproduce cases if needed. Obviously, the code below doesn't make much sense per se; in our "real-life" code, the continue 2; is run only when certain conditions are met. Here, the return is never reached, but still seems to be the cause of the problem. Reproduce code: --- --TEST-- continue/return/loop-related segfault test case for Bug #44913 --FILE-- --EXPECT-- hi Expected result: hi Actual result: -- "Segmentation fault" or "Bus error" -- Edit bug report at http://bugs.php.net/?id=44913&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44913&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44913&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44913&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44913&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44913&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44913&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44913&r=needscript Try newer version:http://bugs.php.net/fix.php?id=44913&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44913&r=support Expected behavior:http://bugs.php.net/fix.php?id=44913&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44913&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44913&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44913&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44913&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44913&r=dst IIS Stability:http://bugs.php.net/fix.php?id=44913&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44913&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44913&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44913&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44913&r=mysqlcfg
#44913 [Opn->Asn]: Segfault when using return; in combination with nested loops and continue 2;
ID: 44913 Updated by: [EMAIL PROTECTED] Reported By: dz at bitxtender dot com -Status: Open +Status: Assigned Bug Type: Reproducible crash Operating System: irrelevant PHP Version: 5.2.6 Assigned To: dmitry New Comment: It does not crash for me but PHP claims that array(1, 2) is not array here. [EMAIL PROTECTED] ~ % USE_ZEND_ALLOC=0 valgrind php -n crash.php ==9030== Memcheck, a memory error detector. ==9030== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. ==9030== Using LibVEX rev 1804, a library for dynamic binary translation. ==9030== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. ==9030== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation framework. ==9030== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. ==9030== For more details, rerun with: -v ==9030== ==9030== Invalid read of size 4 ==9030==at 0x844F126: zend_pzval_unlock_func (zend_execute.c:69) ==9030==by 0x8452225: _get_zval_ptr_var (zend_execute.c:172) ==9030==by 0x8467765: ZEND_FE_FETCH_SPEC_VAR_HANDLER (zend_vm_execute.h:8008) ==9030==by 0x844D36F: execute (zend_vm_execute.h:92) ==9030==by 0x844DB22: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:234) ==9030==by 0x8454339: ZEND_DO_FCALL_SPEC_CONST_HANDLER (zend_vm_execute.h:1679) ==9030==by 0x844D36F: execute (zend_vm_execute.h:92) ==9030==by 0x8424F72: zend_execute_scripts (zend.c:1134) ==9030==by 0x83BFDE9: php_execute_script (main.c:2005) ==9030==by 0x84AD23C: main (php_cli.c:1140) ==9030== Address 0x4d02e70 is 8 bytes inside a block of size 16 free'd ==9030==at 0x402265C: free (vg_replace_malloc.c:323) ==9030==by 0x840104A: _efree (zend_alloc.c:2290) ==9030==by 0x84131E8: safe_free_zval_ptr_rel (zend_execute.h:70) ==9030==by 0x8413127: _zval_ptr_dtor (zend_execute_API.c:415) ==9030==by 0x8450153: zend_switch_free (zend_execute.c:372) ==9030==by 0x84518D4: zend_brk_cont (zend_execute.c:1328) ==9030==by 0x845195D: ZEND_CONT_SPEC_CONST_HANDLER (zend_vm_execute.h:825) ==9030==by 0x844D36F: execute (zend_vm_execute.h:92) ==9030==by 0x844DB22: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:234) ==9030==by 0x8454339: ZEND_DO_FCALL_SPEC_CONST_HANDLER (zend_vm_execute.h:1679) ==9030==by 0x844D36F: execute (zend_vm_execute.h:92) ==9030==by 0x8424F72: zend_execute_scripts (zend.c:1134) ==9030== ==9030== Invalid write of size 4 ==9030==at 0x844F12F: zend_pzval_unlock_func (zend_execute.c:69) ==9030==by 0x8452225: _get_zval_ptr_var (zend_execute.c:172) ==9030==by 0x8467765: ZEND_FE_FETCH_SPEC_VAR_HANDLER (zend_vm_execute.h:8008) ==9030==by 0x844D36F: execute (zend_vm_execute.h:92) ==9030==by 0x844DB22: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:234) ==9030==by 0x8454339: ZEND_DO_FCALL_SPEC_CONST_HANDLER (zend_vm_execute.h:1679) ==9030==by 0x844D36F: execute (zend_vm_execute.h:92) ==9030==by 0x8424F72: zend_execute_scripts (zend.c:1134) ==9030==by 0x83BFDE9: php_execute_script (main.c:2005) ==9030==by 0x84AD23C: main (php_cli.c:1140) ==9030== Address 0x4d02e70 is 8 bytes inside a block of size 16 free'd ==9030==at 0x402265C: free (vg_replace_malloc.c:323) ==9030==by 0x840104A: _efree (zend_alloc.c:2290) ==9030==by 0x84131E8: safe_free_zval_ptr_rel (zend_execute.h:70) ==9030==by 0x8413127: _zval_ptr_dtor (zend_execute_API.c:415) ==9030==by 0x8450153: zend_switch_free (zend_execute.c:372) ==9030==by 0x84518D4: zend_brk_cont (zend_execute.c:1328) ==9030==by 0x845195D: ZEND_CONT_SPEC_CONST_HANDLER (zend_vm_execute.h:825) ==9030==by 0x844D36F: execute (zend_vm_execute.h:92) ==9030==by 0x844DB22: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:234) ==9030==by 0x8454339: ZEND_DO_FCALL_SPEC_CONST_HANDLER (zend_vm_execute.h:1679) ==9030==by 0x844D36F: execute (zend_vm_execute.h:92) ==9030==by 0x8424F72: zend_execute_scripts (zend.c:1134) ==9030== ==9030== Invalid read of size 4 ==9030==at 0x844F135: zend_pzval_unlock_func (zend_execute.c:69) ==9030==by 0x8452225: _get_zval_ptr_var (zend_execute.c:172) ==9030==by 0x8467765: ZEND_FE_FETCH_SPEC_VAR_HANDLER (zend_vm_execute.h:8008) ==9030==by 0x844D36F: execute (zend_vm_execute.h:92) ==9030==by 0x844DB22: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:234) ==9030==by 0x8454339: ZEND_DO_FCALL_SPEC_CONST_HANDLER (zend_vm_execute.h:1679) ==9030==by 0x844D36F: execute (zend_vm_execute.h:92) ==9030==by 0x8424F72: zend_execute_scripts (zend.c:1134) ==9030==by 0x83BFDE9: php_execute_script (main.c:2005) ==9030==by 0x84AD23C: main (php_cli.c:1140) ==9030== Address 0x4d02e70 is 8 bytes inside a block of size 16 free'd ==9030==at 0x402265C: free (vg_replace_malloc.c:323) ==9030==by 0x840104A: _efree (zend_alloc.c:2290) ==9030==by 0x84131E8: safe_free_zval_ptr_rel (zend_execute.h:70) ==9030==
#44914 [NEW]: Array index access with invalid keys on strings without consequences
From: sgalonska at studivz dot net Operating system: UNIX PHP version: 5.2.6 PHP Bug Type: Strings related Bug description: Array index access with invalid keys on strings without consequences Description: It is allowed to access a string the same way as an array. So it is obvious to imply that using numeric indexes is the only way to achieve that goal. Unfortunately access over alphanumeric keys is also possible. In that case, PHP converts them into 0. This behavior seems to be a bug since no notice or error is risen. Reproduce code: --- $string = 'abcdefghijk'; print $string[0] . PHP_EOL; print $string['foo'] . PHP_EOL; Expected result: a -- Edit bug report at http://bugs.php.net/?id=44914&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44914&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44914&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44914&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44914&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44914&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44914&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44914&r=needscript Try newer version:http://bugs.php.net/fix.php?id=44914&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44914&r=support Expected behavior:http://bugs.php.net/fix.php?id=44914&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44914&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44914&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44914&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44914&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44914&r=dst IIS Stability:http://bugs.php.net/fix.php?id=44914&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44914&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44914&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44914&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44914&r=mysqlcfg
#44913 [Asn->Csd]: Segfault when using return; in combination with nested loops and continue 2;
ID: 44913 Updated by: [EMAIL PROTECTED] Reported By: dz at bitxtender dot com -Status: Assigned +Status: Closed Bug Type: Reproducible crash Operating System: irrelevant PHP Version: 5.2.6 Assigned To: dmitry New Comment: Fixed in CVS HEAD and PHP_5_3 (but not in PHP_5_2). Previous Comments: [2008-05-05 09:10:07] [EMAIL PROTECTED] It does not crash for me but PHP claims that array(1, 2) is not array here. [EMAIL PROTECTED] ~ % USE_ZEND_ALLOC=0 valgrind php -n crash.php ==9030== Memcheck, a memory error detector. ==9030== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. ==9030== Using LibVEX rev 1804, a library for dynamic binary translation. ==9030== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. ==9030== Using valgrind-3.3.0-Debian, a dynamic binary instrumentation framework. ==9030== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. ==9030== For more details, rerun with: -v ==9030== ==9030== Invalid read of size 4 ==9030==at 0x844F126: zend_pzval_unlock_func (zend_execute.c:69) ==9030==by 0x8452225: _get_zval_ptr_var (zend_execute.c:172) ==9030==by 0x8467765: ZEND_FE_FETCH_SPEC_VAR_HANDLER (zend_vm_execute.h:8008) ==9030==by 0x844D36F: execute (zend_vm_execute.h:92) ==9030==by 0x844DB22: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:234) ==9030==by 0x8454339: ZEND_DO_FCALL_SPEC_CONST_HANDLER (zend_vm_execute.h:1679) ==9030==by 0x844D36F: execute (zend_vm_execute.h:92) ==9030==by 0x8424F72: zend_execute_scripts (zend.c:1134) ==9030==by 0x83BFDE9: php_execute_script (main.c:2005) ==9030==by 0x84AD23C: main (php_cli.c:1140) ==9030== Address 0x4d02e70 is 8 bytes inside a block of size 16 free'd ==9030==at 0x402265C: free (vg_replace_malloc.c:323) ==9030==by 0x840104A: _efree (zend_alloc.c:2290) ==9030==by 0x84131E8: safe_free_zval_ptr_rel (zend_execute.h:70) ==9030==by 0x8413127: _zval_ptr_dtor (zend_execute_API.c:415) ==9030==by 0x8450153: zend_switch_free (zend_execute.c:372) ==9030==by 0x84518D4: zend_brk_cont (zend_execute.c:1328) ==9030==by 0x845195D: ZEND_CONT_SPEC_CONST_HANDLER (zend_vm_execute.h:825) ==9030==by 0x844D36F: execute (zend_vm_execute.h:92) ==9030==by 0x844DB22: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:234) ==9030==by 0x8454339: ZEND_DO_FCALL_SPEC_CONST_HANDLER (zend_vm_execute.h:1679) ==9030==by 0x844D36F: execute (zend_vm_execute.h:92) ==9030==by 0x8424F72: zend_execute_scripts (zend.c:1134) ==9030== ==9030== Invalid write of size 4 ==9030==at 0x844F12F: zend_pzval_unlock_func (zend_execute.c:69) ==9030==by 0x8452225: _get_zval_ptr_var (zend_execute.c:172) ==9030==by 0x8467765: ZEND_FE_FETCH_SPEC_VAR_HANDLER (zend_vm_execute.h:8008) ==9030==by 0x844D36F: execute (zend_vm_execute.h:92) ==9030==by 0x844DB22: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:234) ==9030==by 0x8454339: ZEND_DO_FCALL_SPEC_CONST_HANDLER (zend_vm_execute.h:1679) ==9030==by 0x844D36F: execute (zend_vm_execute.h:92) ==9030==by 0x8424F72: zend_execute_scripts (zend.c:1134) ==9030==by 0x83BFDE9: php_execute_script (main.c:2005) ==9030==by 0x84AD23C: main (php_cli.c:1140) ==9030== Address 0x4d02e70 is 8 bytes inside a block of size 16 free'd ==9030==at 0x402265C: free (vg_replace_malloc.c:323) ==9030==by 0x840104A: _efree (zend_alloc.c:2290) ==9030==by 0x84131E8: safe_free_zval_ptr_rel (zend_execute.h:70) ==9030==by 0x8413127: _zval_ptr_dtor (zend_execute_API.c:415) ==9030==by 0x8450153: zend_switch_free (zend_execute.c:372) ==9030==by 0x84518D4: zend_brk_cont (zend_execute.c:1328) ==9030==by 0x845195D: ZEND_CONT_SPEC_CONST_HANDLER (zend_vm_execute.h:825) ==9030==by 0x844D36F: execute (zend_vm_execute.h:92) ==9030==by 0x844DB22: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:234) ==9030==by 0x8454339: ZEND_DO_FCALL_SPEC_CONST_HANDLER (zend_vm_execute.h:1679) ==9030==by 0x844D36F: execute (zend_vm_execute.h:92) ==9030==by 0x8424F72: zend_execute_scripts (zend.c:1134) ==9030== ==9030== Invalid read of size 4 ==9030==at 0x844F135: zend_pzval_unlock_func (zend_execute.c:69) ==9030==by 0x8452225: _get_zval_ptr_var (zend_execute.c:172) ==9030==by 0x8467765: ZEND_FE_FETCH_SPEC_VAR_HANDLER (zend_vm_execute.h:8008) ==9030==by 0x844D36F: execute (zend_vm_execute.h:92) ==9030==by 0x844DB22: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:234) ==9030==by 0x8454339: ZEND_DO_FCALL_SPEC_CONST_HANDLER (zend_vm_execute.h:1679) ==9030==by 0x844D36F: execute (zend_vm_execute.h:92) ==9030==by 0x8424F72: zend_execute_scripts (zend.c:1134) ==9030==by 0x83BFDE9: php_execute_script (main.c:2005) ==9030==by 0x84AD23C: main (php_cli.c:1140) ==9030== Address 0x4d02e70 is 8 bytes inside a block of size 16 free'
#44900 [Com]: OpenSSL extension fails to link with OpenSSL 0.9.6
ID: 44900
Comment by: Bjorn dot Wiberg at its dot uu dot se
Reported By: jd at cpanel dot net
Status: Assigned
Bug Type: Compile Failure
Operating System: RedHat Linux AS-2
PHP Version: 5.2.6
Assigned To: pajoye
New Comment:
Same problem on IBM AIX 5.3:
---8<---
/../
ld: 0711-317 ERROR: Undefined symbol: .EVP_MD_CTX_cleanup
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more
information.
collect2: ld returned 8 exit status
make: *** [sapi/cli/php] Error 1
--->8---
Using OpenSSL 0.9.6m from (IBM) RPM.
Best regards,
Björn
Previous Comments:
[2008-05-03 11:50:06] [EMAIL PROTECTED]
Side note: 5.3.0 will have 0.9.8g as requirement (or at the 0.9.7 if
0.9.8 is too "new").
[2008-05-03 11:48:25] [EMAIL PROTECTED]
Unless we explicitly stop to support this version, it costs nothing to
apply this patch for the person running Sarge and other conservative
OSes.
[2008-05-03 11:46:02] [EMAIL PROTECTED]
The last 0.9.6 release was more than *four* years ago - you really
should upgrade as *numerous* security fixes where made there.
[2008-05-02 23:55:58] jd at cpanel dot net
Description:
PHP 5.2.6 introduces some memory cleanup code in the OpenSSL extension.
Unfortunately, EVP_MD_CTX_cleanup() is only available with OpenSSL
0.9.7 and higher. openssl.c needs to verify EVP_MD_CTX_cleanup() is
available...
diff -Nur php-5.2.6.orig/ext/openssl/openssl.c
php-5.2.6/ext/openssl/openssl.c
--- php-5.2.6.orig/ext/openssl/openssl.c2008-04-07
05:44:03.0 -0500
+++ php-5.2.6/ext/openssl/openssl.c 2008-05-02 17:11:10.0
-0500
@@ -3522,7 +3522,9 @@
efree(sigbuf);
RETVAL_FALSE;
}
+#if OPENSSL_VERSION_NUMBER >= 0x0090700fL
EVP_MD_CTX_cleanup(&md_ctx);
+#endif
if (keyresource == -1) {
EVP_PKEY_free(pkey);
}
@@ -3562,7 +3564,9 @@
EVP_VerifyInit (&md_ctx, mdtype);
EVP_VerifyUpdate (&md_ctx, data, data_len);
err = EVP_VerifyFinal (&md_ctx, (unsigned char *)signature,
signature_len, pkey);
+#if OPENSSL_VERSION_NUMBER >= 0x0090700fL
EVP_MD_CTX_cleanup(&md_ctx);
+#endif
if (keyresource == -1) {
EVP_PKEY_free(pkey);
--
Edit this bug report at http://bugs.php.net/?id=44900&edit=1
#44915 [NEW]: ip2long
From: sascha at rizzt dot kicks-ass dot org Operating system: Linux 2.6.24.3-34.fc8 #1 PHP version: 5.2.6 PHP Bug Type: Unknown/Other Function Bug description: ip2long Description: Since quite a while i see ips like 127.255.255.255 the ips in the logfile are correct, but ip2long doesn't convert it correctly. i cannot reproduce the bug with a simple script. -- Edit bug report at http://bugs.php.net/?id=44915&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44915&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44915&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44915&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44915&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44915&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44915&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44915&r=needscript Try newer version:http://bugs.php.net/fix.php?id=44915&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44915&r=support Expected behavior:http://bugs.php.net/fix.php?id=44915&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44915&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44915&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44915&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44915&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44915&r=dst IIS Stability:http://bugs.php.net/fix.php?id=44915&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44915&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44915&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44915&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44915&r=mysqlcfg
#44915 [Opn->Fbk]: ip2long
ID: 44915 Updated by: [EMAIL PROTECTED] Reported By: sascha at rizzt dot kicks-ass dot org -Status: Open +Status: Feedback Bug Type: Unknown/Other Function Operating System: Linux 2.6.24.3-34.fc8 #1 PHP Version: 5.2.6 New Comment: Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. Previous Comments: [2008-05-05 12:06:25] sascha at rizzt dot kicks-ass dot org Description: Since quite a while i see ips like 127.255.255.255 the ips in the logfile are correct, but ip2long doesn't convert it correctly. i cannot reproduce the bug with a simple script. -- Edit this bug report at http://bugs.php.net/?id=44915&edit=1
#44917 [NEW]: Set values
From: me at mkavel dot de
Operating system: Gentoo
PHP version: 5.2.6
PHP Bug Type: SimpleXML related
Bug description: Set values
Description:
Some special German (latin1) caracters could not be set correctly.
The code produces different output between addCild and directly set of the
value in an existing child.
Reproduce code:
---
// 1
$xml->obermenue[0]->addChild("titel","");
// 2
$xml->obermenue[0]->titel="";
Expected result:
1:
Output:
2:
Output:
Actual result:
--
1:
Output:
Please look at the "<" and "&" in the first Output. It changed to "<"
and the "&" not change.
2:
Output:
This one the "<" changed to "<" too but the "&" chnaged to "&"
--
Edit bug report at http://bugs.php.net/?id=44917&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44917&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44917&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44917&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44917&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44917&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44917&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44917&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44917&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44917&r=support
Expected behavior:http://bugs.php.net/fix.php?id=44917&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44917&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44917&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44917&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44917&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44917&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44917&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44917&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44917&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44917&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44917&r=mysqlcfg
#44918 [NEW]: Application error using MSSQL
From: ceesios at gmail dot com
Operating system: Windows XP/2003
PHP version: 4.4.8
PHP Bug Type: MSSQL related
Bug description: Application error using MSSQL
Description:
I am trying to connect to a MSSQL database. Often the first few times this
failes giving an error on the server;
"The instruction at "0x0068d6ff" referenced
memory at 0x. The memory could not be "read"."
The memory adresses always change. I've tried different PHP versions,
different Apache versions and different computers but the problem always
comes back. It seems to be connected to the ammount of code/size of the
query. The more code or the larger the query the more errors I get.
Sometimes it works after a couple of refreshes but the problem always
comes back.
Reproduce code:
---
\n"
. "\n"
. "\n"
. "" . $numRows . " verkeerd" . ($numRows == 1 ? "" : "e") . "
roosteritem" . ($numRows == 1 ? "" : "s") . " gevonden " . "\n"
. "\n"
. "\n";
echo
"".
"\n".
"CursusZoeknaam\n".
"Cursus Omschrijving\n".
"Foutmelding\n".
"\n".
"\n";
while($row = mssql_fetch_array($result))
{
$roostererror=NULL;
$startdatum = strtotime($row["Startdatum"]);
$Hoofddocent = $row["HoofdDocentVnaam"].' '.$row["HoofdDocentAnaam"];
$cursusid = $row["CursusID"];
include 'schedule_error_descriptions.php';
// tekst ipv bits laten zien
IF ($row["MoederCursus"] == NULL) {$moedercursus='Ja';}
ELSE $moedercursus='Nee';
IF ($row["DatumAnnulering"] == NULL) {$geannuleerd='Nee';}
ELSE $geannuleerd='Ja';
echo
"\n".
"". $row["Zoeknaam"] . "\n".
"". $row["CursusOmschrijving"] . "\n".
"". $roostererror . "\n".
"".
"" .
'' .
'' .
"\n".
"\n";
}
//echo "\n\n";
?>
Expected result:
a table with the rows from the database and a detail button on the end.
Actual result:
--
error on the server;
"The instruction at "0x0068d6ff" referenced
memory at 0x. The memory could not be "read"."
--
Edit bug report at http://bugs.php.net/?id=44918&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44918&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44918&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44918&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44918&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44918&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44918&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44918&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44918&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44918&r=support
Expected behavior:http://bugs.php.net/fix.php?id=44918&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44918&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44918&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44918&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44918&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44918&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44918&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44918&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44918&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44918&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44918&r=mysqlcfg
#44918 [Opn->Fbk]: Application error using MSSQL
ID: 44918
Updated by: [EMAIL PROTECTED]
Reported By: ceesios at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: MSSQL related
Operating System: Windows XP/2003
PHP Version: 4.4.8
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-05-05 14:55:12] ceesios at gmail dot com
Description:
I am trying to connect to a MSSQL database. Often the first few times
this failes giving an error on the server;
"The instruction at "0x0068d6ff" referenced
memory at 0x. The memory could not be "read"."
The memory adresses always change. I've tried different PHP versions,
different Apache versions and different computers but the problem always
comes back. It seems to be connected to the ammount of code/size of the
query. The more code or the larger the query the more errors I get.
Sometimes it works after a couple of refreshes but the problem always
comes back.
Reproduce code:
---
\n"
. "\n"
. "\n"
. "" . $numRows . " verkeerd" . ($numRows == 1 ? "" : "e") . "
roosteritem" . ($numRows == 1 ? "" : "s") . " gevonden " . "\n"
. "\n"
. "\n";
echo
"".
"\n".
"CursusZoeknaam\n".
"Cursus Omschrijving\n".
"Foutmelding\n".
"\n".
"\n";
while($row = mssql_fetch_array($result))
{
$roostererror=NULL;
$startdatum = strtotime($row["Startdatum"]);
$Hoofddocent = $row["HoofdDocentVnaam"].' '.$row["HoofdDocentAnaam"];
$cursusid = $row["CursusID"];
include 'schedule_error_descriptions.php';
// tekst ipv bits laten zien
IF ($row["MoederCursus"] == NULL) {$moedercursus='Ja';}
ELSE $moedercursus='Nee';
IF ($row["DatumAnnulering"] == NULL) {$geannuleerd='Nee';}
ELSE $geannuleerd='Ja';
echo
"\n".
"". $row["Zoeknaam"] . "\n".
"". $row["CursusOmschrijving"] . "\n".
"". $roostererror . "\n".
"".
"" .
'' .
'' .
"\n".
"\n";
}
//echo "\n\n";
?>
Expected result:
a table with the rows from the database and a detail button on the end.
Actual result:
--
error on the server;
"The instruction at "0x0068d6ff" referenced
memory at 0x. The memory could not be "read"."
--
Edit this bug report at http://bugs.php.net/?id=44918&edit=1
#44918 [Fbk]: Application error using MSSQL
ID: 44918
Updated by: [EMAIL PROTECTED]
Reported By: ceesios at gmail dot com
Status: Feedback
Bug Type: MSSQL related
Operating System: Windows XP/2003
PHP Version: 4.4.8
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-05-05 15:07:28] [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-05-05 14:55:12] ceesios at gmail dot com
Description:
I am trying to connect to a MSSQL database. Often the first few times
this failes giving an error on the server;
"The instruction at "0x0068d6ff" referenced
memory at 0x. The memory could not be "read"."
The memory adresses always change. I've tried different PHP versions,
different Apache versions and different computers but the problem always
comes back. It seems to be connected to the ammount of code/size of the
query. The more code or the larger the query the more errors I get.
Sometimes it works after a couple of refreshes but the problem always
comes back.
Reproduce code:
---
\n"
. "\n"
. "\n"
. "" . $numRows . " verkeerd" . ($numRows == 1 ? "" : "e") . "
roosteritem" . ($numRows == 1 ? "" : "s") . " gevonden " . "\n"
. "\n"
. "\n";
echo
"".
"\n".
"CursusZoeknaam\n".
"Cursus Omschrijving\n".
"Foutmelding\n".
"\n".
"\n";
while($row = mssql_fetch_array($result))
{
$roostererror=NULL;
$startdatum = strtotime($row["Startdatum"]);
$Hoofddocent = $row["HoofdDocentVnaam"].' '.$row["HoofdDocentAnaam"];
$cursusid = $row["CursusID"];
include 'schedule_error_descriptions.php';
// tekst ipv bits laten zien
IF ($row["MoederCursus"] == NULL) {$moedercursus='Ja';}
ELSE $moedercursus='Nee';
IF ($row["DatumAnnulering"] == NULL) {$geannuleerd='Nee';}
ELSE $geannuleerd='Ja';
echo
"\n".
"". $row["Zoeknaam"] . "\n".
"". $row["CursusOmschrijving"] . "\n".
"". $roostererror . "\n".
"".
"" .
'' .
'' .
"\n".
"\n";
}
//echo "\n\n";
?>
Expected result:
a table with the rows from the database and a detail button on the end.
Actual result:
--
error on the server;
"The instruction at "0x0068d6ff" referenced
memory at 0x. The memory could not be "read"."
--
Edit this bug report at http://bugs.php.net/?id=44918&edit=1
#44919 [NEW]: works in command line but not in browser
From: chris at p5nettrain dot com Operating system: Fedora Core 1 PHP version: 4.4.8 PHP Bug Type: Unknown/Other Function Bug description: works in command line but not in browser Description: I am writing a script to change an interface's IP address. When I run the following script: In the command line, it works. But when I go to my web browser (either Firefox or Internet Explorer) it doesn't change the ip address - it does execute the second system command. -- Edit bug report at http://bugs.php.net/?id=44919&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44919&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44919&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44919&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44919&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44919&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44919&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44919&r=needscript Try newer version:http://bugs.php.net/fix.php?id=44919&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44919&r=support Expected behavior:http://bugs.php.net/fix.php?id=44919&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44919&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44919&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44919&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44919&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44919&r=dst IIS Stability:http://bugs.php.net/fix.php?id=44919&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44919&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44919&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44919&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44919&r=mysqlcfg
#29318 [Com]: Can't encode to HTML Entities from UTF-8
ID: 29318 Comment by: pieroconti182 at hotmail dot com Reported By: atlantisboydn at yougotmail dot com Status: No Feedback Bug Type: mbstring related Operating System: Windows XP SP1 PHP Version: 5.0.0 New Comment: yeah, i have a bug with that, when i want to do that if(htmlentities($recado) !== $recado ) but, if i use ç or ã, this code convert that to entities, and i dont want this. Previous Comments: [2004-10-16 01:00:05] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2004-10-08 16:11:44] [EMAIL PROTECTED] Hi there. (1) $a = mb_convert_encoding($a, 'UTF-8','SJIS'); (2) $a = mb_convert_encoding($a, 'HTML-ENTITIES','UTF -8'); Assuming you got correct result from example (1), you seem to be converting a sequence of SJIS-encoded data into HTML-ENTITIES while setting the source encoding to "UTF-8" in example (2), which will never produce correct result. It may be a bit too late to say, though... [2004-08-02 18:08:09] ross at golder dot org This sounds like a duplicate of : http://bugs.php.net/bug.php?id=25670 I'm still struggling with this one. [2004-07-31 12:49:04] atlantisboy at yougotmail dot com I really don't why noone consider this bug ??? [2004-07-31 12:41:17] johnmcklein at hotmail dot com I also face this problem , how to fix it ? 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/29318 -- Edit this bug report at http://bugs.php.net/?id=29318&edit=1
#43053 [Com]: Scientific notation
ID: 43053 Comment by: sweiss at stylesight dot com Reported By: owner at dragon-hearts dot net Status: Verified Bug Type: Scripting Engine problem Operating System: Centos4 PHP Version: 5CVS-2007-10-25 New Comment: You guys *have* to make changes like this more explicitly stated... It took forever to even realize the problem we were having lay with PHP and not the Javascript it was printing it out to - I definitely read the changelog and definitely did not pick up on the fact that all my numbers were going to suddenly come out in this totally useless format now. *Seriously Frustrating* - Couldn't this have just been an ini option for the people that wanted it? Previous Comments: [2008-04-18 13:07:41] rbro at hotmail dot com Thanks for your help - that definitely seems to fix the problem. I manually applied your changes since I wanted to test it against the PHP 5.2.5 source, but I'm getting consistent output now when working with floats. [2008-04-18 01:34:28] int-e at gmx dot de Here's a patch that fixes the problem. http://int-e.home.tlink.de/php/php-printf.patch There are three changes here: 1) get rid of a hack in zend_dtoa() that sometimes kept trailing zeros (which caused the inconsistent behaviour between printing 120 and 130) 2) change php_gcvt() to switch to E format for large numbers if the number wouldn't fit into precision digits. 3) update a few tests to reflect the change to the precision semantics. I believe that in each of these cases, the test was flawed. Note that a precision of 14 (the default) means that 15 digit numbers should be printed in E notation, at least that's how I read the sprintf documentation. [2008-04-15 22:37:33] rbro at hotmail dot com Your examples work correctly for me in PHP 5.2.1, so I'm not sure if the issue was caused by change you mentioned or something else, but it definitely happens for me in PHP 5.2.2 and later. [2008-04-15 20:43:16] marek dot chodor at gmail dot com on PHP Version 5.2.6RC1-pl1-gentoo and PHP 5.2.4 Fedora7 the same problem $ php -r "echo 12000;" 12000 $ php -r "echo (double)12000;" 1.2E+8 $ php -r "echo (int)(double)12000;" 12000 It could be related to this change in PHP 5.2.1: # Changed double-to-string utilities to use BSD implementation. (Dmitry, Tony) [2008-04-15 09:08:48] ali at adcworks dot com I am receiving longs via SOAP responses which represent IDs of accounts. Due to some issue with PHP and long values when we retrieve accounts using the same IDs we receive, we get other peoples' accounts back - not good! I have found the core problem and the snippet of code below shows that the correct ID of 2853622757 is transformed into the incorrect ID of 2853622752 (last number goes down 5). F0 (no formatting) F1 (sprintf) F2 (number_format) OUTPUT == F0 (no formatting) 2.854E+17 F1 (sprintf) 2853622752 F2 (number_format) 2853622752 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/43053 -- Edit this bug report at http://bugs.php.net/?id=43053&edit=1
#44919 [Opn->Bgs]: works in command line but not in browser
ID: 44919 Updated by: [EMAIL PROTECTED] Reported By: chris at p5nettrain dot com -Status: Open +Status: Bogus Bug Type: Unknown/Other Function Operating System: Fedora Core 1 PHP Version: 4.4.8 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Most likely due to permissions. Previous Comments: [2008-05-05 16:50:44] chris at p5nettrain dot com Description: I am writing a script to change an interface's IP address. When I run the following script: In the command line, it works. But when I go to my web browser (either Firefox or Internet Explorer) it doesn't change the ip address - it does execute the second system command. -- Edit this bug report at http://bugs.php.net/?id=44919&edit=1
#43896 [Com]: htmlspecialchars returns empty string on invalid unicode sequence
ID: 43896 Comment by: heurika at gmail dot com Reported By: arnaud dot lb at gmail dot com Status: Open Bug Type: Strings related Operating System: * PHP Version: 5.2CVS, 5.3CVS (2008-03-25) New Comment: Hi, I've got the same Bug, posted on #43740. Please fix it. Thanks! Previous Comments: [2008-02-17 13:25:22] andreas dot ravnestad at gmail dot com This seems to be breaking PEAR::Text_Wiki completely when using UTF-8: http://pear.php.net/bugs/bug.php?id=13136 [2008-01-24 20:51:11] tallyce at gmail dot com See also bugs 43294 and 43549 which seem to be the same thing. This is really starting to bite now. Please can this be fixed, or suggest how we can reliably process incoming user data in UTF8 given this behaviour change! [2008-01-24 12:29:58] arnaud dot lb at gmail dot com I made a patch for this bug: http://s3.amazonaws.com/arnaud.lb/php_htmlentities_utf.patch The internal get_next_char() function returns a status of FAILURE when it encounters a invalid or incomplete sequence, which causes the htmlspecialchars and htmlentities functions to return an empty string. This patch modify the behavior of these functions to skip invalid sequences, without discarding the whole string. This involves a very few changes and makes the behavior of theses functions more consistent with previous PHP versions. It also adds a few tests to htmlentities-utf.phpt. [2008-01-20 02:12:01] arnaud dot lb at gmail dot com Description: htmlspecialchars/htmlentities returns an empty string when the input contains an invalid unicode sequence. I think these functions should just skip the invalid sequences or encode them byte by byte (e.g. 0xE9 => é), instead of discarding the whole string. Sometimes you have to display arbitrary strings of unknow encoding. So you make them more safe using htmlspecialchars($string, ENT_COMPAT, "site_encoding, utf-8 in my case"), but if there is at least one invalid sequence in the string, it returns an empty string :/ Reproduce code: --- $string = "Voil\xE0"; // "Voilà", in ISO-8859-15 var_dump(htmlspecialchars($string, ENT_COMPAT, "utf-8")); Expected result: string(4) "Voil" OR string(10) "Voilà" Actual result: -- string(0) "" -- Edit this bug report at http://bugs.php.net/?id=43896&edit=1
#44767 [Com]: Incorrect handling of a closing # to # based comments
ID: 44767
Comment by: whitewolf24 at hotmail dot com
Reported By: ikickdogsforfun at hotmail dot com
Status: Open
Bug Type: Scripting Engine problem
Operating System: Gentoo Linux
PHP Version: 5.2.6RC5
New Comment:
no, # is a ONE line comment. the end of the line ended the comment.
as for the error. you should get them as that code would break anyway.
your lacking ; on the end of lines. {they are commented out}
nothing on the line after the first # is read by the parser.
the problem your having is that your ending your code before it's
closed line three is ?> and the interpreter is seeing this and asking
you about the messed up syntax
these should be the two errors you are getting
Warning: Unexpected character in input: '\' (ASCII=92) state=1 in file
on line 2
Parse error: syntax error, unexpected ';' in file on line 3
done believe me? try this line which is a code complete and doesn't
error
if you were right about your logic then you should get this works
else if I'm correct you will just get this
Previous Comments:
[2008-05-02 13:27:13] ikickdogsforfun at hotmail dot com
In which case the comment is handled incorrectly if a second # appears,
note the code above which produces 2 errors. One of the errors refers to
a third line, even though there is only code on line. This suggests that
the interpretor has closed the comment and is attempting to handle the
rest of the code after the second # by treating it as a new line.
[2008-04-29 23:28:07] whitewolf24 at hotmail dot com
um, last I checked and have read in the manual
# comments to the end of the line OR the end of the php block, which
ever happens first. not to another #
[2008-04-17 20:49:53] ikickdogsforfun at hotmail dot com
Description:
A # comment can be closed by a second # causing PHP to act rather
oddly. Any errors that occur on the same line but after the closing #
are reported as an error on the next line, however if there are no
errors anything after the second # is ignored and not processed as if it
was a comment. I think based on this, there needs to be some concistency
about what happens when a second # is encountered. Are these intended to
be embedded comments which can be be closed? Or should everything being
ignored after the first # untill a new line character is encountered?
Reproduce code:
---
This produces 2 errors, one on line 2, one on line 3, though they are
both about line 3:
This only echos out 'some':
Expected result:
I would expect to see 'some text' echoed out, as I was under the
impression these kinds of comments were imbedded.
Actual result:
--
See the code section
--
Edit this bug report at http://bugs.php.net/?id=44767&edit=1
#44920 [NEW]: "vsprintf_variation8.phpt" from "make test" depends on precision
From: twm at twmacinta dot com Operating system: Red Hat Enterprise Linux ES 3 PHP version: 5.2.6 PHP Bug Type: Unknown/Other Function Bug description: "vsprintf_variation8.phpt" from "make test" depends on precision Description: After building PHP 5.2.6 on RHEL3, I ran "make test" to test the new build, and one of the tests that failed was "vsprintf_variation8.phpt". I inspected the test's output, compared it to what was expected, tracked down the problem, and came up with a potential fix for it. The problem appears to be that the expected output of the test is based on the default "precision" configuration setting of 14, but my "php.ini" file has it set to 12. This looks like it is the same problem that occurred with the "make test" script "ext/json/tests/bug41567.phpt", which was fixed in revision "1.1.2.5". The fix was simply to specify the precision in an INI section. When I apply this same fix to "vsprintf_variation8.phpt", the test then passes. Here's what I added: --INI-- precision=14 I had copied the file named "php.ini-dist" which came with the PHP source distribution to "/etc/php.ini", without modification. It sets the precision to 12. I looked at the CVS history for the test "vsprintf_variation8.phpt" and it appears to be fixed in PHP 5.3 in the same way I suggested above. I think that fix just needs to be applied to PHP 5.2 as well. Reproduce code: --- 1) Copy "php.ini-dist", which comes with PHP, to "/etc/php.ini" 2) Run the test that comes with PHP: "ext/standard/tests/strings/vsprintf_variation8.phpt" Expected result: Number of tests :1 1 Tests skipped :0 ( 0.0%) Tests warned:0 ( 0.0%) ( 0.0%) Tests failed:0 ( 0.0%) ( 0.0%) Tests passed:1 (100.0%) (100.0%) Actual result: -- Number of tests :1 1 Tests skipped :0 ( 0.0%) Tests warned:0 ( 0.0%) ( 0.0%) Tests failed:1 (100.0%) (100.0%) Tests passed:0 ( 0.0%) ( 0.0%) -- Edit bug report at http://bugs.php.net/?id=44920&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44920&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44920&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44920&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44920&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44920&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44920&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44920&r=needscript Try newer version:http://bugs.php.net/fix.php?id=44920&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44920&r=support Expected behavior:http://bugs.php.net/fix.php?id=44920&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44920&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44920&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44920&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44920&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44920&r=dst IIS Stability:http://bugs.php.net/fix.php?id=44920&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44920&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44920&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44920&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44920&r=mysqlcfg
#44798 [Opn->Csd]: Memory leak assigning value to attribute (Fixed in PHP_5_3 branch!)
ID: 44798
Updated by: [EMAIL PROTECTED]
Reported By: aldo at armiento dot com
-Status: Open
+Status: Closed
Bug Type: SimpleXML related
Operating System: *
PHP Version: 5.2CVS-2008-04-22
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2008-04-22 23:38:44] aldo at armiento dot com
Yeah, this "bug" (and other changes to simplexml.c) is fixed in PHP 5.3
and PHP 6 but not in PHP 5.2 series (for example in php-5.2.6RC5).
By the way this problem produces a "memory leak".
[2008-04-22 23:23:30] crrodriguez at suse dot de
The "leak" ( which is not really a memory leak) is already fixed in
PHP_5_3.
[2008-04-22 22:25:06] aldo at armiento dot com
This patch to php-5.2.5 sources in ext/simplexml/simplexml.c solve the
problem.
The problem is also present in php5.2-200804222030 snap
--- simplexml.c.orig2007-07-31 17:40:49.0 +0200
+++ simplexml.c 2008-04-23 00:16:00.276147006 +0200
@@ -702,11 +702,13 @@
convert_to_string(member);
name = Z_STRVAL_P(member);
node = sxe_get_element_by_name(sxe, node, &name, &type
TSRMLS_CC);
- if (!node) {
- sxe_prop_dim_write(object, member, NULL, 1, 0, &node
TSRMLS_CC);
- type = SXE_ITER_NONE;
- name = NULL;
+ if (node) {
+ return NULL;
}
+ sxe_prop_dim_write(object, member, NULL, 1, 0, &node
TSRMLS_CC);
+ type = SXE_ITER_NONE;
+ name = NULL;
+
MAKE_STD_ZVAL(return_value);
_node_as_zval(sxe, node, return_value, type, name, sxe-
>iter.nsprefix, sxe->iter.isprefix TSRMLS_CC);
[2008-04-22 11:29:07] aldo at armiento dot com
Description:
Assigning any value to a SimpleXML attribute produces a memory leak.
Reproduce code:
---
');
while(true) {
$xml->test['attribute'] = 'value';
}
echo $xml->asXML();
?>
Expected result:
Actual result:
--
Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to
allocate 40 bytes) in /tmp/test_simplexml.php on line 5
--
Edit this bug report at http://bugs.php.net/?id=44798&edit=1
#44866 [Opn->Bgs]: curl CURLOPT_INFILE leaks handle reference
ID: 44866 Updated by: [EMAIL PROTECTED] Reported By: david at acz dot org -Status: Open +Status: Bogus Bug Type: cURL related Operating System: SLES 10 x86_64 PHP Version: 5.2.5 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php The file will be closed at the end of the request. Previous Comments: [2008-04-30 01:05:03] david at acz dot org Description: File handles are normally closed automatically when the reference count hits zero. For example, if you fopen() something in a function and only assign it to a local variable, the file is closed when the function returns. CURLOPT_INFILE breaks this behavior. Presumably, the curl resource destructor does not decrement the reference count for the file handle. Reproduce code: --- Expected result: bool(true) bool(true) bool(true) Actual result: -- bool(true) bool(true) bool(false) -- Edit this bug report at http://bugs.php.net/?id=44866&edit=1
#44920 [Opn->Csd]: "vsprintf_variation8.phpt" from "make test" depends on precision
ID: 44920 Updated by: [EMAIL PROTECTED] Reported By: twm at twmacinta dot com -Status: Open +Status: Closed Bug Type: Unknown/Other Function Operating System: Red Hat Enterprise Linux ES 3 PHP Version: 5.2.6 New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2008-05-05 21:46:22] twm at twmacinta dot com Description: After building PHP 5.2.6 on RHEL3, I ran "make test" to test the new build, and one of the tests that failed was "vsprintf_variation8.phpt". I inspected the test's output, compared it to what was expected, tracked down the problem, and came up with a potential fix for it. The problem appears to be that the expected output of the test is based on the default "precision" configuration setting of 14, but my "php.ini" file has it set to 12. This looks like it is the same problem that occurred with the "make test" script "ext/json/tests/bug41567.phpt", which was fixed in revision "1.1.2.5". The fix was simply to specify the precision in an INI section. When I apply this same fix to "vsprintf_variation8.phpt", the test then passes. Here's what I added: --INI-- precision=14 I had copied the file named "php.ini-dist" which came with the PHP source distribution to "/etc/php.ini", without modification. It sets the precision to 12. I looked at the CVS history for the test "vsprintf_variation8.phpt" and it appears to be fixed in PHP 5.3 in the same way I suggested above. I think that fix just needs to be applied to PHP 5.2 as well. Reproduce code: --- 1) Copy "php.ini-dist", which comes with PHP, to "/etc/php.ini" 2) Run the test that comes with PHP: "ext/standard/tests/strings/vsprintf_variation8.phpt" Expected result: Number of tests :1 1 Tests skipped :0 ( 0.0%) Tests warned:0 ( 0.0%) ( 0.0%) Tests failed:0 ( 0.0%) ( 0.0%) Tests passed:1 (100.0%) (100.0%) Actual result: -- Number of tests :1 1 Tests skipped :0 ( 0.0%) Tests warned:0 ( 0.0%) ( 0.0%) Tests failed:1 (100.0%) (100.0%) Tests passed:0 ( 0.0%) ( 0.0%) -- Edit this bug report at http://bugs.php.net/?id=44920&edit=1
#44922 [NEW]: After update from 5.2.5 to 5.2.6 postgrest doesn't work
From: gabriel dot vasquez at gmail dot com Operating system: Windows XP SP2 PHP version: 5.2.6 PHP Bug Type: Reproducible crash Bug description: After update from 5.2.5 to 5.2.6 postgrest doesn't work Description: After update from PHP version 5.25 to 5.2.6 my system didn't work, i get a message [Mon May 05 21:53:31 2008] [error] [client 189.26.101.57] PHP Fatal error: Call to undefined function pg_connect() in C:\\apache\\Laboratorio\\lab\\conectadb.php on line 8 I started to digg and i've found that the newer version of php_pgsql.dll has 96kb, and the older has 164kb. I've updated using the instaler for windows 32bit, an MSI file that i've downloaded from PHP.net, actually i'm using Windows XP SP2 all updated.Link: http://br.php.net/distributions/php-5.2.6-win32-installer.msi I fixed the problem downgrading the php_pg_sql.dll to the one contained in the version 5.25. I have both DLL if someone need it. Sorry for my poor english. Gabriel - Londrina - Parana - Brazil. -- Edit bug report at http://bugs.php.net/?id=44922&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44922&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44922&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44922&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44922&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44922&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44922&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44922&r=needscript Try newer version:http://bugs.php.net/fix.php?id=44922&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44922&r=support Expected behavior:http://bugs.php.net/fix.php?id=44922&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44922&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44922&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44922&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44922&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44922&r=dst IIS Stability:http://bugs.php.net/fix.php?id=44922&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44922&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44922&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44922&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44922&r=mysqlcfg
#44914 [Opn->Bgs]: Array index access with invalid keys on strings without consequences
ID: 44914 Updated by: [EMAIL PROTECTED] Reported By: sgalonska at studivz dot net -Status: Open +Status: Bogus Bug Type: Strings related Operating System: UNIX PHP Version: 5.2.6 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Previous Comments: [2008-05-05 10:52:56] sgalonska at studivz dot net Description: It is allowed to access a string the same way as an array. So it is obvious to imply that using numeric indexes is the only way to achieve that goal. Unfortunately access over alphanumeric keys is also possible. In that case, PHP converts them into 0. This behavior seems to be a bug since no notice or error is risen. Reproduce code: --- $string = 'abcdefghijk'; print $string[0] . PHP_EOL; print $string['foo'] . PHP_EOL; Expected result: a -- Edit this bug report at http://bugs.php.net/?id=44914&edit=1
#44923 [NEW]: ereg works differently in PHP 6.0 unicode.semantics=on
From: tokul at users dot sourceforge dot net
Operating system: Linux Debian Etch
PHP version: 6CVS-2008-05-06 (snap)
PHP Bug Type: *Regular Expressions
Bug description: ereg works differently in PHP 6.0 unicode.semantics=on
Description:
expressions that work in older versions fail on PHP6 unicode.semantics=on
Compared 5.2-dev, 5.3-dev and 6.0-dev snapshots
Reproduce code:
---
$line = "* 469 EXISTS\r\n";
if (ereg("[^ ]+ +([^ ]+) +EXISTS", $line, $match)) {
var_dump($match[1]);
} else {
var_dump(false);
}
$line = "* 469 FETCH (UID 508 BODY[1]<0> {154}\r\n";
if (ereg('\\{([^\\}]*)\\}', $line, $match)) {
var_dump($match[1]);
} else {
var_dump(false);
}
Expected result:
string(3) "469"
string(3) "154"
Actual result:
--
bool(false)
Warning: ereg(): REG_BADRPT in
/home/tomas/testbeds/test/php60/bin/ereg.php on line 10
bool(false)
--
Edit bug report at http://bugs.php.net/?id=44923&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=44923&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=44923&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=44923&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=44923&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=44923&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=44923&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=44923&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=44923&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=44923&r=support
Expected behavior:http://bugs.php.net/fix.php?id=44923&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=44923&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=44923&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=44923&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44923&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=44923&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=44923&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=44923&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=44923&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=44923&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=44923&r=mysqlcfg
#44924 [NEW]: sendmail path detected at configure time is ignored.
From: fegert at belwue dot de Operating system: Solaris PHP version: 5.2.6 PHP Bug Type: *Mail Related Bug description: sendmail path detected at configure time is ignored. Description: Starting with php-5.2.6 the PHP_PROG_SENDMAIL detected at configure time isn't picked up any more as a default value for DEFAULT_SENDMAIL_PATH. This breaks the mail() function on systems where DEFAULT_SENDMAIL_PATH != /usr/sbin/sendmail (e.g. Solaris with /usr/lib/sendmail) and sendmail_path isn't explicitly set in php.ini. The following patch restores the behavior known up to php-5.2.5: --- main/main.c.origMon May 5 16:44:56 2008 +++ main/main.c Mon May 5 16:47:06 2008 @@ -355,6 +355,8 @@ /* Windows and Netware use the internal mail */ #if defined(PHP_WIN32) || defined(NETWARE) # define DEFAULT_SENDMAIL_PATH NULL +#elif defined(PHP_PROG_SENDMAIL) +# define DEFAULT_SENDMAIL_PATH PHP_PROG_SENDMAIL " -t -i " #else # define DEFAULT_SENDMAIL_PATH "/usr/sbin/sendmail -t -i" #endif Is there a specific reason why the two lines have been removed? -- Edit bug report at http://bugs.php.net/?id=44924&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44924&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44924&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44924&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44924&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44924&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44924&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44924&r=needscript Try newer version:http://bugs.php.net/fix.php?id=44924&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44924&r=support Expected behavior:http://bugs.php.net/fix.php?id=44924&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44924&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44924&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44924&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44924&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44924&r=dst IIS Stability:http://bugs.php.net/fix.php?id=44924&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44924&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44924&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44924&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44924&r=mysqlcfg
