#49269 [Asn-Csd]: Ternary operator fails on Iterator object when used inside foreach declaration
ID: 49269 Updated by: col...@php.net Reported By: president at basnetworks dot net -Status: Assigned +Status: Closed Bug Type: Class/Object related Operating System: All PHP Version: 5.3.0 Assigned To: colder New Comment: This bug has been fixed in SVN. 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: [2009-08-17 07:41:22] s...@php.net Automatic comment from SVN on behalf of dmitry Revision: http://svn.php.net/viewvc/?view=revisionrevision=287398 Log: Fixed bug #49269 (Ternary operator fails on Iterator object when used inside foreach declaration). (Etienne, Dmitry) [2009-08-17 07:40:44] s...@php.net Automatic comment from SVN on behalf of dmitry Revision: http://svn.php.net/viewvc/?view=revisionrevision=287397 Log: Fixed bug #49269 (Ternary operator fails on Iterator object when used inside foreach declaration). (Etienne, Dmitry) [2009-08-17 07:40:19] s...@php.net Automatic comment from SVN on behalf of dmitry Revision: http://svn.php.net/viewvc/?view=revisionrevision=287396 Log: Fixed bug #49269 (Ternary operator fails on Iterator object when used inside foreach declaration). (Etienne, Dmitry) [2009-08-17 00:49:28] col...@php.net http://patches.colder.ch/Zend/bug49269.patch?markup This should fix it, and passes all the Zend tests, but as it may affect some untested edge cases out there, further checking is required. [2009-08-16 17:21:46] president at basnetworks dot net sjoerd-php at linuxonly dot nl, Your code sample is much clearer, and seems to narrow it down to the ternary operator mis-behaving. Thanks for the added clarification, I will update the report. You should also vote that you reproduced the bug above. 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/49269 -- Edit this bug report at http://bugs.php.net/?id=49269edit=1
#39492 [Com]: log_errors do not use error_append_string directive
ID: 39492 Comment by: brad dot mcnay at webarena dot com dot au Reported By: frederic dot linot at free dot fr Status: Open Bug Type: Feature/Change Request Operating System: mandriva 2006 PHP Version: 5.2.0 New Comment: I am also having this problem. The error_prepend_string shows when the error is displayed, but not in the log file. Any word on when this feature will be available? Previous Comments: [2009-05-22 16:17:28] temagardon at gmail dot com Good morning. When we are unhurried and wise, we perceive that only great and worthy things have any permanent and absolute existence, that petty fears and petty pleasures are but the shadow of the reality. Help me! Please help find sites for: I am taking a low dose aspirin, plavix, vytorin, diovan and synthroid.. I found only this - a href=http://turbo-tax.biz;turbo tax/a. In the early s, my doctor switched me over to synthroid. cytomel is not a steroid, but more a of a cutting aid. Thanks ;-). Jacqueline from Barbuda. [2009-05-15 11:52:41] julya2 at link dot net Very interesting and professional site. I am from Malawi and also now'm speaking English, please tell me right I wrote the following sentence: Synthroid is the most commonly prescribed of all the thyroid supplements. Best regards :P, Sefton. [2006-11-13 09:38:49] tony2...@php.net Reclassified as feature request. [2006-11-13 09:34:57] frederic dot linot at free dot fr Reproduce code was not complete, sorry.. (last line was omitted) Here is : error_reporting(E_ALL) ; ini_set('error_log', 'errors.txt') ; ini_set('html_errors', false) ; ini_set('error_append_string', -- .$_SERVER['REQUEST_URI']) ; ini_set('log_errors', true) ; ini_set('display_errors', true) ; trigger_error(Show me the error_append_string please !) ; [2006-11-13 09:31:56] frederic dot linot at free dot fr Description: error_append_string directive not used when error is logged in a file. Just used when error is displayed on screen. Reproduce code: --- error_reporting(E_ALL) ; ini_set('error_log', 'errors.txt') ; ini_set('html_errors', false) ; ini_set('error_append_string', -- .$_SERVER['REQUEST_URI']) ; ini_set('log_errors', true) ; ini_set('display_errors', true) ; Expected result: in errors.txt file : Notice: Show me the error_append_string please ! in /home/fred/www/EasyZik-2006-10-29/test.php on line 9 -- /test.php on screen : Notice: Show me the error_append_string please ! in /home/fred/www/EasyZik-2006-10-29/test.php on line 9 -- /test.php Actual result: -- in errors.txt file : Notice: Show me the error_append_string please ! in /home/fred/www/EasyZik-2006-10-29/test.php on line 9 on screen : Notice: Show me the error_append_string please ! in /home/fred/www/EasyZik-2006-10-29/test.php on line 9 -- /test.php -- Edit this bug report at http://bugs.php.net/?id=39492edit=1
#49275 [NEW]: Error pointing to http://php.net/main
From: michaelwalser at gmx dot net Operating system: Debian Lenny PHP version: 5.3.0 PHP Bug Type: Session related Bug description: Error pointing to http://php.net/main Description: Hi, this code says more than 1000 words ;) Reproduce code: --- ?php session_start(); if(!isset($_SESSION['xml'])) { $xml = simplexml_load_string('?xml version=1.0 encoding=UTF-8? blah/blah'); $_SESSION['xml'] = $xml; echo Session variable set... Please hit F5; } else { $wtf = $_SESSION['xml']; if($wtf) echo 'lol'; // This triggers the error } ? Actual result: -- Warning: session_start() [function.session-start]: Node no longer exists in /var/www/phperr.php on line 2 Warning: session_start() [function.session-start]: Cannot send session cache limiter - headers already sent (output started at /var/www/phperr.php:2) in /var/www/phperr.php on line 2 Warning: main() [function.main]: Node no longer exists in /var/www/phperr.php on line 14 Warning: Unknown: Node no longer exists in Unknown on line 0 -- Edit bug report at http://bugs.php.net/?id=49275edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49275r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49275r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49275r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49275r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49275r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49275r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49275r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49275r=needscript Try newer version: http://bugs.php.net/fix.php?id=49275r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49275r=support Expected behavior: http://bugs.php.net/fix.php?id=49275r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49275r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49275r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49275r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49275r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49275r=dst IIS Stability: http://bugs.php.net/fix.php?id=49275r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49275r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49275r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49275r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49275r=mysqlcfg
#48664 [NoF-Asn]: crypt truncating salt values
ID: 48664 Updated by: paj...@php.net Reported By: patrickdk at patrickdk dot com -Status: No Feedback +Status: Assigned Bug Type: Strings related Operating System: linux 2.6.x PHP Version: 5.2.10 Assigned To: pajoye Previous Comments: [2009-07-03 01:00:00] 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. [2009-06-25 21:12:00] paj...@php.net Yes, it can be a solution. We can also simply implement the missing algo in php and always use them, for the users benefits (portability). [2009-06-25 03:26:18] patrickdk at patrickdk dot com What I would like to see is this: We can use the new php builtin crypt function for hashs it can understand, like des, md5, and blowfish (I think it does md5) For hashs it doesn't understand, by matching the the has type in the supplied salt, if it start with $ and follows a type unknown, pass it off to the system crypt function (or crypt_r). If one doesn't exist (windows) then it can just fail. Then it wouldn't matter if new crypt hashs come into being and php can't handle them internally, as long as the system libs can. [2009-06-25 02:16:13] patrickdk at patrickdk dot com Ok, I tried php-5.3.0RC4 on ubuntu 8.04 It didn't work at first, and I found out it's cause it didn't detect crypt_r, so php used it's internal routines, so that was to be expected. It seems configure doesn't test for crypt_r in libcrypt So I overrode that, and it worked fine (same results though). salt is truncated cause php only detects crypt_md5, and truncates salts to 12bytes. If I hack the salt_max then everything works as expected. same results using rhel5 [2009-06-24 18:48:36] paj...@php.net Debian/Ubuntu should really stop to do stupid things with PHP. Which version do you use (of ubuntu)? And have you tried using 5.3.0RC4? If not, please try. 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/48664 -- Edit this bug report at http://bugs.php.net/?id=48664edit=1
#46015 [NoF-Csd]: Build fails with system gd
ID: 46015 Updated by: paj...@php.net Reported By: Fedora at FamilleCollet dot com -Status: No Feedback +Status: Closed Bug Type: GD related Operating System: Linux (Fedora 9) PHP Version: 5.3.0alpha2 Assigned To: pajoye New Comment: Fixed in 5.3.0 and later. Previous Comments: [2009-04-15 01:00:00] 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. [2009-04-07 09:27:06] paj...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-03-27 18:50:40] tsteiner at nerdclub dot net Here's a quick patch that removes support for building against an external libgd and replaces it with an error message. It seems to work as intended but I am by no means experienced with the autoconf system. --- php-5.3.0RC1.orig/ext/gd/config.m4 2009-01-14 13:05:59.0 -0600 +++ php-5.3.0RC1/ext/gd/config.m4 2009-03-27 13:42:01.071603975 -0500 @@ -262,7 +262,6 @@ dnl if test $PHP_GD = yes; then - GD_MODULE_TYPE=builtin extra_sources=libgd/gd.c libgd/gd_gd.c libgd/gd_gd2.c libgd/gd_io.c libgd/gd_io_dp.c \ libgd/gd_io_file.c libgd/gd_ss.c libgd/gd_io_ss.c libgd/gd_png.c libgd/gd_jpeg.c \ libgd/gdxpm.c libgd/gdfontt.c libgd/gdfonts.c libgd/gdfontmb.c libgd/gdfontl.c \ @@ -339,57 +338,7 @@ else if test $PHP_GD != no; then - GD_MODULE_TYPE=external - extra_sources=gdcache.c - -dnl Various checks for GD features - PHP_GD_ZLIB - PHP_GD_TTSTR - PHP_GD_JPEG - PHP_GD_PNG - PHP_GD_XPM - PHP_GD_FREETYPE2 - PHP_GD_T1LIB - -dnl Header path - for i in include/gd1.3 include/gd include gd1.3 gd ; do -test -f $PHP_GD/$i/gd.h GD_INCLUDE=$PHP_GD/$i - done - -dnl Library path - for i in $PHP_LIBDIR/gd1.3 $PHP_LIBDIR/gd $PHP_LIBDIR gd1.3 gd ; do -test -f $PHP_GD/$i/libgd.$SHLIB_SUFFIX_NAME || test -f $PHP_GD/$i/libgd.a GD_LIB=$PHP_GD/$i - done - - if test -n $GD_INCLUDE test -n $GD_LIB; then -PHP_ADD_LIBRARY_WITH_PATH(gd, $GD_LIB, GD_SHARED_LIBADD) -AC_DEFINE(HAVE_LIBGD,1,[ ]) -PHP_GD_CHECK_VERSION - elif test -z $GD_INCLUDE; then -AC_MSG_ERROR([Unable to find gd.h anywhere under $PHP_GD]) - else -AC_MSG_ERROR([Unable to find libgd.(a|so) anywhere under $PHP_GD]) - fi - - PHP_EXPAND_PATH($GD_INCLUDE, GD_INCLUDE) - - dnl - dnl Check for gd 2.0.4 greater availability - dnl - old_CPPFLAGS=$CPPFLAGS - CPPFLAGS=-I$GD_INCLUDE - AC_TRY_COMPILE([ -#include gd.h -#include stdlib.h - ], [ -gdIOCtx *ctx; -ctx = malloc(sizeof(gdIOCtx)); -ctx-gd_free = 1; - ], [ -AC_DEFINE(HAVE_LIBGD204, 1, [ ]) - ]) - CPPFLAGS=$old_CPPFLAGS - + AC_MSG_ERROR([Building the GD extension against an external libgd is not supported.]) fi fi @@ -399,23 +348,13 @@ if test $PHP_GD != no; then PHP_NEW_EXTENSION(gd, gd.c $extra_sources, $ext_shared,, \\$(GDLIB_CFLAGS)) - if test $GD_MODULE_TYPE = builtin; then -GDLIB_CFLAGS=-I$ext_srcdir/libgd $GDLIB_CFLAGS -PHP_ADD_BUILD_DIR($ext_builddir/libgd) -GD_HEADER_DIRS=ext/gd/ ext/gd/libgd/ - -PHP_TEST_BUILD(foobar, [], [ - AC_MSG_ERROR([GD build test failed. Please check the config.log for details.]) -], [ $GD_SHARED_LIBADD ], [char foobar () {}]) - else -GD_HEADER_DIRS=ext/gd/ -GDLIB_CFLAGS=-I$GD_INCLUDE $GDLIB_CFLAGS -PHP_ADD_INCLUDE($GD_INCLUDE) - -PHP_CHECK_LIBRARY(gd, gdImageCreate, [], [ - AC_MSG_ERROR([GD build test failed. Please check the config.log for details.]) -], [ -L$GD_LIB $GD_SHARED_LIBADD ]) - fi + GDLIB_CFLAGS=-I$ext_srcdir/libgd $GDLIB_CFLAGS + PHP_ADD_BUILD_DIR($ext_builddir/libgd) + GD_HEADER_DIRS=ext/gd/ ext/gd/libgd/ + + PHP_TEST_BUILD(foobar, [], [ +AC_MSG_ERROR([GD build test failed. Please check the config.log for details.]) + ], [ $GD_SHARED_LIBADD ], [char foobar () {}]) PHP_INSTALL_HEADERS([$GD_HEADER_DIRS]) PHP_SUBST(GDLIB_CFLAGS) [2009-03-27 18:03:22] tsteiner at nerdclub dot net This is still an issue in 5.3.0RC1. If building against an external version of GD is no longer supported, the configure script should probably be updated to throw an error or at least a warning should one try to do so. Currently, the build just fails during make with the error: ext/gd/gd.c:72:23: error: gdhelpers.h: No such file or directory leaving the user with no idea what to do.
#45447 [NoF-Csd]: filesystem time functions
ID: 45447 Updated by: paj...@php.net Reported By: Bryan dot Gallant at hma dot com -Status: No Feedback +Status: Closed Bug Type: Filesystem function related Operating System: Windows Server 2008 PHP Version: 5.2.6 Assigned To: pajoye New Comment: Fixed in 5.3+ Previous Comments: [2008-08-23 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2008-08-15 18:36:46] paj...@php.net Fixed in CVS. Please try the 5.3 snapshot from http://snaps.php.net (the zip, not the MSI). [2008-08-13 07:46:56] paj...@php.net http://phpfi.com/342491 should fix it. I'm working on fixing many filesystem functions on Windows (touch, filemtime, stat, etc.). 98% of the file tests pass now on 2k8, xp and vista. [2008-08-13 06:55:38] j...@php.net What filesystem is used in the one that fails and on the one where it doesn't fail..? [2008-08-04 21:13:56] Bryan dot Gallant at hma dot com Interesting Update. using the same code on an old Win2k Box against the files on the 2008 server, it works as intended. 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/45447 -- Edit this bug report at http://bugs.php.net/?id=45447edit=1
#40858 [NoF-Csd]: Thread safety issue in GD
ID: 40858 Updated by: paj...@php.net Reported By: scottmacvicar at ntlworld dot com -Status: No Feedback +Status: Closed Bug Type: GD related Operating System: RHEL 4 PHP Version: 5.2.1 Assigned To: pajoye New Comment: fixed in all branches. Previous Comments: [2007-04-12 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2007-04-04 01:59:07] paj...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.2-win32-latest.zip [2007-03-23 12:39:34] scottmacvicar at ntlworld dot com I don't have access to a Windows machine at the moment but the following patch should fix the issues in libGD, I'll try and do a test when I have access to the machine. PHP 5.2 Patch: http://public.vbulletin.com/bugs/php/gd-mutex-patch.txt libGD Patch: http://public.vbulletin.com/bugs/php/libgd-mutex-patch.txt Explanation: * pthread now initialises the mutex only once * win32 can set the mutex within DLLMain * Race condition fix by locking prior to checking font cache Problems not fixed: * calling gdFontCacheSetup before obtaining a lock is going to cause the race condition still, I know the ruby wrappers do this. * Unusure about behaviour of using the non bundled GD library on windows with PHP since DLLMain and gdFontCacheMutexSetup may setup the critical section twice. Could make gdMutexSetup(x) a no-op for win32 too. [2007-03-23 01:21:26] paj...@php.net Hi Scott, Nuno, Regarding the patch to the bundled GD library and the php wrapper, does it look reasonable? We've been running it for the past 2 days now without issue on a production server. I'd rather see something put into 5.2.2 Yes, the patch for php (and unix) looks good. I will apply it during the weekend as well (or Nuno, you can do it if you have the time before). For the windows version, that's a good news, thanks to take the time to work on it. [2007-03-23 00:31:35] scottmacvicar at ntlworld dot com I have some time to spare over the weekend and a copy of VC6 installed now so I'll have a go at the win32 implementation. Regarding the patch to the bundled GD library and the php wrapper, does it look reasonable? We've been running it for the past 2 days now without issue on a production server. I'd rather see something put into 5.2.2 and then fix libGD. 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/40858 -- Edit this bug report at http://bugs.php.net/?id=40858edit=1
#49276 [NEW]: Sybase 15 incorrect library name references
From: andy at networkjabber dot com Operating system: Fedora Core 9 PHP version: 5.3.0 PHP Bug Type: Compile Failure Bug description: Sybase 15 incorrect library name references Description: This problem was originally logged on 24/2/2006 under #36516, but marked as bogus. However, the problem still exists. Sybase have changed the library names of 4 of their ASE libraries: libsybcs, libsybct, lsybcomn and lsybintl. The default automake profile references these as -lcs -lct -lcomn -lintl so the compile fails with libraries being reported as missing. Both ./configure and ./ext/sybase_ct/config.m4 need to be editied so that these references are -lsybcs -lsybct -lsybcomn -lsybsybintl. After these changes are made all compiles correctly. -- Edit bug report at http://bugs.php.net/?id=49276edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49276r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49276r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49276r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49276r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49276r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49276r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49276r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49276r=needscript Try newer version: http://bugs.php.net/fix.php?id=49276r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49276r=support Expected behavior: http://bugs.php.net/fix.php?id=49276r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49276r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49276r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49276r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49276r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49276r=dst IIS Stability: http://bugs.php.net/fix.php?id=49276r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49276r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49276r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49276r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49276r=mysqlcfg
#49274 [Opn-Fbk]: filter_var() should accept objects without fatal error
ID: 49274 Updated by: j...@php.net Reported By: cel...@php.net -Status: Open +Status: Feedback Bug Type: Filter related Operating System: * PHP Version: 5.3SVN-2009-08-16 (SVN) New Comment: Does this happen ONLY with PHP_5_3 branch? If not, please use the proper version string. Previous Comments: [2009-08-16 22:09:05] cel...@php.net Description: ?php filter_var(new stdClass, FILTER_VALIDATE_EMAIL); ? throws a fatal error because stdClass can't be converted into a string. filter_var() should be more flexible and simply return false in this situation, it makes it very difficult to provide validation not just for untrusted user input but for untrusted third party use of libraries who may make it insecure by passing in the wrong value to a field for setting. -- Edit this bug report at http://bugs.php.net/?id=49274edit=1
#49276 [Opn-Bgs]: Sybase 15 incorrect library name references
ID: 49276 Updated by: j...@php.net Reported By: andy at networkjabber dot com -Status: Open +Status: Bogus Bug Type: Sybase-ct (ctlib) related Operating System: Fedora Core 9 PHP Version: 5.3.0 New Comment: Bug #36516 was marked as being bogus because it was duplicate of bug #45357 and both didn't get any feedback when asked to test this patch: http://sitten-polizei.de/php/sybase-configm4.diff So please apply the patch, run ./buildconf --force and see if it works then. Previous Comments: [2009-08-17 08:56:52] andy at networkjabber dot com Description: This problem was originally logged on 24/2/2006 under #36516, but marked as bogus. However, the problem still exists. Sybase have changed the library names of 4 of their ASE libraries: libsybcs, libsybct, lsybcomn and lsybintl. The default automake profile references these as -lcs -lct -lcomn -lintl so the compile fails with libraries being reported as missing. Both ./configure and ./ext/sybase_ct/config.m4 need to be editied so that these references are -lsybcs -lsybct -lsybcomn -lsybsybintl. After these changes are made all compiles correctly. -- Edit this bug report at http://bugs.php.net/?id=49276edit=1
#49224 [Opn-Asn]: Segmentation fault
ID: 49224 Updated by: j...@php.net Reported By: alahaye at fm2i dot com -Status: Open +Status: Assigned Bug Type: Apache2 related Operating System: HPUX 11.31 PHP Version: 5.3.0 -Assigned To: +Assigned To: scottmac Previous Comments: [2009-08-14 12:11:35] alahaye at fm2i dot com Hi, did you receive my files ? [2009-08-12 10:36:34] scott...@php.net Can you mail me your config.log and your resolv.h file. [2009-08-12 09:37:01] alahaye at fm2i dot com Bind version is 9.3.2. For me it's very strange because last compilation about PHP 5.3.0 stable was successfull and not with the snap. [2009-08-12 09:24:47] alahaye at fm2i dot com unfortunatly no... it's on a local network, no VPN or DMZ access. [2009-08-12 09:12:21] scott...@php.net Is there any chance to get an account on this box to do some testing? I can provide an SSH key. 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/49224 -- Edit this bug report at http://bugs.php.net/?id=49224edit=1
#49254 [Opn-Bgs]: setlocale affects math functions
ID: 49254 Updated by: j...@php.net Reported By: stakadush at yahoo dot com -Status: Open +Status: Bogus Bug Type: Math related Operating System: Ubuntu 9.04 OS X 10.5.7 PHP Version: 5.3.0 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Previous Comments: [2009-08-14 14:49:35] stakadush at yahoo dot com Description: setlocalte affects the return of math functions, making them unusable. in this example the dot is being replaced with the italian comma notation. Reproduce code: --- setlocale(LC_ALL, 'it_IT.UTF-8'); echo abs(-5.5); Expected result: 5.5 Actual result: -- 5,5 -- Edit this bug report at http://bugs.php.net/?id=49254edit=1
#49151 [Opn-Asn]: relocation must bind locally
ID: 49151 Updated by: j...@php.net Reported By: tech at uscki dot nl -Status: Open +Status: Assigned Bug Type: Compile Failure Operating System: Sun Solaris 5.10 (i386) PHP Version: 5.3.0 Assigned To: nlopess New Comment: It should be as simple as adding 'static' in the macro ZEND_DECLARE_MODULE_GLOBALS since those should be static anyway.. Previous Comments: [2009-08-14 23:13:32] tech at uscki dot nl Yeah, got it compiling! I removed -fvisibility=hidden from the Makefile after running ./configure, guess that boils down to the same result, though your suggestion is a bit tidier. Compiler: gcc (GCC) 4.0.1 Thanks for all your help! [2009-08-14 21:54:04] nlop...@php.net sorry, I forgot to say that before ./configure you must run ./buildconf [2009-08-14 16:49:14] nlop...@php.net you can disable the visibility patch by editing the configure.in file and removing the occurrence of -fvisibility=hidden. Then do a ./vcsclean ./configure make. Then please report if it worked, and which compiler version you used. thanks. [2009-08-14 10:08:07] tech at uscki dot nl Hmmm, adding static isn't trivial, these first two methods were the tip of the iceberg... Looks like I'll be adding it all through the code if I go through with this (I stopped after about 10 changes in various files). How do I disable the visibility thing, as Nuno noted? [2009-08-13 10:01:53] j...@php.net in ext/date/php_date.c:485, add static in front of this line: ZEND_DECLARE_MODULE_GLOBALS(date) 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/49151 -- Edit this bug report at http://bugs.php.net/?id=49151edit=1
#49278 [NEW]: SoapClient::__getLastResponseHeaders returns NULL if wsdl operation !has output
From: jeroen at asystance dot nl Operating system: linux PHP version: 5.3SVN-2009-08-17 (snap) PHP Bug Type: SOAP related Bug description: SoapClient::__getLastResponseHeaders returns NULL if wsdl operation !has output Description: For wsdl:operations that do not have output, SoapClient does not return last response headers. Reproduce code: --- download http://jayvee.nl/soaptest3.tar change URL in interface.wsdl to point to SOAPtest.php SOAPtest.php contains both client and server code, so just run php SOAPtest.php Expected result: SoapClient::getLastResponseHeaders should return string Actual result: -- SoapClient::getLastResponseHeaders returns NULL -- Edit bug report at http://bugs.php.net/?id=49278edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49278r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49278r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49278r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49278r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49278r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49278r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49278r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49278r=needscript Try newer version: http://bugs.php.net/fix.php?id=49278r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49278r=support Expected behavior: http://bugs.php.net/fix.php?id=49278r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49278r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49278r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49278r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49278r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49278r=dst IIS Stability: http://bugs.php.net/fix.php?id=49278r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49278r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49278r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49278r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49278r=mysqlcfg
#49276 [Bgs-Asn]: Sybase 15 incorrect library name references
ID: 49276 Updated by: j...@php.net Reported By: andy at networkjabber dot com -Status: Bogus +Status: Assigned Bug Type: Sybase-ct (ctlib) related Operating System: Fedora Core 9 PHP Version: 5.3.0 -Assigned To: +Assigned To: thekid New Comment: Ok, so the patch works, lets keep this assigned to the maintainer then. :) Previous Comments: [2009-08-17 10:15:27] andy at networkjabber dot com Hi. Thanks for the quick reply. I can confirm that the patch works correctly and PHP compiles correctly with the specified directives to build Sybase ASE support. Perhaps it would be worth adding an extra autoconf argument in subsequent PHP releases for Sybase ASE versions previous to 12.5 and those later? i.e. --with-sybase-ct-oldlib or --with-sybase-ct-newlib, for example. Many thanks, Andy [2009-08-17 09:36:09] j...@php.net Bug #36516 was marked as being bogus because it was duplicate of bug #45357 and both didn't get any feedback when asked to test this patch: http://sitten-polizei.de/php/sybase-configm4.diff So please apply the patch, run ./buildconf --force and see if it works then. [2009-08-17 08:56:52] andy at networkjabber dot com Description: This problem was originally logged on 24/2/2006 under #36516, but marked as bogus. However, the problem still exists. Sybase have changed the library names of 4 of their ASE libraries: libsybcs, libsybct, lsybcomn and lsybintl. The default automake profile references these as -lcs -lct -lcomn -lintl so the compile fails with libraries being reported as missing. Both ./configure and ./ext/sybase_ct/config.m4 need to be editied so that these references are -lsybcs -lsybct -lsybcomn -lsybsybintl. After these changes are made all compiles correctly. -- Edit this bug report at http://bugs.php.net/?id=49276edit=1
#49276 [Asn]: Sybase 15 incorrect library name references
ID: 49276 Updated by: j...@php.net Reported By: andy at networkjabber dot com Status: Assigned Bug Type: Sybase-ct (ctlib) related Operating System: Fedora Core 9 PHP Version: 5.3.0 Assigned To: thekid New Comment: Oh, and you don't need extra configure options with the patch since then it detects the libs properly.. :) Previous Comments: [2009-08-17 11:15:43] j...@php.net Ok, so the patch works, lets keep this assigned to the maintainer then. :) [2009-08-17 10:15:27] andy at networkjabber dot com Hi. Thanks for the quick reply. I can confirm that the patch works correctly and PHP compiles correctly with the specified directives to build Sybase ASE support. Perhaps it would be worth adding an extra autoconf argument in subsequent PHP releases for Sybase ASE versions previous to 12.5 and those later? i.e. --with-sybase-ct-oldlib or --with-sybase-ct-newlib, for example. Many thanks, Andy [2009-08-17 09:36:09] j...@php.net Bug #36516 was marked as being bogus because it was duplicate of bug #45357 and both didn't get any feedback when asked to test this patch: http://sitten-polizei.de/php/sybase-configm4.diff So please apply the patch, run ./buildconf --force and see if it works then. [2009-08-17 08:56:52] andy at networkjabber dot com Description: This problem was originally logged on 24/2/2006 under #36516, but marked as bogus. However, the problem still exists. Sybase have changed the library names of 4 of their ASE libraries: libsybcs, libsybct, lsybcomn and lsybintl. The default automake profile references these as -lcs -lct -lcomn -lintl so the compile fails with libraries being reported as missing. Both ./configure and ./ext/sybase_ct/config.m4 need to be editied so that these references are -lsybcs -lsybct -lsybcomn -lsybsybintl. After these changes are made all compiles correctly. -- Edit this bug report at http://bugs.php.net/?id=49276edit=1
#49248 [Asn]: undefined reference to `zlib_globals'
ID: 49248 Updated by: j...@php.net -Summary: make error Reported By: e dot ehritt at web dot de Status: Assigned Bug Type: Compile Failure Operating System: Linux/2.6.30.4 x86_64 PHP Version: 5.3SVN-2009-08-14 (snap) Assigned To: jani New Comment: Related to fix for bug #48994 Previous Comments: [2009-08-16 05:50:52] ka...@php.net Jani, you changed to use ZLIBG in main, but unless thats exported it cannot be used when its built shared. So we need to either export it or just skip this part in main/ if zlib is shared. [2009-08-14 00:07:02] e dot ehritt at web dot de Description: $ export CFLAGS=-march=athlon64 -O3 -pipe -fstack-protector -fstack-protector-all export EXTENSION_DIR=/home/eddi/opt/php/5.3.0/lib ./configure --prefix=/home/eddi/opt/php/5.3.0 --mandir=/home/eddi/opt/man --build=x86_64-pc-linux-gnu --with-config-file-path=/home/eddi/opt/conf --with-zend-vm=GOTO --disable-all --with-bz2=shared --with-curl=shared --with-curlwrappers --with-gd=shared --with-gettext=shared --with-iconv=shared --with-openssl=shared --with-regex=shared --with-xmlrpc=shared --with-xsl=shared --with-zlib=shared --enable-bcmath=shared --enable-calendar=shared --enable-ctype=shared --enable-dom=shared --enable-exif=shared --enable-fileinfo=shared --enable-filter=shared --enable-ftp=shared --enable-hash=shared --enable-libxml=shared --enable-pcntl=shared --enable-phar=shared --enable-posix=shared --enable-shmop=shared --enable-simplexml=shared --enable-soap=shared --enable-sockets=shared --enable-sysvmsg=shared --enable-sysvsem=shared --enable-sysvshm=shared --enable-tokenizer=shared --enable-wddx=shared --enable-xml=shared --enable-xmlreader=shared --enable-xmlwriter=shared --enable-zip=shared --enable-sigchild --enable-cgi --disable-short-tags $ make /dev/null /home/eddi/opt/src/php5.3-200908132230/ext/date/php_date.c: In function 'date_format': /home/eddi/opt/src/php5.3-200908132230/ext/date/php_date.c:1058: warning: incompatible implicit declaration of built-in function 'llabs' /home/eddi/opt/src/php5.3-200908132230/main/streams/cast.c: In function '_php_stream_cast': /home/eddi/opt/src/php5.3-200908132230/main/streams/cast.c:222: warning: cast to pointer from integer of different size /home/eddi/opt/src/php5.3-200908132230/main/streams/cast.c:225: warning: cast to pointer from integer of different size /home/eddi/opt/src/php5.3-200908132230/Zend/zend_objects.c: In function 'zend_objects_destroy_object': /home/eddi/opt/src/php5.3-200908132230/Zend/zend_objects.c:95: warning: assignment discards qualifiers from pointer target type main/.libs/SAPI.o: In function `sapi_send_headers': SAPI.c:(.text+0x1fca): undefined reference to `zlib_globals' collect2: ld returned 1 exit status make: *** [sapi/cgi/php-cgi] Error 1 Reproduce code: --- $ gcc -v Using built-in specs. Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.3.2-r3/work/gcc-4.3.2/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.2 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.2 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.2/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.2/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-multilib --enable-libmudflap --disable-libssp --enable-libgomp --disable-libgcj --enable-languages=c,c++,treelang,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.3.2-r3 p1.6, pie-10.1.5' Thread model: posix gcc version 4.3.2 (Gentoo 4.3.2-r3 p1.6, pie-10.1.5) $ ld -v GNU ld (GNU Binutils) 2.18 -- Edit this bug report at http://bugs.php.net/?id=49248edit=1
#49274 [Fbk]: filter_var() should accept objects without fatal error
ID: 49274 Updated by: cel...@php.net Reported By: cel...@php.net Status: Feedback Bug Type: Filter related Operating System: * PHP Version: 5.3SVN-2009-08-16 (SVN) New Comment: don't know, that's up to the developers to decide, don't you think? Previous Comments: [2009-08-17 09:32:59] j...@php.net Does this happen ONLY with PHP_5_3 branch? If not, please use the proper version string. [2009-08-16 22:09:05] cel...@php.net Description: ?php filter_var(new stdClass, FILTER_VALIDATE_EMAIL); ? throws a fatal error because stdClass can't be converted into a string. filter_var() should be more flexible and simply return false in this situation, it makes it very difficult to provide validation not just for untrusted user input but for untrusted third party use of libraries who may make it insecure by passing in the wrong value to a field for setting. -- Edit this bug report at http://bugs.php.net/?id=49274edit=1
#42516 [Csd-Opn]: __FILE__ resolves symlinks - not mentioned in manual
ID: 42516 User updated by: michael at zedeler dot dk Reported By: michael at zedeler dot dk -Status: Closed +Status: Open -Bug Type: Documentation problem +Bug Type: Feature/Change Request Operating System: Linux PHP Version: 4.4.7 Assigned To: bjori New Comment: Moved to Feature/Change request category. Previous Comments: [2009-04-24 05:58:24] bj...@php.net Please use the developers mailinglist for feature discussions (intern...@lists.php.net). [2009-04-23 18:51:59] michael at zedeler dot dk Wrong category. [2009-04-23 17:53:20] michael at zedeler dot dk Sorry to bug you again, but as I am writing in the report, just putting a description of the errant behaviour is not a useful fix. [2008-04-13 23:46:35] bj...@php.net This bug has been fixed in the documentation's XML sources. Since the online and downloadable versions of the documentation need some time to get updated, we would like to ask you to be a bit patient. Thank you for the report, and for helping us make our documentation better. [2007-09-01 21:02:38] michael at zedeler dot dk Description: __FILE__ does not return the path used to invoke the current file, but resolves symlinks. This behaviour is extremely problematics, since important information is thrown away. The web is teeming with postings from people that are experiencing problems because of this. In http://bugs.php.net/bug.php?id=37603 this bug was mentioned and the response was that it is intended behavior with a reference to the manual. The page http://es.php.net/manual/en/language.constants.predefined.php is the primary source of information for __FILE__, and it does not mention resolving symlinks at all. I'd like if we could have som kind of dialogue about how to solve the problem, in stead of just having this bug being closed with a Bogus status. My suggestions are: 1) introduce a new magical constant that behaves as it should. 2) put a parameter in php.ini that changes how __FILE__ behaves. Reproduce code: --- This is basically a reopening of http://bugs.php.net/bug.php?id=37603 Expected result: This is basically a reopening of http://bugs.php.net/bug.php?id=37603 Actual result: -- This is basically a reopening of http://bugs.php.net/bug.php?id=37603 -- Edit this bug report at http://bugs.php.net/?id=42516edit=1
#42516 [Opn]: __FILE__ resolves symlinks
ID: 42516 User updated by: michael at zedeler dot dk -Summary: __FILE__ resolves symlinks - not mentioned in manual Reported By: michael at zedeler dot dk Status: Open Bug Type: Feature/Change Request Operating System: Linux PHP Version: 4.4.7 Assigned To: bjori New Comment: Fixed subject. Previous Comments: [2009-08-17 12:56:08] michael at zedeler dot dk Moved to Feature/Change request category. [2009-04-24 05:58:24] bj...@php.net Please use the developers mailinglist for feature discussions (intern...@lists.php.net). [2009-04-23 18:51:59] michael at zedeler dot dk Wrong category. [2009-04-23 17:53:20] michael at zedeler dot dk Sorry to bug you again, but as I am writing in the report, just putting a description of the errant behaviour is not a useful fix. [2008-04-13 23:46:35] bj...@php.net This bug has been fixed in the documentation's XML sources. Since the online and downloadable versions of the documentation need some time to get updated, we would like to ask you to be a bit patient. Thank you for the report, and for helping us make our documentation better. 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/42516 -- Edit this bug report at http://bugs.php.net/?id=42516edit=1
#49274 [Fbk-Bgs]: filter_var() should accept objects without fatal error
ID: 49274 Updated by: j...@php.net Reported By: cel...@php.net -Status: Feedback +Status: Bogus Bug Type: Filter related Operating System: * PHP Version: 5.3SVN-2009-08-16 (SVN) New Comment: This is not a bug. It's exactly what's supposed to happen. When you pass crap in you get crap out. The language isn't supposed to hold your hand in every corner. Previous Comments: [2009-08-17 11:45:09] cel...@php.net don't know, that's up to the developers to decide, don't you think? [2009-08-17 09:32:59] j...@php.net Does this happen ONLY with PHP_5_3 branch? If not, please use the proper version string. [2009-08-16 22:09:05] cel...@php.net Description: ?php filter_var(new stdClass, FILTER_VALIDATE_EMAIL); ? throws a fatal error because stdClass can't be converted into a string. filter_var() should be more flexible and simply return false in this situation, it makes it very difficult to provide validation not just for untrusted user input but for untrusted third party use of libraries who may make it insecure by passing in the wrong value to a field for setting. -- Edit this bug report at http://bugs.php.net/?id=49274edit=1
#49248 [Asn]: undefined reference to `zlib_globals'
ID: 49248 Updated by: j...@php.net Reported By: e dot ehritt at web dot de Status: Assigned Bug Type: Compile Failure Operating System: * -PHP Version: 5.*, 6 +PHP Version: 5.* Assigned To: jani New Comment: And this is 5.* only, HEAD has better output handling. Previous Comments: [2009-08-17 11:28:35] j...@php.net Related to fix for bug #48994 [2009-08-16 05:50:52] ka...@php.net Jani, you changed to use ZLIBG in main, but unless thats exported it cannot be used when its built shared. So we need to either export it or just skip this part in main/ if zlib is shared. [2009-08-14 00:07:02] e dot ehritt at web dot de Description: $ export CFLAGS=-march=athlon64 -O3 -pipe -fstack-protector -fstack-protector-all export EXTENSION_DIR=/home/eddi/opt/php/5.3.0/lib ./configure --prefix=/home/eddi/opt/php/5.3.0 --mandir=/home/eddi/opt/man --build=x86_64-pc-linux-gnu --with-config-file-path=/home/eddi/opt/conf --with-zend-vm=GOTO --disable-all --with-bz2=shared --with-curl=shared --with-curlwrappers --with-gd=shared --with-gettext=shared --with-iconv=shared --with-openssl=shared --with-regex=shared --with-xmlrpc=shared --with-xsl=shared --with-zlib=shared --enable-bcmath=shared --enable-calendar=shared --enable-ctype=shared --enable-dom=shared --enable-exif=shared --enable-fileinfo=shared --enable-filter=shared --enable-ftp=shared --enable-hash=shared --enable-libxml=shared --enable-pcntl=shared --enable-phar=shared --enable-posix=shared --enable-shmop=shared --enable-simplexml=shared --enable-soap=shared --enable-sockets=shared --enable-sysvmsg=shared --enable-sysvsem=shared --enable-sysvshm=shared --enable-tokenizer=shared --enable-wddx=shared --enable-xml=shared --enable-xmlreader=shared --enable-xmlwriter=shared --enable-zip=shared --enable-sigchild --enable-cgi --disable-short-tags $ make /dev/null /home/eddi/opt/src/php5.3-200908132230/ext/date/php_date.c: In function 'date_format': /home/eddi/opt/src/php5.3-200908132230/ext/date/php_date.c:1058: warning: incompatible implicit declaration of built-in function 'llabs' /home/eddi/opt/src/php5.3-200908132230/main/streams/cast.c: In function '_php_stream_cast': /home/eddi/opt/src/php5.3-200908132230/main/streams/cast.c:222: warning: cast to pointer from integer of different size /home/eddi/opt/src/php5.3-200908132230/main/streams/cast.c:225: warning: cast to pointer from integer of different size /home/eddi/opt/src/php5.3-200908132230/Zend/zend_objects.c: In function 'zend_objects_destroy_object': /home/eddi/opt/src/php5.3-200908132230/Zend/zend_objects.c:95: warning: assignment discards qualifiers from pointer target type main/.libs/SAPI.o: In function `sapi_send_headers': SAPI.c:(.text+0x1fca): undefined reference to `zlib_globals' collect2: ld returned 1 exit status make: *** [sapi/cgi/php-cgi] Error 1 Reproduce code: --- $ gcc -v Using built-in specs. Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.3.2-r3/work/gcc-4.3.2/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.2 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.2 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.2/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.2/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-multilib --enable-libmudflap --disable-libssp --enable-libgomp --disable-libgcj --enable-languages=c,c++,treelang,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.3.2-r3 p1.6, pie-10.1.5' Thread model: posix gcc version 4.3.2 (Gentoo 4.3.2-r3 p1.6, pie-10.1.5) $ ld -v GNU ld (GNU Binutils) 2.18 -- Edit this bug report at http://bugs.php.net/?id=49248edit=1
#49274 [Bgs-Opn]: filter_var() should accept objects without fatal error
ID: 49274 Updated by: cel...@php.net Reported By: cel...@php.net -Status: Bogus +Status: Open Bug Type: Filter related Operating System: * PHP Version: 5.3SVN-2009-08-16 (SVN) New Comment: ?php var_dump(filter_var(null, FILTER_VALIDATE_INT)); var_dump(filter_var(array(), FILTER_VALIDATE_INT)); var_dump(filter_var('hi', FILTER_VALIDATE_INT)); var_dump(filter_var(1.1, FILTER_VALIDATE_INT)); var_dump(filter_var(fopen('somefile', 'r'), FILTER_VALIDATE_INT)); var_dump(filter_var(1, FILTER_VALIDATE_INT)); var_dump(filter_var('1.0', FILTER_VALIDATE_INT)); ? all work without error. ?php class blah {function __toString(){return '1';}} var_dump(filter_var(new blah, FILTER_VALIDATE_INT)); ? works without error. Only filter_var with an object that doesn't implement __toString fails with an error. Either filter is incorrectly returning false with no error on all of those other random types, or you're wrong, Jani. Previous Comments: [2009-08-17 13:13:43] j...@php.net This is not a bug. It's exactly what's supposed to happen. When you pass crap in you get crap out. The language isn't supposed to hold your hand in every corner. [2009-08-17 11:45:09] cel...@php.net don't know, that's up to the developers to decide, don't you think? [2009-08-17 09:32:59] j...@php.net Does this happen ONLY with PHP_5_3 branch? If not, please use the proper version string. [2009-08-16 22:09:05] cel...@php.net Description: ?php filter_var(new stdClass, FILTER_VALIDATE_EMAIL); ? throws a fatal error because stdClass can't be converted into a string. filter_var() should be more flexible and simply return false in this situation, it makes it very difficult to provide validation not just for untrusted user input but for untrusted third party use of libraries who may make it insecure by passing in the wrong value to a field for setting. -- Edit this bug report at http://bugs.php.net/?id=49274edit=1
#49279 [NEW]: Current does not seem to work with Iterator
From: andrew at ajohnstone dot com Operating system: debain PHP version: 5.2.10 PHP Bug Type: *General Issues Bug description: Current does not seem to work with Iterator Description: Current does not seem to work with Iterator Reproduce code: --- ?php class test implements IteratorAggregate, Iterator { protected $_data = array( 0=1, 1=2, 2=3, 3=4, 4=5, ); public function getIterator() { var_dump(__FUNCTION__); return $this-getCurrentItems(); } public function getCurrentItems() { return $this-_data; } public function current() { var_dump(__FUNCTION__); $this-_data = $this-getCurrentItems(); return current($this-_data); } public function key() { var_dump(__FUNCTION__); return key($this-_data); } public function next() { var_dump(__FUNCTION__); next($this-_data); } public function rewind() { var_dump(__FUNCTION__); $this-_data = $this-getCurrentItems(); $this-_pointer = 0; reset($this-_data); } public function valid() { var_dump(__FUNCTION__); return (current($this-_data) !== FALSE); } } $c = new test(); var_dump(current($c)); Expected result: string 'current' (length=7) 1 Actual result: -- bool(false) -- Edit bug report at http://bugs.php.net/?id=49279edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49279r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49279r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49279r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49279r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49279r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49279r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49279r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49279r=needscript Try newer version: http://bugs.php.net/fix.php?id=49279r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49279r=support Expected behavior: http://bugs.php.net/fix.php?id=49279r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49279r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49279r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49279r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49279r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49279r=dst IIS Stability: http://bugs.php.net/fix.php?id=49279r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49279r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49279r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49279r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49279r=mysqlcfg
#49274 [Opn-Fbk]: filter_var() should accept objects without fatal error
ID: 49274 Updated by: paj...@php.net Reported By: cel...@php.net -Status: Open +Status: Feedback Bug Type: Filter related Operating System: * PHP Version: 5.3SVN-2009-08-16 (SVN) New Comment: As StdClass has no __toString implementation (obviously), it can't be converted to string. I tend to agree that it should not raise a fatal (recovable error) here as it defeats the main purpose of this API. I'm however not sure it is worth the effort to add custom error handler for this edge case. Patch welcome, it could help to get this edge case solved (I can't work on this exact issue any time soon). Previous Comments: [2009-08-17 13:27:50] cel...@php.net ?php var_dump(filter_var(null, FILTER_VALIDATE_INT)); var_dump(filter_var(array(), FILTER_VALIDATE_INT)); var_dump(filter_var('hi', FILTER_VALIDATE_INT)); var_dump(filter_var(1.1, FILTER_VALIDATE_INT)); var_dump(filter_var(fopen('somefile', 'r'), FILTER_VALIDATE_INT)); var_dump(filter_var(1, FILTER_VALIDATE_INT)); var_dump(filter_var('1.0', FILTER_VALIDATE_INT)); ? all work without error. ?php class blah {function __toString(){return '1';}} var_dump(filter_var(new blah, FILTER_VALIDATE_INT)); ? works without error. Only filter_var with an object that doesn't implement __toString fails with an error. Either filter is incorrectly returning false with no error on all of those other random types, or you're wrong, Jani. [2009-08-17 13:13:43] j...@php.net This is not a bug. It's exactly what's supposed to happen. When you pass crap in you get crap out. The language isn't supposed to hold your hand in every corner. [2009-08-17 11:45:09] cel...@php.net don't know, that's up to the developers to decide, don't you think? [2009-08-17 09:32:59] j...@php.net Does this happen ONLY with PHP_5_3 branch? If not, please use the proper version string. [2009-08-16 22:09:05] cel...@php.net Description: ?php filter_var(new stdClass, FILTER_VALIDATE_EMAIL); ? throws a fatal error because stdClass can't be converted into a string. filter_var() should be more flexible and simply return false in this situation, it makes it very difficult to provide validation not just for untrusted user input but for untrusted third party use of libraries who may make it insecure by passing in the wrong value to a field for setting. -- Edit this bug report at http://bugs.php.net/?id=49274edit=1
#49274 [Fbk]: filter_var() should accept objects without fatal error
ID: 49274 Updated by: cel...@php.net Reported By: cel...@php.net Status: Feedback Bug Type: Filter related Operating System: * PHP Version: 5.3SVN-2009-08-16 (SVN) New Comment: the stdClass was just to illustrate the point, this happens with any object that doesn't have a __toString(). I would imagine it would be easier to check for IS_OBJECT and then see if it implements __toString than to do a custom error handler. The performance should be about the same (dismal). Previous Comments: [2009-08-17 13:48:45] paj...@php.net As StdClass has no __toString implementation (obviously), it can't be converted to string. I tend to agree that it should not raise a fatal (recovable error) here as it defeats the main purpose of this API. I'm however not sure it is worth the effort to add custom error handler for this edge case. Patch welcome, it could help to get this edge case solved (I can't work on this exact issue any time soon). [2009-08-17 13:27:50] cel...@php.net ?php var_dump(filter_var(null, FILTER_VALIDATE_INT)); var_dump(filter_var(array(), FILTER_VALIDATE_INT)); var_dump(filter_var('hi', FILTER_VALIDATE_INT)); var_dump(filter_var(1.1, FILTER_VALIDATE_INT)); var_dump(filter_var(fopen('somefile', 'r'), FILTER_VALIDATE_INT)); var_dump(filter_var(1, FILTER_VALIDATE_INT)); var_dump(filter_var('1.0', FILTER_VALIDATE_INT)); ? all work without error. ?php class blah {function __toString(){return '1';}} var_dump(filter_var(new blah, FILTER_VALIDATE_INT)); ? works without error. Only filter_var with an object that doesn't implement __toString fails with an error. Either filter is incorrectly returning false with no error on all of those other random types, or you're wrong, Jani. [2009-08-17 13:13:43] j...@php.net This is not a bug. It's exactly what's supposed to happen. When you pass crap in you get crap out. The language isn't supposed to hold your hand in every corner. [2009-08-17 11:45:09] cel...@php.net don't know, that's up to the developers to decide, don't you think? [2009-08-17 09:32:59] j...@php.net Does this happen ONLY with PHP_5_3 branch? If not, please use the proper version string. 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/49274 -- Edit this bug report at http://bugs.php.net/?id=49274edit=1
#49279 [Opn-Bgs]: Current does not seem to work with Iterator
ID: 49279 Updated by: scott...@php.net Reported By: andrew at ajohnstone dot com -Status: Open +Status: Bogus Bug Type: *General Issues Operating System: debain PHP Version: 5.2.10 New Comment: None of the array functions work with iterator interface, its designed to allow you iterate through objects with foreach() / while(). Previous Comments: [2009-08-17 13:45:24] andrew at ajohnstone dot com Description: Current does not seem to work with Iterator Reproduce code: --- ?php class test implements IteratorAggregate, Iterator { protected $_data = array( 0=1, 1=2, 2=3, 3=4, 4=5, ); public function getIterator() { var_dump(__FUNCTION__); return $this-getCurrentItems(); } public function getCurrentItems() { return $this-_data; } public function current() { var_dump(__FUNCTION__); $this-_data = $this-getCurrentItems(); return current($this-_data); } public function key() { var_dump(__FUNCTION__); return key($this-_data); } public function next() { var_dump(__FUNCTION__); next($this-_data); } public function rewind() { var_dump(__FUNCTION__); $this-_data = $this-getCurrentItems(); $this-_pointer = 0; reset($this-_data); } public function valid() { var_dump(__FUNCTION__); return (current($this-_data) !== FALSE); } } $c = new test(); var_dump(current($c)); Expected result: string 'current' (length=7) 1 Actual result: -- bool(false) -- Edit this bug report at http://bugs.php.net/?id=49279edit=1
#49274 [Fbk-Ana]: filter_var() should accept objects without fatal error
ID: 49274 Updated by: paj...@php.net Reported By: cel...@php.net -Status: Feedback +Status: Analyzed Bug Type: Filter related Operating System: * PHP Version: 5.3SVN-2009-08-16 (SVN) New Comment: it is indeed valid for all objects but it is still an edge case. A check for IS_OBJECT + tostring() existence could be easy enough and with almost no impact(perf impact is null on the existing application). If you have some time to write one, go ahead. Previous Comments: [2009-08-17 13:52:56] cel...@php.net the stdClass was just to illustrate the point, this happens with any object that doesn't have a __toString(). I would imagine it would be easier to check for IS_OBJECT and then see if it implements __toString than to do a custom error handler. The performance should be about the same (dismal). [2009-08-17 13:48:45] paj...@php.net As StdClass has no __toString implementation (obviously), it can't be converted to string. I tend to agree that it should not raise a fatal (recovable error) here as it defeats the main purpose of this API. I'm however not sure it is worth the effort to add custom error handler for this edge case. Patch welcome, it could help to get this edge case solved (I can't work on this exact issue any time soon). [2009-08-17 13:27:50] cel...@php.net ?php var_dump(filter_var(null, FILTER_VALIDATE_INT)); var_dump(filter_var(array(), FILTER_VALIDATE_INT)); var_dump(filter_var('hi', FILTER_VALIDATE_INT)); var_dump(filter_var(1.1, FILTER_VALIDATE_INT)); var_dump(filter_var(fopen('somefile', 'r'), FILTER_VALIDATE_INT)); var_dump(filter_var(1, FILTER_VALIDATE_INT)); var_dump(filter_var('1.0', FILTER_VALIDATE_INT)); ? all work without error. ?php class blah {function __toString(){return '1';}} var_dump(filter_var(new blah, FILTER_VALIDATE_INT)); ? works without error. Only filter_var with an object that doesn't implement __toString fails with an error. Either filter is incorrectly returning false with no error on all of those other random types, or you're wrong, Jani. [2009-08-17 13:13:43] j...@php.net This is not a bug. It's exactly what's supposed to happen. When you pass crap in you get crap out. The language isn't supposed to hold your hand in every corner. [2009-08-17 11:45:09] cel...@php.net don't know, that's up to the developers to decide, don't you think? 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/49274 -- Edit this bug report at http://bugs.php.net/?id=49274edit=1
#49280 [NEW]: Not possible to detect mysqlnd in php
From: ar at ez dot no Operating system: All PHP version: 5.3.0 PHP Bug Type: MySQLi related Bug description: Not possible to detect mysqlnd in php Description: There doesn't seem to be possible to cleanly* detect that mysqlnd is currently in use. * Constant would be nice, preferably already in 5.3.next Detecting by presence off 'mysqli_fetch_all' or other functions is not exactly clean. Use case: Disabling / enabling Persistent Connections based on application specific settings. See: http://issues.ez.no/IssueView.php?Id=15315 -- Edit bug report at http://bugs.php.net/?id=49280edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49280r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49280r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49280r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49280r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49280r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49280r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49280r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49280r=needscript Try newer version: http://bugs.php.net/fix.php?id=49280r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49280r=support Expected behavior: http://bugs.php.net/fix.php?id=49280r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49280r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49280r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49280r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49280r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49280r=dst IIS Stability: http://bugs.php.net/fix.php?id=49280r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49280r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49280r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49280r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49280r=mysqlcfg
#49281 [NEW]: Using . operator whilst assigning to a property gives misleading error.
From: RQuadling at GMail dot com Operating system: Irrelevant PHP version: 5.3SVN-2009-08-17 (snap) PHP Bug Type: Feature/Change Request Bug description: Using . operator whilst assigning to a property gives misleading error. Description: Changeset http://svn.php.net/viewvc?view=revisionrevision=286600. The Config.php class is using . to create a property. The error that is generated is appropriate, but I feel it is misleading. The error is different under slightly different circumstances. The 2 scripts below show what I mean. Having said that, the elements being concatenated are constant, so I believe there is some argument that these are NOT dynamic as say a function call would be. Reproduce code: --- = Test1.php = ?php class Config { public $string = __DIR__ . 'something'; } ? = Test2.php = ?php class Config { public $array = array(__DIR__ . 'something'); } Expected result: An error along the lines that you cannot assign dynamic values to properties during class creation. Actual result: -- = Test1.php = Parse error: parse error, expecting `','' or `';'' in Z:\Test1.php on line 3 = Test2.php = Parse error: parse error, expecting `')'' in Z:\Test2.php on line 3 -- Edit bug report at http://bugs.php.net/?id=49281edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49281r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49281r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49281r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49281r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49281r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49281r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49281r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49281r=needscript Try newer version: http://bugs.php.net/fix.php?id=49281r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49281r=support Expected behavior: http://bugs.php.net/fix.php?id=49281r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49281r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49281r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49281r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49281r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49281r=dst IIS Stability: http://bugs.php.net/fix.php?id=49281r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49281r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49281r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49281r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49281r=mysqlcfg
#49280 [Com]: Not possible to detect mysqlnd in php
ID: 49280 Comment by: ar at ez dot no Reported By: ar at ez dot no Status: Open Bug Type: MySQLi related Operating System: All PHP Version: 5.3.0 New Comment: Seems to be possible with something like this as well: strpos( mysqli_get_client_info(), 'mysqlnd ' ) !== false But constant would still be a bit cleaner. Previous Comments: [2009-08-17 14:10:00] ar at ez dot no Description: There doesn't seem to be possible to cleanly* detect that mysqlnd is currently in use. * Constant would be nice, preferably already in 5.3.next Detecting by presence off 'mysqli_fetch_all' or other functions is not exactly clean. Use case: Disabling / enabling Persistent Connections based on application specific settings. See: http://issues.ez.no/IssueView.php?Id=15315 -- Edit this bug report at http://bugs.php.net/?id=49280edit=1
#49280 [Opn-Fbk]: Not possible to detect mysqlnd in php
ID: 49280 Updated by: j...@php.net Reported By: ar at ez dot no -Status: Open +Status: Feedback Bug Type: MySQLi related Operating System: * PHP Version: 5.3.0 New Comment: So you want to circumvent a bug by adding a constant instead of fixing the actual bug? Can you please explain WHAT does not work like it should when you have enabled mysqlnd..? Previous Comments: [2009-08-17 14:21:35] ar at ez dot no Seems to be possible with something like this as well: strpos( mysqli_get_client_info(), 'mysqlnd ' ) !== false But constant would still be a bit cleaner. [2009-08-17 14:10:00] ar at ez dot no Description: There doesn't seem to be possible to cleanly* detect that mysqlnd is currently in use. * Constant would be nice, preferably already in 5.3.next Detecting by presence off 'mysqli_fetch_all' or other functions is not exactly clean. Use case: Disabling / enabling Persistent Connections based on application specific settings. See: http://issues.ez.no/IssueView.php?Id=15315 -- Edit this bug report at http://bugs.php.net/?id=49280edit=1
#49280 [Com]: Not possible to detect mysqlnd in php
ID: 49280 Comment by: ar at ez dot no Reported By: ar at ez dot no Status: Feedback Bug Type: MySQLi related Operating System: * PHP Version: 5.3.0 New Comment: Hi jani! I'm not trying to workaround anything, its just that Persistent Connections are only supported on mysqli when mysqlnd is used. So it doesn't help to detect php version using PHP_VERSION, as the end user might have mysqlnd disabled / not compiled in. It is possible to detect it by by using function_exists. But since you guys might add those extra mysqlnd functions to the other mysql driver as well, that is not reliable not to mention clean. see: http://no.php.net/mysqli.mysqlnd For what I'm trying to do: eZ Publish like other php projects abstracts things, one of those is Persistent connection, witch is abstracted into a ini setting (changeable in admin gui). So I need to prepend p: IF user has mysqlnd, or trow a warning about unsupported setting. Previous Comments: [2009-08-17 14:30:15] j...@php.net So you want to circumvent a bug by adding a constant instead of fixing the actual bug? Can you please explain WHAT does not work like it should when you have enabled mysqlnd..? [2009-08-17 14:21:35] ar at ez dot no Seems to be possible with something like this as well: strpos( mysqli_get_client_info(), 'mysqlnd ' ) !== false But constant would still be a bit cleaner. [2009-08-17 14:10:00] ar at ez dot no Description: There doesn't seem to be possible to cleanly* detect that mysqlnd is currently in use. * Constant would be nice, preferably already in 5.3.next Detecting by presence off 'mysqli_fetch_all' or other functions is not exactly clean. Use case: Disabling / enabling Persistent Connections based on application specific settings. See: http://issues.ez.no/IssueView.php?Id=15315 -- Edit this bug report at http://bugs.php.net/?id=49280edit=1
#49280 [Fbk-Opn]: Not possible to detect mysqlnd in php
ID: 49280 User updated by: ar at ez dot no Reported By: ar at ez dot no -Status: Feedback +Status: Open Bug Type: MySQLi related Operating System: * PHP Version: 5.3.0 New Comment: see above comment. Previous Comments: [2009-08-17 14:53:12] ar at ez dot no Hi jani! I'm not trying to workaround anything, its just that Persistent Connections are only supported on mysqli when mysqlnd is used. So it doesn't help to detect php version using PHP_VERSION, as the end user might have mysqlnd disabled / not compiled in. It is possible to detect it by by using function_exists. But since you guys might add those extra mysqlnd functions to the other mysql driver as well, that is not reliable not to mention clean. see: http://no.php.net/mysqli.mysqlnd For what I'm trying to do: eZ Publish like other php projects abstracts things, one of those is Persistent connection, witch is abstracted into a ini setting (changeable in admin gui). So I need to prepend p: IF user has mysqlnd, or trow a warning about unsupported setting. [2009-08-17 14:30:15] j...@php.net So you want to circumvent a bug by adding a constant instead of fixing the actual bug? Can you please explain WHAT does not work like it should when you have enabled mysqlnd..? [2009-08-17 14:21:35] ar at ez dot no Seems to be possible with something like this as well: strpos( mysqli_get_client_info(), 'mysqlnd ' ) !== false But constant would still be a bit cleaner. [2009-08-17 14:10:00] ar at ez dot no Description: There doesn't seem to be possible to cleanly* detect that mysqlnd is currently in use. * Constant would be nice, preferably already in 5.3.next Detecting by presence off 'mysqli_fetch_all' or other functions is not exactly clean. Use case: Disabling / enabling Persistent Connections based on application specific settings. See: http://issues.ez.no/IssueView.php?Id=15315 -- Edit this bug report at http://bugs.php.net/?id=49280edit=1
#49282 [NEW]: importNode() looses namespaceURI value
From: daniel at webdevelopers dot cz Operating system: Ubuntu 2.6.21 i686 PHP version: 5.3.0 PHP Bug Type: DOM XML related Bug description: importNode() looses namespaceURI value Description: libxml 2.6.31 When importing previously removed element into the new document the namespaceURI is not preserved. It is preserved only if the @xmlns declaration attribute is present on the element itself. Does not work if it was declared on former ancestor. Reproduce code: --- $rcpt=new DOMDocument; $rcpt-loadXML(rcpt/rcpt); // XMLNS on parent $dnr1=new DOMDocument; $dnr1-loadXML(dnr xmlns:sys='http://www.1stomni.com/spire'sys:donate//dnr); // XMLNS on element $dnr2=new DOMDocument; $dnr2-loadXML(dnrsys:donate xmlns:sys='http://www.1stomni.com/spire'//dnr); getGift($rcpt, $dnr1-documentElement-removeChild($dnr1-documentElement-firstChild)); getGift($rcpt, $dnr2-documentElement-removeChild($dnr2-documentElement-firstChild)); function getGift($dom, $gift) { echo before: \$gift-namespaceURI\; after: \.$dom-documentElement-appendChild($dom-importNode($gift))-namespaceURI.\\n; } Expected result: before: http://www.1stomni.com/spire;; after: http://www.1stomni.com/spire; before: http://www.1stomni.com/spire;; after: http://www.1stomni.com/spire; Actual result: -- before: http://www.1stomni.com/spire;; after: before: http://www.1stomni.com/spire;; after: http://www.1stomni.com/spire; -- Edit bug report at http://bugs.php.net/?id=49282edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49282r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49282r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49282r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49282r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49282r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49282r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49282r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49282r=needscript Try newer version: http://bugs.php.net/fix.php?id=49282r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49282r=support Expected behavior: http://bugs.php.net/fix.php?id=49282r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49282r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49282r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49282r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49282r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49282r=dst IIS Stability: http://bugs.php.net/fix.php?id=49282r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49282r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49282r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49282r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49282r=mysqlcfg
#49280 [Opn]: ext/mysqlnd: Not possible to detect mysqlnd in php
ID: 49280 Updated by: j...@php.net -Summary: Not possible to detect mysqlnd in php Reported By: ar at ez dot no Status: Open -Bug Type: MySQLi related +Bug Type: Feature/Change Request Operating System: * PHP Version: 5.3.0 New Comment: p: is allowed always since PHP 5.3.0. You only get a warning when someone has disabled persistent connections with mysqli.allow_persistent ini option. You don't need to know whether it's mysqlnd or libmysql that is used. And you really should be checking if mysql*.allow_persistent is on or off anyway. :) Previous Comments: [2009-08-17 14:53:12] ar at ez dot no Hi jani! I'm not trying to workaround anything, its just that Persistent Connections are only supported on mysqli when mysqlnd is used. So it doesn't help to detect php version using PHP_VERSION, as the end user might have mysqlnd disabled / not compiled in. It is possible to detect it by by using function_exists. But since you guys might add those extra mysqlnd functions to the other mysql driver as well, that is not reliable not to mention clean. see: http://no.php.net/mysqli.mysqlnd For what I'm trying to do: eZ Publish like other php projects abstracts things, one of those is Persistent connection, witch is abstracted into a ini setting (changeable in admin gui). So I need to prepend p: IF user has mysqlnd, or trow a warning about unsupported setting. [2009-08-17 14:30:15] j...@php.net So you want to circumvent a bug by adding a constant instead of fixing the actual bug? Can you please explain WHAT does not work like it should when you have enabled mysqlnd..? [2009-08-17 14:21:35] ar at ez dot no Seems to be possible with something like this as well: strpos( mysqli_get_client_info(), 'mysqlnd ' ) !== false But constant would still be a bit cleaner. [2009-08-17 14:10:00] ar at ez dot no Description: There doesn't seem to be possible to cleanly* detect that mysqlnd is currently in use. * Constant would be nice, preferably already in 5.3.next Detecting by presence off 'mysqli_fetch_all' or other functions is not exactly clean. Use case: Disabling / enabling Persistent Connections based on application specific settings. See: http://issues.ez.no/IssueView.php?Id=15315 -- Edit this bug report at http://bugs.php.net/?id=49280edit=1
#49280 [Opn]: ext/mysqlnd: Not possible to detect mysqlnd in php
ID: 49280 User updated by: ar at ez dot no Reported By: ar at ez dot no Status: Open Bug Type: Feature/Change Request Operating System: * PHP Version: 5.3.0 New Comment: And you really should be checking if mysql*.allow_persistent is on or off anyway We don't need hide php warnings, so if php trows a understandable warning in such a case, then that would be sufficient. So, for my use case this is not valid anymore then, Thanks;) But as long as mysqlnd behaves differently then the old mysql client, I would vote for such a constant anyway. Or you can close with reference to the first comment(2:21) on how to detect mysqlnd if you absolutely need to know about it in code. Previous Comments: [2009-08-17 17:18:45] j...@php.net p: is allowed always since PHP 5.3.0. You only get a warning when someone has disabled persistent connections with mysqli.allow_persistent ini option. You don't need to know whether it's mysqlnd or libmysql that is used. And you really should be checking if mysql*.allow_persistent is on or off anyway. :) [2009-08-17 14:53:12] ar at ez dot no Hi jani! I'm not trying to workaround anything, its just that Persistent Connections are only supported on mysqli when mysqlnd is used. So it doesn't help to detect php version using PHP_VERSION, as the end user might have mysqlnd disabled / not compiled in. It is possible to detect it by by using function_exists. But since you guys might add those extra mysqlnd functions to the other mysql driver as well, that is not reliable not to mention clean. see: http://no.php.net/mysqli.mysqlnd For what I'm trying to do: eZ Publish like other php projects abstracts things, one of those is Persistent connection, witch is abstracted into a ini setting (changeable in admin gui). So I need to prepend p: IF user has mysqlnd, or trow a warning about unsupported setting. [2009-08-17 14:30:15] j...@php.net So you want to circumvent a bug by adding a constant instead of fixing the actual bug? Can you please explain WHAT does not work like it should when you have enabled mysqlnd..? [2009-08-17 14:21:35] ar at ez dot no Seems to be possible with something like this as well: strpos( mysqli_get_client_info(), 'mysqlnd ' ) !== false But constant would still be a bit cleaner. [2009-08-17 14:10:00] ar at ez dot no Description: There doesn't seem to be possible to cleanly* detect that mysqlnd is currently in use. * Constant would be nice, preferably already in 5.3.next Detecting by presence off 'mysqli_fetch_all' or other functions is not exactly clean. Use case: Disabling / enabling Persistent Connections based on application specific settings. See: http://issues.ez.no/IssueView.php?Id=15315 -- Edit this bug report at http://bugs.php.net/?id=49280edit=1
#49248 [Asn-Csd]: undefined reference to `zlib_globals'
ID: 49248 Updated by: j...@php.net Reported By: e dot ehritt at web dot de -Status: Assigned +Status: Closed Bug Type: Compile Failure Operating System: * PHP Version: 5.* Assigned To: jani Previous Comments: [2009-08-17 17:30:33] s...@php.net Automatic comment from SVN on behalf of jani Revision: http://svn.php.net/viewvc/?view=revisionrevision=287423 Log: - Fixed bug #49248 by fixing bug #48994 properly [2009-08-17 13:15:31] j...@php.net And this is 5.* only, HEAD has better output handling. [2009-08-17 11:28:35] j...@php.net Related to fix for bug #48994 [2009-08-16 05:50:52] ka...@php.net Jani, you changed to use ZLIBG in main, but unless thats exported it cannot be used when its built shared. So we need to either export it or just skip this part in main/ if zlib is shared. [2009-08-14 00:07:02] e dot ehritt at web dot de Description: $ export CFLAGS=-march=athlon64 -O3 -pipe -fstack-protector -fstack-protector-all export EXTENSION_DIR=/home/eddi/opt/php/5.3.0/lib ./configure --prefix=/home/eddi/opt/php/5.3.0 --mandir=/home/eddi/opt/man --build=x86_64-pc-linux-gnu --with-config-file-path=/home/eddi/opt/conf --with-zend-vm=GOTO --disable-all --with-bz2=shared --with-curl=shared --with-curlwrappers --with-gd=shared --with-gettext=shared --with-iconv=shared --with-openssl=shared --with-regex=shared --with-xmlrpc=shared --with-xsl=shared --with-zlib=shared --enable-bcmath=shared --enable-calendar=shared --enable-ctype=shared --enable-dom=shared --enable-exif=shared --enable-fileinfo=shared --enable-filter=shared --enable-ftp=shared --enable-hash=shared --enable-libxml=shared --enable-pcntl=shared --enable-phar=shared --enable-posix=shared --enable-shmop=shared --enable-simplexml=shared --enable-soap=shared --enable-sockets=shared --enable-sysvmsg=shared --enable-sysvsem=shared --enable-sysvshm=shared --enable-tokenizer=shared --enable-wddx=shared --enable-xml=shared --enable-xmlreader=shared --enable-xmlwriter=shared --enable-zip=shared --enable-sigchild --enable-cgi --disable-short-tags $ make /dev/null /home/eddi/opt/src/php5.3-200908132230/ext/date/php_date.c: In function 'date_format': /home/eddi/opt/src/php5.3-200908132230/ext/date/php_date.c:1058: warning: incompatible implicit declaration of built-in function 'llabs' /home/eddi/opt/src/php5.3-200908132230/main/streams/cast.c: In function '_php_stream_cast': /home/eddi/opt/src/php5.3-200908132230/main/streams/cast.c:222: warning: cast to pointer from integer of different size /home/eddi/opt/src/php5.3-200908132230/main/streams/cast.c:225: warning: cast to pointer from integer of different size /home/eddi/opt/src/php5.3-200908132230/Zend/zend_objects.c: In function 'zend_objects_destroy_object': /home/eddi/opt/src/php5.3-200908132230/Zend/zend_objects.c:95: warning: assignment discards qualifiers from pointer target type main/.libs/SAPI.o: In function `sapi_send_headers': SAPI.c:(.text+0x1fca): undefined reference to `zlib_globals' collect2: ld returned 1 exit status make: *** [sapi/cgi/php-cgi] Error 1 Reproduce code: --- $ gcc -v Using built-in specs. Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.3.2-r3/work/gcc-4.3.2/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.2 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.2 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.2/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.2/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-multilib --enable-libmudflap --disable-libssp --enable-libgomp --disable-libgcj --enable-languages=c,c++,treelang,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.3.2-r3 p1.6, pie-10.1.5' Thread model: posix gcc version 4.3.2 (Gentoo 4.3.2-r3 p1.6, pie-10.1.5) $ ld -v GNU ld (GNU Binutils) 2.18 -- Edit this bug report at http://bugs.php.net/?id=49248edit=1
#41888 [Opn-Csd]: Segfault when attempting to update PDO LOB column in a stream wrapper
ID: 41888 Updated by: j...@php.net Reported By: hans at velum dot net -Status: Open +Status: Closed Bug Type: PDO related Operating System: Gentoo Linux PHP Version: 5.2.4 Assigned To: iliaa Previous Comments: [2009-06-16 20:09:34] paj...@php.net closed [2009-06-16 20:06:21] hans at velum dot net Indeed - this appears to be fixed in latest PHP 5.2.x release. Thanks! [2008-01-14 20:53:04] hans at velum dot net Any idea when this issue might get fixed? This is a big deal to us, since this bug prevents us from swapping out filesystem-based storage with a db-storage engine. [2007-10-01 20:04:40] hans at velum dot net Updating version to reflect that problem is still present in 5.2.4 [2007-09-06 13:40:07] hans at velum dot net Note, here is some revised reproduce code (there was a bug in the original code such that it was creating two DB connections): http://pastebin.com/f40fa427d Thanks! 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/41888 -- Edit this bug report at http://bugs.php.net/?id=41888edit=1
#44639 [Opn]: PDO quotes integers in prepared statement
ID: 44639 Updated by: j...@php.net Reported By: jgauld at blueyonder dot co dot uk Status: Open Bug Type: PDO related Operating System: WinXP -PHP Version: 5.2.5 +PHP Version: 5.2.10 New Comment: But you didn't bother updating the version field. Done now.. Previous Comments: [2009-07-21 00:30:49] whistl0r+php at googlemail dot com Hi, this bug is still present in the current PHP version. Tested with PHP 5.2.10 stable and snapshot on Windows. MySQL client api: 5.1.35 [2008-10-21 11:59:03] jgauld at blueyonder dot co dot uk Tried windows snapshot as suggested (5.2.7RC2-dev), but no joy. Result is same, ie: select * from my_table where id'13' If it helps, phpinfo() reports: PDO Driver for MySQL, client library version5.0.51a [2008-10-21 11:27:05] j...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2008-07-03 15:17:35] u...@php.net This is not a driver issue. Its the PDO SQL driver messing up SQL statements. [2008-06-12 13:42:35] dobamail at gmail dot com Hi. PDO::MySQL The code: $stmt = $db-prepare(' SELECT id, hu_name, ord FROMproducts ORDER BY ord DESC, hu_name LIMIT :offset, :limit '); $stmt-bindValue(':offset', ($offset*$limit)); $stmt-bindValue(':limit', $limit); $stmt-execute(); It is work on: - PHP Version 5.2.0-8+etch11; - PDO Driver for MySQL, client library version 5.0.32 - MySQL version: 5.0.32-Debian_7etch5-log Not work on: - PHP Version 5.2.3-1ubuntu6.3 - PDO Driver for MySQL, client library version 5.0.45 - 5.0.45-Debian_1ubuntu3.3 I hope this help you. Best regards. 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/44639 -- Edit this bug report at http://bugs.php.net/?id=44639edit=1
#48614 [Opn-Asn]: Loading pdo_sqlite.so fails: undefined symbol: sqlite3_libversion
ID: 48614 Updated by: j...@php.net Reported By: kaspernj at gmail dot com -Status: Open +Status: Assigned Bug Type: PDO related Operating System: Ubuntu Jaunty PHP Version: 5.3.0RC4 -Assigned To: +Assigned To: scottmac Previous Comments: [2009-07-09 18:18:07] dkepplinger at gmail dot com I have the same problem with PHP 5.3 on Debian 5.0.2 when loading the pdo_sqlite.so extension in the config file. [2009-06-23 07:18:49] dominics at gmail dot com I can reproduce this bug (Debian Lenny) with the following minimal configure line: ./configure --with-zlib --enable-pdo=shared --with-sqlite=shared --with-pdo-sqlite=shared For now, not building PDO as shared seems to be a workaround. [2009-06-20 16:41:46] kaspernj at gmail dot com sqlite3.so loads fine. It does not help to load pdo_sqlite.so afterwards though - getting the exact same error. Here is what I did: #!/opt/php53/bin/php ?php dl(gd.so); dl(sqlite3.so); dl(pdo.so); dl(pdo_sqlite.so); echo(Hejsa\n); ? [2009-06-20 16:35:43] scott...@php.net If you load sqlite3.so first does it work? [2009-06-20 13:19:49] kaspernj at gmail dot com Thank you for responding. I used the following configure-line: ./configure --with-mysql=shared --with-gd=shared --with-pgsql=shared --enable-pcntl=shared --with-gettext=shared --with-mysqli=shared --with-imap=shared --with-mcrypt=shared --with-kerberos --with-imap-ssl --with-sqlite=shared --enable-sockets=shared --with-pdo-mysql=shared --with-pdo-sqlite=shared --enable-ftp=shared --enable-pdo=shared --with-pdo-pgsql=shared --enable-sockets=shared --enable-cli --disable-cgi --prefix=/opt/php53 --with-ldap=shared --with-pear=shared --disable-debug --with-bz2=shared --with-iconv=shared --with-regex=shared --enable-xml=shared --enable-dom=shared --with-xmlrpc=shared --with-mhash=shared --with-unixODBC=shared,/usr --enable-mbstring=shared --enable-xmlreader=shared --with-sqlite3=shared 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/48614 -- Edit this bug report at http://bugs.php.net/?id=48614edit=1
#49206 [Opn-Asn]: PDO SQLite support for ATTR_FETCH_TABLE_NAMES and getColumnMeta fix
ID: 49206 Updated by: j...@php.net Reported By: patchnow at gmail dot com -Status: Open +Status: Assigned Bug Type: PDO related Operating System: Windows PHP Version: 5.3.0 Assigned To: scottmac Previous Comments: [2009-08-10 09:32:33] patchnow at gmail dot com Description: Patch for adding ATTR_FETCH_TABLE_NAMES support for PDO SQLite. http://news.php.net/php.internals/45254 Fixes SQLite Bug 42589 for windows builds too, getColumnMeta didn't return the table name. -- Edit this bug report at http://bugs.php.net/?id=49206edit=1
#49236 [Opn-Csd]: Missing PHP_SUBST(PDO_MYSQL_SHARED_LIBADD)
ID: 49236 Updated by: j...@php.net Reported By: xueron at xueron dot com -Status: Open +Status: Closed Bug Type: PDO related Operating System: CentOS 5.3 PHP Version: 5.3.0 Previous Comments: [2009-08-17 17:57:41] s...@php.net Automatic comment from SVN on behalf of jani Revision: http://svn.php.net/viewvc/?view=revisionrevision=287424 Log: - Fixed bug #49236 (Missing PHP_SUBST(PDO_MYSQL_SHARED_LIBADD)). [2009-08-12 13:05:55] xueron at xueron dot com Description: [r...@cvs pdo_mysql]# pwd /home/src/php-5.3.0/ext/pdo_mysql [r...@cvs pdo_mysql]# ./configure --with-php-config=/home/amos/bin/php-cconfig --with-pdo-mysql=/home/amos --with-zlib-dir=/usr . [r...@cvs pdo_mysql]# make . /src/php-5.3.0/ext/pdo_mysql/modules pdo_mysql.lo mysql_driver.lo mysql_statement.lo cc -shared .libs/pdo_mysql.o .libs/mysql_driver.o .libs/mysql_statement.o -Wl,-soname -Wl,pdo_mysql.so -o .libs/pdo_mysql.so creating pdo_mysql.la Here, I found pdo_mysql.so was not linked with libmysqlclient_r.so. So I checked the Makefile, and compared whit my working version(5.2.10), I found, PDO_MYSQL_SHARED_LIBADD was missed in the Makefile. After I add: PDO_MYSQL_SHARED_LIBADD = -Wl,-rpath,/home/amos/lib/ -L/home/amos/lib/ -Wl,-rpath,/home/amos/lib/mysql -L/home/amos/lib/mysql -lmysqlclient -lz -lcrypt -lnsl -lm -lssl -lcr ypto to Makefile and remake, it works. -- Edit this bug report at http://bugs.php.net/?id=49236edit=1
#49251 [Opn-Ver]: wrong object created
ID: 49251 Updated by: j...@php.net Reported By: ies_clan at hotmail dot com -Status: Open +Status: Verified Bug Type: SimpleXML related -Operating System: Windows XP SP3 +Operating System: * -PHP Version: 5.3.0 +PHP Version: 5.*, 6 (2009-08-17) New Comment: Quite weird indeed. And verified in all branches. Previous Comments: [2009-08-14 13:49:22] ies_clan at hotmail dot com Description: if u try to create a new object from an simple xml-objekt-property you got an simple xml object :( Reproduce code: --- class test {} $Xml = new SimpleXMLElement('rootclassnamestdclass/classname/root'); $XmlClass = new $Xml-classname('root /'); print_r($XmlClass); $MyClass = new stdclass(); $MyClass-classname = 'test'; $stdclass = new $MyClass-classname(); print_r($stdclass); Expected result: stdclass Object ( ) test Object ( ) Actual result: -- SimpleXMLElement Object ( ) test Object ( ) -- Edit this bug report at http://bugs.php.net/?id=49251edit=1
#49251 [Ver]: wrong object created
ID: 49251 Updated by: j...@php.net Reported By: ies_clan at hotmail dot com Status: Verified Bug Type: SimpleXML related Operating System: * PHP Version: 5.*, 6 (2009-08-17) New Comment: And it only happens with 'new'. Previous Comments: [2009-08-17 18:19:09] j...@php.net Quite weird indeed. And verified in all branches. [2009-08-14 13:49:22] ies_clan at hotmail dot com Description: if u try to create a new object from an simple xml-objekt-property you got an simple xml object :( Reproduce code: --- class test {} $Xml = new SimpleXMLElement('rootclassnamestdclass/classname/root'); $XmlClass = new $Xml-classname('root /'); print_r($XmlClass); $MyClass = new stdclass(); $MyClass-classname = 'test'; $stdclass = new $MyClass-classname(); print_r($stdclass); Expected result: stdclass Object ( ) test Object ( ) Actual result: -- SimpleXMLElement Object ( ) test Object ( ) -- Edit this bug report at http://bugs.php.net/?id=49251edit=1
#49252 [Opn-Fbk]: ext/ldap/config.m4 sasl2 checks wrong
ID: 49252 Updated by: j...@php.net Reported By: crrodriguez at opensuse dot org -Status: Open +Status: Feedback Bug Type: LDAP related Operating System: Linux PHP Version: 5.3SVN-2009-08-14 (SVN) New Comment: It's actually intentional. What configure line did you use when it fails..? The library is passed to the test via the 3rd parameter to PHP_CHECK_LIBRARY() macro and if the ldap library is linked with it, then the test will pass, otherwise it fails. :) Previous Comments: [2009-08-14 14:43:16] crrodriguez at opensuse dot org Description: in ext/ldap/config.m4 there is the following check PHP_CHECK_LIBRARY(ldap, sasl_version, sasl_version symbol is not really found in ldap library but in sasl2, that is correctly added soon after with PHP_ADD_LIBRARY_WITH_PATH(sasl2, $LDAP_SASL_LIBDIR, LDAP_SHARED_LIBADD) I think you mean PHP_CHECK_LIBRARY(sasl2, sasl_version Reproduce code: --- ... Expected result: extension build correctly Actual result: -- failure to build -- Edit this bug report at http://bugs.php.net/?id=49252edit=1
#49265 [Opn-Bgs]: external program execution hangs, process sometimes never exits
ID: 49265 Updated by: j...@php.net Reported By: stefan dot launicke at gate8 dot de -Status: Open +Status: Bogus Bug Type: Program Execution Operating System: Linux 2.6.19 PHP Version: 5.2.10 New Comment: We can only delete the comments. Can't edit initial entry in this version of the bug tracker. Please repost this bug. Previous Comments: [2009-08-15 10:32:36] stefan dot launicke at gate8 dot de I appologize for the double post. For some reason, I cannot edit my submission. Can some admin please delete the first entry? Thank you. [2009-08-15 10:17:26] stefan dot launicke at gate8 dot de Description: When doing a external function call using either passthru(), proc_open() or system(), the external process hangs most of the time. Sometimes it works. Only appears when run through mod_php / apache2. Calling the script in the shell with CLI always works. ps shows: 11606 ?Sl 0:00 /usr/bin/pdftk No errors in any logs, no segfaults. top Please Note: - doing the exact same call in a Perl script running in Apache always works. - calling the perl script which does the funtion call from within php will crash again with ps (passthru example): 11674 ?S 0:00 sh -c cd '/data/usr/inauris.com/tmp' ; /data/usr/inauris.com/tmp/test3.pl 11675 ?S 0:00 /usr/bin/perl -w /data/usr/inauris.com/tmp/test3.pl 11676 ?Sl 0:00 /usr/bin/pdftk /data/usr/inauris.com/management/home/app/pdf... Apache Version: 2.2.11, Worker MPM Reproduce code: --- passthru (/usr/bin/pdftk /data/testin.pdf fill_form /data/workdata output /data/testout.pdf flatten); Expected result: exec return Actual result: -- hang -- Edit this bug report at http://bugs.php.net/?id=49265edit=1
#49265 [Bgs]: external program execution hangs, process sometimes never exits
ID: 49265 Updated by: j...@php.net Reported By: stefan dot launicke at gate8 dot de Status: Bogus Bug Type: Program Execution Operating System: Linux 2.6.19 PHP Version: 5.2.10 New Comment: And please don't post the bug if you can't reproduce it using the preform MPM. Threaded mpms are not supported. Previous Comments: [2009-08-17 18:49:00] j...@php.net We can only delete the comments. Can't edit initial entry in this version of the bug tracker. Please repost this bug. [2009-08-15 10:32:36] stefan dot launicke at gate8 dot de I appologize for the double post. For some reason, I cannot edit my submission. Can some admin please delete the first entry? Thank you. [2009-08-15 10:17:26] stefan dot launicke at gate8 dot de Description: When doing a external function call using either passthru(), proc_open() or system(), the external process hangs most of the time. Sometimes it works. Only appears when run through mod_php / apache2. Calling the script in the shell with CLI always works. ps shows: 11606 ?Sl 0:00 /usr/bin/pdftk No errors in any logs, no segfaults. top Please Note: - doing the exact same call in a Perl script running in Apache always works. - calling the perl script which does the funtion call from within php will crash again with ps (passthru example): 11674 ?S 0:00 sh -c cd '/data/usr/inauris.com/tmp' ; /data/usr/inauris.com/tmp/test3.pl 11675 ?S 0:00 /usr/bin/perl -w /data/usr/inauris.com/tmp/test3.pl 11676 ?Sl 0:00 /usr/bin/pdftk /data/usr/inauris.com/management/home/app/pdf... Apache Version: 2.2.11, Worker MPM Reproduce code: --- passthru (/usr/bin/pdftk /data/testin.pdf fill_form /data/workdata output /data/testout.pdf flatten); Expected result: exec return Actual result: -- hang -- Edit this bug report at http://bugs.php.net/?id=49265edit=1
#47118 [Asn-Csd]: Segmentation fault on ociexecute
ID: 47118 Updated by: s...@php.net Reported By: holger at noefer dot org -Status: Assigned +Status: Closed Bug Type: OCI8 related Operating System: Solaris 8 PHP Version: 5.2.8 Assigned To: sixd New Comment: Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to Open. Again, thank you for your continued support of PHP. --- Duplicate of http://bugs.php.net/bug.php?id=41069 Previous Comments: [2009-06-18 21:13:48] holger at noefer dot org Hi, sorry for my very late response. The workaround to increase oci8.default_prefetch worked for me, sometimes I got an segmenation fault. After that I applied the patch and removed the increased oci8.default_prefetch value from php.ini. The patch works fine and resolved my problem, no segmentation faults seen any more. Thanks for helping with the bug. Best regards, Holger [2009-02-10 19:41:36] s...@php.net If you think it is #41069, you can examine use of Oracle dblinks in your application. The changes in php_oci_statement_set_prefetch() in http://cvs.php.net/viewvc.cgi/pecl/oci8/oci8_statement.c?r1=1.7.2.14.2.28.2.4r2=1.7.2.14.2.28.2.5 are the patch, if you want to test a code fix. If this doesn't help, I'd recommend upgrading OCI8 to 1.3.4 from PECL before we continue investigation. [2009-01-30 18:52:18] holger at noefer dot org Hello, I changed oci8.default_prefetch from 10 to 100. The segmentation faults seems to be fewer than before. Perhaps it is related to this bug? http://bugs.php.net/bug.php?id=41069 Best regards, Holger [2009-01-30 15:04:24] holger at noefer dot org Hello, sorry for the long time I did not respond to the bug but it is hard to aim the bug. The bug seems to appear when I use persistent connections. Here are the default settings in php.ini oci8.default_prefetch = 10 = 10 oci8.max_persistent = -1 = -1 oci8.old_oci_close_semantics = 0 = 0 oci8.persistent_timeout = -1 = -1 oci8.ping_interval = 60 = 60 oci8.privileged_connect = Off = Off oci8.statement_cache_size = 20 = 20 Should the oci8.persistent_timeout be changed? I will try to post some code next week. Best regards, Holger [2009-01-15 21:46:24] s...@php.net Please help narrow down the problem with the aim of supplying a reproducable testcase. Look at patterns in the frequency of crash, the statement(s) that crash, and the environment (machine, environment variables, build options, connection etc) that causes the crash. 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/47118 -- Edit this bug report at http://bugs.php.net/?id=47118edit=1
#49223 [Opn-Csd]: Inconsistency using get_defined_constants(true)
ID: 49223 Updated by: garre...@php.net Reported By: carlos dot ballesteros at softonic dot com -Status: Open +Status: Closed Bug Type: Scripting Engine problem Operating System: win32 only PHP Version: 5.3.1-dev New Comment: This bug has been fixed in SVN. The internal module mhash was improperly registered Previous Comments: [2009-08-17 21:28:23] s...@php.net Automatic comment from SVN on behalf of garretts Revision: http://svn.php.net/viewvc/?view=revisionrevision=287429 Log: - Fix for bug #49223 Inconsistency using get_defined_constants(true) [2009-08-11 19:00:43] j...@php.net Seems to be windows only issue. [2009-08-11 12:59:00] carlos dot ballesteros at softonic dot com It's not working even in the lastest snapshot. C:\dev\php53php -v PHP 5.3.1-dev (cli) (built: Aug 11 2009 10:52:16) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies C:\dev\php53php -rprint_r(get_defined_constants(true)); | more Array ( [mhash] = Array ( [E_ERROR] = 1 ... [2009-08-11 11:29:29] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ 'Core' is correct. Dunno about windows, might be fixed now. Try the snapshot. [2009-08-11 10:43:48] carlos dot ballesteros at softonic dot com Description: Before PHP 5.3, get_defined_constants with a parameter returned the core constants in a key called internal. In PHP5.3 in linux it's returning them as Core key. But in windows it's returned as key mhash. It's pretty weird. It's similar to this bug: http://bugs.php.net/bug.php?id=47549 But at least in windows mhash key is wrong. And about linux, if the key changed from 'internal' to 'Core', I think it should, at least, be specified in the documentation. http://es2.php.net/get_defined_constants Reproduce code: --- print_r(get_defined_constants(true)); Expected result: Array ( [internal] = Array ( [E_ERROR] = 1 [E_RECOVERABLE_ERROR] = 4096 ... Actual result: -- Linux: -bash-3.2# php -rprint_r(get_defined_constants(true)); | more Array ( [Core] = Array ( [E_ERROR] = 1 [E_RECOVERABLE_ERROR] = 4096 ... -bash-3.2# php -v PHP 5.3.0 (cli) (built: Jun 30 2009 21:37:54) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies Windows: C:\php -rprint_r(get_defined_constants(true)); | more Array ( [mhash] = Array ( [E_ERROR] = 1 [E_RECOVERABLE_ERROR] = 4096 ... C:\php -v PHP 5.3.0 (cli) (built: Jun 29 2009 21:55:01) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies -- Edit this bug report at http://bugs.php.net/?id=49223edit=1
#49265 [Bgs]: external program execution hangs, process sometimes never exits
ID: 49265 User updated by: stefan dot launicke at gate8 dot de Reported By: stefan dot launicke at gate8 dot de Status: Bogus Bug Type: Program Execution Operating System: Linux 2.6.19 PHP Version: 5.2.10 New Comment: reproduced with Apache Prefork model. Same behaviour, Previous Comments: [2009-08-17 18:49:51] j...@php.net And please don't post the bug if you can't reproduce it using the preform MPM. Threaded mpms are not supported. [2009-08-17 18:49:00] j...@php.net We can only delete the comments. Can't edit initial entry in this version of the bug tracker. Please repost this bug. [2009-08-15 10:32:36] stefan dot launicke at gate8 dot de I appologize for the double post. For some reason, I cannot edit my submission. Can some admin please delete the first entry? Thank you. [2009-08-15 10:17:26] stefan dot launicke at gate8 dot de Description: When doing a external function call using either passthru(), proc_open() or system(), the external process hangs most of the time. Sometimes it works. Only appears when run through mod_php / apache2. Calling the script in the shell with CLI always works. ps shows: 11606 ?Sl 0:00 /usr/bin/pdftk No errors in any logs, no segfaults. top Please Note: - doing the exact same call in a Perl script running in Apache always works. - calling the perl script which does the funtion call from within php will crash again with ps (passthru example): 11674 ?S 0:00 sh -c cd '/data/usr/inauris.com/tmp' ; /data/usr/inauris.com/tmp/test3.pl 11675 ?S 0:00 /usr/bin/perl -w /data/usr/inauris.com/tmp/test3.pl 11676 ?Sl 0:00 /usr/bin/pdftk /data/usr/inauris.com/management/home/app/pdf... Apache Version: 2.2.11, Worker MPM Reproduce code: --- passthru (/usr/bin/pdftk /data/testin.pdf fill_form /data/workdata output /data/testout.pdf flatten); Expected result: exec return Actual result: -- hang -- Edit this bug report at http://bugs.php.net/?id=49265edit=1
#49274 [Ana]: filter_var() should accept objects without fatal error
ID: 49274 Updated by: paj...@php.net Reported By: cel...@php.net Status: Analyzed Bug Type: Feature/Change Request Operating System: * PHP Version: 5.3SVN-2009-08-16 (SVN) New Comment: http://pastie.org/586442 should do it. I did not not test more than the test case here. Previous Comments: [2009-08-17 13:55:58] paj...@php.net it is indeed valid for all objects but it is still an edge case. A check for IS_OBJECT + tostring() existence could be easy enough and with almost no impact(perf impact is null on the existing application). If you have some time to write one, go ahead. [2009-08-17 13:52:56] cel...@php.net the stdClass was just to illustrate the point, this happens with any object that doesn't have a __toString(). I would imagine it would be easier to check for IS_OBJECT and then see if it implements __toString than to do a custom error handler. The performance should be about the same (dismal). [2009-08-17 13:48:45] paj...@php.net As StdClass has no __toString implementation (obviously), it can't be converted to string. I tend to agree that it should not raise a fatal (recovable error) here as it defeats the main purpose of this API. I'm however not sure it is worth the effort to add custom error handler for this edge case. Patch welcome, it could help to get this edge case solved (I can't work on this exact issue any time soon). [2009-08-17 13:27:50] cel...@php.net ?php var_dump(filter_var(null, FILTER_VALIDATE_INT)); var_dump(filter_var(array(), FILTER_VALIDATE_INT)); var_dump(filter_var('hi', FILTER_VALIDATE_INT)); var_dump(filter_var(1.1, FILTER_VALIDATE_INT)); var_dump(filter_var(fopen('somefile', 'r'), FILTER_VALIDATE_INT)); var_dump(filter_var(1, FILTER_VALIDATE_INT)); var_dump(filter_var('1.0', FILTER_VALIDATE_INT)); ? all work without error. ?php class blah {function __toString(){return '1';}} var_dump(filter_var(new blah, FILTER_VALIDATE_INT)); ? works without error. Only filter_var with an object that doesn't implement __toString fails with an error. Either filter is incorrectly returning false with no error on all of those other random types, or you're wrong, Jani. [2009-08-17 13:13:43] j...@php.net This is not a bug. It's exactly what's supposed to happen. When you pass crap in you get crap out. The language isn't supposed to hold your hand in every corner. 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/49274 -- Edit this bug report at http://bugs.php.net/?id=49274edit=1
#49039 [Fbk]: Can't pass file name with subfolder name 3 characters or less
ID: 49039 Updated by: paj...@php.net Reported By: sant9442 at gmail dot com Status: Feedback Bug Type: CGI related Operating System: win32 only - Windows PHP Version: 5.3.0 Assigned To: pajoye New Comment: There is a difference between junction.exe and mklink and that may cause what we have here. We had to deal with symlink/junction (not under all circumstances) because of some path resolutions issues we have with symlinks, that's not specific to php either. However a regression has been introduced with junctions (with junction.exe) and it will be fixed soon. Previous Comments: [2009-08-15 14:23:02] sant9442 at gmail dot com After reading Mark's article, the man it probably wrote MKLINK from his junction.exe/c work, for a command link too, I have a recommendatin for PHP. Since the new logic is for VISTA/W7/2008, I would highly suggest that PHP a) either no bother with this stuff, b) make it optional or C) make sure it doesn't enforce VISTA/W7/2008 hard vs soft links in its design for general Windows operation. It needs to take the lower ground with this or not at all. Then again, I don't see why it even cares about altering the intent of PHP developers or web operators with the scripts file names passed. Links are suppose to be outside an PHP engine IMV. [2009-08-15 14:06:53] sant9442 at gmail dot com I have 5 bucks, Microsoft MKLINK for VISTA/2008/W7 was written using Mark's Junction.C code as a basis. g Check this out: http://technet.microsoft.com/en-us/magazine/2007.02.vistakernel.aspx Also, why would PHP even came for this? I just don't why. [2009-08-15 13:57:53] sant9442 at gmail dot com Good show. I have follow up with your links and also reup on junctions and moint points technical details. I have exclusively use SysInternal.com junction.exe (comes with C source at the web site). I'm sure you know the infamous Mark Russinovich. No need to elaborate on this industy guru, So I might suggest to explore PHP windows junction operations with junction.exe as I am pretty sure (I trust) Mark's logics matches what is correctly technically expected under windows. Put it this way, odds are good he is doing right. :-) I do have a question? why does PHP even care about symbolic links? Whats the purpose? Why not just use the input file names as passed?, like it is expected? Let the file system deal with it. Thats its purpose. PHP seems to be breaking it apart to revert and obtain the physical path. When I first saw that, I thought maybe it was doing for security purposes. [2009-08-15 13:41:14] mormegil at centrum dot cz One more detail: if the link has been created using the built-in MKLINK command, PHP seems to work correctly (since MKLINK fills in both print name and substitute name), both for directory junction, and for a symbolic link. Therefore, a workaround for this bug is to recreate the problematic reparse points using mklink (if you are on Vista/W2008/W7, XP did not have the command). [2009-08-15 13:18:32] mormegil at centrum dot cz I hit this problem and decided to investigate a bit. The final result is that the reparse logic in tsrm_realpath_r is broken, or more specifically, incomplete. The problem (and the cause why some people are not able to reproduce the bug) is that there are more ways how to create a mount point on Windows, and it seems the exact representation of the parse point differs among those representations. tsrm_realpath_r resolves reparse points using the print name of the reparse point. However, it seems that in my case, the reparse point does not have a print name at all: SubstituteNameOffset 0x unsigned short SubstituteNameLength 0x0030 unsigned short PrintNameOffset 0x0032 unsigned short PrintNameLength 0x unsigned short ReparseTarget 0x002a3a70 \??\c:\temp\phptests\to\ wchar_t [1] As you can see, the reparse point only has its substitute name filled. I am used to creating reparse points using a simple MAKELINK.EXE utility (which I downloaded from http://www.codeproject.com/KB/winsdk/junctionpoints.aspx, I believe). This utility does not fill the print name, but the reparse point seems to work fine in all other programs, so this is probably a valid thing to do, and PHP should be also able to handle that. Read http://brainrack.wordpress.com/2008/05/28/broken-and-ill-documented-api-for-windows-mount-points/ for more information on the various forms of mountpoints. (OBTW: You should probably use IsReparseTagMicrosoft, too.)
#48182 [Asn]: asynchronous socket connection over ssl fails entirely
ID: 48182 Updated by: srina...@php.net Reported By: frase at cs dot wisc dot edu Status: Assigned Bug Type: OpenSSL related Operating System: * PHP Version: 5.2.11RC1 Assigned To: srinatar New Comment: thanks for verifying it. let me try this again with php 5.2.11rc1 and see why it is happening (again). Previous Comments: [2009-08-14 13:56:38] frase at cs dot wisc dot edu To clarify, I tested the posted patch by recompiling 5.3.0 on Ubuntu Linux, and the fix worked. I was not able to test the patch in 5.2.10 on Windows as I have no suitable build environment. The posted 5.2.11RC1 binaries (under Apache 2.2.11) now exhibit this new problem. [2009-08-14 13:49:53] frase at cs dot wisc dot edu I'm re-opening this bug as the fix appears not to work in 5.2.11RC1. With the same testing code as in the original report, when connecting synchronously, all is well. But when connecting asynchronously I get these warnings: Warning: stream_socket_client() [function.stream-socket-client]: SSL: The operation completed successfully. in test-async-ssl.php on line 14 Warning: stream_socket_client() [function.stream-socket-client]: Failed to enable crypto in test-async-ssl.php on line 14 Warning: stream_socket_client() [function.stream-socket-client]: unable to connect to ssl://91.189.90.211:443 (Unknown error) in test-async-ssl.php on line 14 Line 14 is of course the stream_socket_client() call. Additionally, after these warnings, $errno contains 10035 and $errstr is empty. [2009-07-28 19:34:15] srina...@php.net This bug has been fixed in SVN. 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. Committed revision 286465. [2009-07-10 13:38:01] frase at cs dot wisc dot edu The supplied patch does fix the problem in 5.3.0 on Linux; I have no Windows build environment so I can't test it there but can't see why it wouldn't also work. Since the patch was to OpenSSL I've changed the category back. Many thanks! [2009-07-09 21:53:03] sriram dot natarajan at gmail dot com better still, here is the patch (more readable format) http://pastebin.org/805 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/48182 -- Edit this bug report at http://bugs.php.net/?id=48182edit=1
#49144 [Asn-Csd]: import of schema from different host transmits original authentication details
ID: 49144 Updated by: dmi...@php.net Reported By: david dot zuelke at bitextender dot com -Status: Assigned +Status: Closed Bug Type: SOAP related Operating System: Mac OS X 10.5.7 PHP Version: 5.3.0 Assigned To: dmitry New Comment: This bug has been fixed in SVN. 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: [2009-08-17 18:23:49] s...@php.net Automatic comment from SVN on behalf of dmitry Revision: http://svn.php.net/viewvc/?view=revisionrevision=287425 Log: Fixed bug #49144 (import of schema from different host transmits original authentication details) [2009-08-03 16:32:54] david dot zuelke at bitextender dot com Description: Say I have a webservice at foo.com, described by http://foo.com/wsdl, and it's protected by HTTP Basic Authentication. If this WSDL inside the XML Schema definitions imports another schema from a different host, then the HTTP Basic Authentication credentials will be transmitted to this host, too, resulting in the credentials being inadvertently leaked to a third party. An example is the importing of W3C's XML schema located at http://www.w3.org/2001/xml.xsd The original issue was reported on the s...@lists.php.net list and brought to internals@'s attention here: http://thread.gmane.org/gmane.comp.php.devel/58024 Reproduce code: --- .phpt: http://pastie.org/569897 -- Edit this bug report at http://bugs.php.net/?id=49144edit=1
#49276 [Bgs]: Sybase 15 incorrect library name references
ID: 49276 User updated by: andy at networkjabber dot com Reported By: andy at networkjabber dot com Status: Bogus Bug Type: Sybase-ct (ctlib) related Operating System: Fedora Core 9 PHP Version: 5.3.0 New Comment: Hi. Thanks for the quick reply. I can confirm that the patch works correctly and PHP compiles correctly with the specified directives to build Sybase ASE support. Perhaps it would be worth adding an extra autoconf argument in subsequent PHP releases for Sybase ASE versions previous to 12.5 and those later? i.e. --with-sybase-ct-oldlib or --with-sybase-ct-newlib, for example. Many thanks, Andy Previous Comments: [2009-08-17 09:36:09] j...@php.net Bug #36516 was marked as being bogus because it was duplicate of bug #45357 and both didn't get any feedback when asked to test this patch: http://sitten-polizei.de/php/sybase-configm4.diff So please apply the patch, run ./buildconf --force and see if it works then. [2009-08-17 08:56:52] andy at networkjabber dot com Description: This problem was originally logged on 24/2/2006 under #36516, but marked as bogus. However, the problem still exists. Sybase have changed the library names of 4 of their ASE libraries: libsybcs, libsybct, lsybcomn and lsybintl. The default automake profile references these as -lcs -lct -lcomn -lintl so the compile fails with libraries being reported as missing. Both ./configure and ./ext/sybase_ct/config.m4 need to be editied so that these references are -lsybcs -lsybct -lsybcomn -lsybsybintl. After these changes are made all compiles correctly. -- Edit this bug report at http://bugs.php.net/?id=49276edit=1
#48668 [Com]: foreach with array will coredump php
ID: 48668 Comment by: sriram dot natarajan at gmail dot com Reported By: dmda at yandex dot ru Status: Critical Bug Type: Reproducible crash Operating System: Solaris PHP Version: 5.3.0RC4 Assigned To: dsp New Comment: i have been looking into this issue over the week end and here is what i found. a) this is memory alignment issue and nothing to do with compilers or optimizations. hence, bug - 47230 (http://bugs.php.net/bug.php?id=47230edit=1) should be closed as duplicate of this bug. now, why this is happening ? here is a rough and crude explanation : with php 5.3, addresses returned from zend_vm_stack_top , _get_zval_ptr_tmp etc are not 8 byte aligned. hence, accessing the 8 byte data results in crashes. i haven't come up with a solution yet. i will look more into this after next week. Previous Comments: [2009-08-10 21:44:07] dmda at yandex dot ru by any chance, the submitter built this php5.3 on one machine and ran it on another machine ? no. currently, php 5.3 build process includes -xtarget=native within the configure flags when used with sun studio compiler. I used only gcc which is available from sunfreeware. It did never create any problems with various applications I compiled with it, including php versions from 4.0.6 up to 5.2.10. [2009-08-10 21:24:58] srina...@php.net by any chance, the submitter built this php5.3 on one machine and ran it on another machine ? currently, php 5.3 build process includes -xtarget=native within the configure flags when used with sun studio compiler. this would mean that this compiled program will not work on different class of sparc machines (unless recompiled for that platform) for e.g, if some one currently built php 5.3 on ultra-sparc III+/IV+ based system (like v410, v220, v880 etc) then if they try to run the same on older hardware with chips like sparc II+ hardware, then they might run into crash. [2009-07-28 14:25:31] d...@php.net PHP is broken on Sparc (and possible every other processor that requires memalignment) at the moment [2009-06-26 15:42:15] d...@php.net It looks like this is a memalign issue. PHP 5.3.0 is now build with flags to avoid the crash. I assign the bug to me to provide a proper fix for the issue for 5.3.1 [2009-06-24 12:21:10] johan...@php.net When using --enable-dbug the code works, without --enable-debug the code fails, maybe that's the reason why I didn't see this before. uname -a SunOS techra46 5.8 Generic_117350-54 sun4u sparc SUNW,Sun-Fire-V210 The issue seems to be independent from the compiler but in some way system dependent, another similar box worked for me. 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/48668 -- Edit this bug report at http://bugs.php.net/?id=48668edit=1
#49283 [NEW]: date('Y') display error
From: ht0315 at gmail dot com Operating system: Solaris 10 sparc PHP version: 5.2.10 PHP Bug Type: Date/time related Bug description: date('Y') display error Description: date('Y') display error, print: Reproduce code: --- ?php echo date('y-m-d H:i:s'); echo date('Y-m-d H:i:s'); echo date('ymd'); echo date('Y'); echo date('y'); echo time(); echo date('Y-m-d', time()); echo date('y-m-d', time()); ? Expected result: 09-08-18 13:18:36 2009-08-18 13:18:36 090818 2009 09 1250572716 2009-08-18 09-08-18 Actual result: -- 09-08-18 13:18:13 -08-18 13:18:13 090818 09 1250572693 -08-18 09-08-18 -- Edit bug report at http://bugs.php.net/?id=49283edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49283r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49283r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49283r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49283r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49283r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49283r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49283r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49283r=needscript Try newer version: http://bugs.php.net/fix.php?id=49283r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49283r=support Expected behavior: http://bugs.php.net/fix.php?id=49283r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49283r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49283r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49283r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49283r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49283r=dst IIS Stability: http://bugs.php.net/fix.php?id=49283r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49283r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49283r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49283r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49283r=mysqlcfg