#46601 [NEW]: E_RECOVERABLE_ERROR for Call to a member function on a non-object
From: bugs dot php dot net-V29nHf1_z-nsp at cvogt dot org
Operating system:
PHP version: 5.2.6
PHP Bug Type: Feature/Change Request
Bug description: E_RECOVERABLE_ERROR for Call to a member function on a
non-object
Description:
Calling a method on a non-object results in a non catchable fatal error,
that cannot be handled by an error_handler. It would be great if it would
be a catchable fatal error instead. This would e.g. make possible to send
an e-mail to the developers in case of such an error.
When using object-orientation heavily, a program bug can easily result in
an uninitialized or wrongly initialized variable, currently leading to a
fatal error. Being able to handle this error case would be a great
improvement for quality control.
I hope the implementation of PHP allows such a change.
This request is similar to http://bugs.php.net/bug.php?id=40587 .
In case this request is rejected, please attach a short reason.
Reproduce code:
---
set_error_handler( create_function('$code','echo error handler called
($code)\n;') );
$o = NULL;
$o-method();
echo end of script\n;
Expected result:
error handler called (4096)
end of script
Actual result:
--
Fatal error: Call to a member function method() on a non-object
--
Edit bug report at http://bugs.php.net/?id=46601edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=46601r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=46601r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=46601r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=46601r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=46601r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=46601r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=46601r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=46601r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=46601r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=46601r=support
Expected behavior:
http://bugs.php.net/fix.php?id=46601r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=46601r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=46601r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=46601r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46601r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=46601r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=46601r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=46601r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=46601r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=46601r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=46601r=mysqlcfg
#44994 [Com]: exec() produces zombie processes on Windows, hangs Apache
ID: 44994 Comment by: bernd dot ebert at gmx dot net Reported By: dbarrett at vistaprint dot com Status: Assigned Bug Type: Program Execution Operating System: Windows 2003 Server, 64-bit PHP Version: 5.2.6 Assigned To: pajoye New Comment: Same Problem here with an commandline-script calling other php-commandline-scripts. It seems to happen more frequently if you have a lot of exec-calls. Previous Comments: [2008-08-19 02:58:37] jkflash at gmail dot com Sorry, I take that last comment back, it still hangs annoyingly intermittently with shell_exec as well. It's a killer :( [2008-08-13 01:08:19] jkflash at gmail dot com PS: shell_exec() DOES seem to work without hanging on my setup, but none of the others. [2008-08-12 23:50:58] jkflash at gmail dot com I am experiencing this same problem with PHP 5.2.1 running on IIS as an ISAPI module on Windows Server 2003 R2 SP2. Intermitently (a handful of times in a hundred) a process started with exec() will appear to complete ok but remain running in a zombie state. The IIS worker process that created the process will not respond to any further requests. I need to either open a new client browser or kill the worker process. I get the same result with system, passthru, p_open and proc_open. [2008-07-29 15:03:40] nobody at dontsendmespam dot com i can reproduce this problem on a debian server with apache2 and php5.2.6 running as fcgi [2008-07-23 02:02:29] efesar at gmail dot com I just upgraded from PHP 5.1.2 to 5.2.6, and this exact problem happens to me. The exec and shell_exec used to work, and now they don't. They hang the php process, and every subsequent call to exec produces a lost cmd.exe ... Incidentally passthru() causes the same behavior. Maybe it has something to do with the rotatelogs.exe ... somebody earlier mentioned that it was waiting on c:\Apache2\logs\error.log ... So, basically, we can't run any system calls whatsoever via PHP. I don't want to use a COM object, because I like portable code ... but that might be the best step until this bug is fixed. 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/44994 -- Edit this bug report at http://bugs.php.net/?id=44994edit=1
#42886 [Asn-Ana]: openssl_x509_checkpurpose returns int(0) on valid public certificate
ID: 42886
Updated by: [EMAIL PROTECTED]
Reported By: tokul at users dot sourceforge dot net
-Status: Assigned
+Status: Analyzed
Bug Type: OpenSSL related
Operating System: Linux Debian Etch
PHP Version: 5CVS-2008-11-01
Assigned To: pajoye
New Comment:
It seems to be a bug in the openssl directly. I have tried with many
different certs and many failed (including the one available in the
openssl's demo directory).
I have to work on other things now, the fix may require to duplicate
the x509_verify_cert code (partially or completely).
tested with 0.98g and 0.9.8i
Previous Comments:
[2008-11-01 21:13:07] tokul at users dot sourceforge dot net
php 5.2-200811011530
Test result is the same. It is impossible to verify purpose of
certificate, because function returns integer value which is evaluated
as false even when certificate can be used for SMIME signatures.
I don't know options that Thawte used to generate certificate. I've
accepted default options with 2048-bit encryption for Mozilla
Firefox/Thunderbird.
Here goes already expired certificate used for initial bug report.
-BEGIN CERTIFICATE-
MIIC8DCCAlmgAwIBAgIQS8GxvbV7pghz0FD/I7rVVjANBgkqhkiG9w0BAQUFADBi
MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg
THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg
Q0EwHhcNMDcwMjI0MDYyMzA0WhcNMDgwMjI0MDYyMzA0WjBNMR8wHQYDVQQDExZU
aGF3dGUgRnJlZW1haWwgTWVtYmVyMSowKAYJKoZIhvcNAQkBFht0b2t1bEB1c2Vy
cy5zb3VyY2Vmb3JnZS5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDQALcUK5moBKz5tHqYcquqb8seEKgzDbFJ3Nko8VEyVy1vnwKtHkNeXuMv1mbH
2dhkvI2JtWpNte36bzLErQHzZhnehAdRb3RIlLrASxkn4btidkWasYjqhtMI1sGL
D+7wFdC4rSfdYwRUto8zrB5FeoNakJre8gmljqwm18fh5ZMsiWboXdKVVCa8ALBk
P5dZ7gYElfNj3FJSjqo0Efs5yQn8EsY+uDNTH+y8HE5Sqq0mkuLw/7WIO5PCsQAF
xTsEo2dqnj3us9KGgNGkR4JRp17NPfNofLs26w7H2n3oAmjMaM51U5lpPOSh0Nm7
uwrpsWnE84Jm2I/9WhhuSOEJAgMBAAGjODA2MCYGA1UdEQQfMB2BG3Rva3VsQHVz
ZXJzLnNvdXJjZWZvcmdlLm5ldDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUA
A4GBAJlmrYGSeE00IK7WR+05BT0g6YigfIoKLbeTJu25oVHN8dBLU0Jjx5KZRfZQ
BCt/8CVBNxNwwKRQnQ36M4Hq0YLa+bBYq3pJPbL62Ffj7mLHhDkFvJw/sgQ1I7jH
URvzt58Hw3B34wEHzqnzcsFOPxNZN3aU4BTnbUBTUjkVVpuZ
-END CERTIFICATE-
[2008-10-31 08:49:37] [EMAIL PROTECTED]
Please provide a sample certificate to reproduce this problem or the
values you used to create a similar certificate.
[2007-10-08 10:52:55] tokul at users dot sourceforge dot net
Description:
According to last chapter in openssl_x509_checkpurpose() manual
function should return true, false or int(-1). Synopsis line shows that
function returns integer.
If I check public certificate file with OpenSSL binary (openssl x509
-purpose -in certfile.pem), it shows purposes as
SSL client : Yes
SSL client CA : No
SSL server : Yes
SSL server CA : No
Netscape SSL server : Yes
Netscape SSL server CA : No
S/MIME signing : Yes
S/MIME signing CA : No
S/MIME encryption : Yes
S/MIME encryption CA : No
CRL signing : Yes
CRL signing CA : No
Any Purpose : Yes
Any Purpose CA : Yes
OCSP helper : Yes
OCSP helper CA : No
If I check it with PHP
var_dump(openssl_x509_checkpurpose(file_get_contents('./certfile.pem'),X509_PURPOSE_SMIME_SIGN));
---
it returns int(0). Int(0) is evaluated as boolean false in PHP.
Tested PHP 5.2.0 and PHP 5.2-dev (200710080830). OpenSSL 0.9.8c (Debian
0.9.8c-4 package). Used Thawte free email certificate for testing.
Certificate is valid from 2007.02.24 till 2008.02.24. System clock is
correct.
Reproduce code:
---
var_dump(openssl_x509_checkpurpose(file_get_contents('./certfile.pem'),X509_PURPOSE_SMIME_SIGN));
Expected result:
bool(true) or int(1)
Actual result:
--
int(0)
--
Edit this bug report at http://bugs.php.net/?id=42886edit=1
#46600 [Opn-Ver]: _empty_ key in objects (see #41504)
ID: 46600
Updated by: [EMAIL PROTECTED]
Reported By: Matt at mpcm dot com
-Status: Open
+Status: Verified
Bug Type: JSON related
-Operating System: Ubuntu
+Operating System: *
-PHP Version: 5.3.0alpha2
+PHP Version: 5CVS, 6CVS (2008-11-18)
Previous Comments:
[2008-11-18 03:13:51] Matt at mpcm dot com
Description:
json_decode() treats empty property name as _empty_ not . This was
fixed in #41504 for arrays, but not for objects. (seems to happen in PHP
Version 5.2.4-2ubuntu5.3 and 5.3.0alpha2.
Reproduce code:
---
?
$s = '{:test}';
var_dump(json_decode($s));
?
Expected result:
object(stdClass)#1 (1) { []= string(4) test }
Actual result:
--
object(stdClass)#2 (1) { [_empty_]= string(4) test }
--
Edit this bug report at http://bugs.php.net/?id=46600edit=1
#46597 [Opn-Ver]: Inconsistent return values for strtotime('0000-00-00')
ID: 46597
Updated by: [EMAIL PROTECTED]
Reported By: fsb at thefsb dot org
-Status: Open
+Status: Verified
Bug Type: Date/time related
-Operating System: Mac 10.5.5
+Operating System: *
-PHP Version: 5.2.6
+PHP Version: 5CVS, 6CVS (2008-11-18)
Previous Comments:
[2008-11-17 18:33:04] fsb at thefsb dot org
i was wrong with the expected results. a year of is reasonable but
neither month = 00 nor day of of the month = 00 are possible, so the
strtotime('-00-00') should return bool(false)
[2008-11-17 17:41:21] fsb at thefsb dot org
Description:
strtotime('-00-00') returns int(-62169955200) in a script run by
apache web server and bool(false) when run by the command line.
Reproduce code:
---
?php
var_dump(strtotime('-00-00'));
?
this script outputs int(-62169955200) to the web browser when run as a
web page and bool(false) when run on the command line.
Expected result:
i would expect the same result from running the function in the two
contexts.
regarding which result strtotime('-00-00') should return, i don't
know. both answers seem reasonable to me. it would help if php
documentation would specify the range of dates and unix timestamps that
date and time functions can handle.
Actual result:
--
int(-62169955200) in the web page
bool(false) in the command line
--
Edit this bug report at http://bugs.php.net/?id=46597edit=1
#46603 [NEW]: Installation fails ....
From: ktildsley at btinternet dot com Operating system: xp2 PHP version: 5.2.6 PHP Bug Type: Windows Installer Bug description: Installation fails Description: Attempting to upgared from PHP 4 to 5. Used the installer for windows, seemed to work, no problems. However, when Apache starts it complains about the end of httpd.conf, namely the line PHPIniDir C:/Program Files/PHP5/ Errors says PHPIniDir is an invalid command. Removing the offending (to see what happens)line leads to an error that Apache can't find php5apache2_2.dll in the path given, even though the file is most certainly there. Furthermore, after uninstalling PHP5, IE no longer executes Apache/PHP4, the browser just attempts to download the php file, rather than having Apache/PHP4 execute it. Configuration files are the way they have been for last two years, so not sure what has got meesed up by installing and then uninstalling PHP5 Expected result: I expected the installer to work. Actual result: -- Apache.exe no longer runs but generates error message detailed above. -- Edit bug report at http://bugs.php.net/?id=46603edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46603r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46603r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46603r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46603r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=46603r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=46603r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46603r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=46603r=needscript Try newer version: http://bugs.php.net/fix.php?id=46603r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46603r=support Expected behavior: http://bugs.php.net/fix.php?id=46603r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46603r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46603r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46603r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46603r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=46603r=dst IIS Stability: http://bugs.php.net/fix.php?id=46603r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46603r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46603r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46603r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=46603r=mysqlcfg
#46603 [Com]: Installation fails ....
ID: 46603 Comment by: ktildsley at btinternet dot com Reported By: ktildsley at btinternet dot com Status: Open Bug Type: Windows Installer Operating System: xp2 PHP Version: 5.2.6 New Comment: A Google search for PHPinidir invalid command throws up a bunch of pages where people seem to have the same problem. Previous Comments: [2008-11-18 13:46:11] ktildsley at btinternet dot com Description: Attempting to upgared from PHP 4 to 5. Used the installer for windows, seemed to work, no problems. However, when Apache starts it complains about the end of httpd.conf, namely the line PHPIniDir C:/Program Files/PHP5/ Errors says PHPIniDir is an invalid command. Removing the offending (to see what happens)line leads to an error that Apache can't find php5apache2_2.dll in the path given, even though the file is most certainly there. Furthermore, after uninstalling PHP5, IE no longer executes Apache/PHP4, the browser just attempts to download the php file, rather than having Apache/PHP4 execute it. Configuration files are the way they have been for last two years, so not sure what has got meesed up by installing and then uninstalling PHP5 Expected result: I expected the installer to work. Actual result: -- Apache.exe no longer runs but generates error message detailed above. -- Edit this bug report at http://bugs.php.net/?id=46603edit=1
#46600 [Com]: _empty_ key in objects (see #41504)
ID: 46600
Comment by: matt at mpcm dot com
Reported By: Matt at mpcm dot com
Status: Verified
Bug Type: JSON related
Operating System: *
PHP Version: 5CVS, 6CVS (2008-11-18)
New Comment:
All the work arounds I am looking at are throwing Error Text: Illegal
member variable name when I convert/cast an object with a blank
property.
Is this json_decode `bug` a result of a larger object mechanism
limitation inside of php's object handling?
Previous Comments:
[2008-11-18 03:13:51] Matt at mpcm dot com
Description:
json_decode() treats empty property name as _empty_ not . This was
fixed in #41504 for arrays, but not for objects. (seems to happen in PHP
Version 5.2.4-2ubuntu5.3 and 5.3.0alpha2.
Reproduce code:
---
?
$s = '{:test}';
var_dump(json_decode($s));
?
Expected result:
object(stdClass)#1 (1) { []= string(4) test }
Actual result:
--
object(stdClass)#2 (1) { [_empty_]= string(4) test }
--
Edit this bug report at http://bugs.php.net/?id=46600edit=1
#46604 [NEW]: ReflectionClass::getProperty() fails
From: [EMAIL PROTECTED] Operating system: Windows/Linux PHP version: 6CVS-2008-11-18 (snap) PHP Bug Type: Reflection related Bug description: ReflectionClass::getProperty() fails Description: ReflectionClass::getProperty() returns a NULL on PHP 6 - it works as expected on PHP 5.3 and 5.2.6. There are some tests now checked into CVS that show the unexpected behaviour: ext/reflection/tests/ReflectionClass_getProperty_001.phpt ext/reflection/tests/ReflectionClass_getProperty_003.phpt ext/reflection/tests/ReflectionClass_getProperty_004.phpt These tests have been marked with an --XFAIL-- section so they should show up as expected failures. Reproduce code: --- See the following tests in CVS: ext/reflection/tests/ReflectionClass_getProperty_001.phpt ext/reflection/tests/ReflectionClass_getProperty_003.phpt ext/reflection/tests/ReflectionClass_getProperty_004.phpt Expected result: 083- -- Check for a: Property a does not exist Actual result: -- 083+ -- Check for a: NULL -- Edit bug report at http://bugs.php.net/?id=46604edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46604r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46604r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46604r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46604r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=46604r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=46604r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46604r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=46604r=needscript Try newer version: http://bugs.php.net/fix.php?id=46604r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46604r=support Expected behavior: http://bugs.php.net/fix.php?id=46604r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46604r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46604r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46604r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46604r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=46604r=dst IIS Stability: http://bugs.php.net/fix.php?id=46604r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46604r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46604r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46604r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=46604r=mysqlcfg
#41388 [Com]: Error in COM Object results
ID: 41388 Comment by: xxx at xxx dot cc Reported By: superfelo at yahoo dot com Status: Assigned Bug Type: COM related Operating System: Windows XP and 2003 PHP Version: 5.2.2 Assigned To: wez New Comment: ¿Se arreglará alguna vez? ¿Hay alguien trabajando en el problema? Will fix any time? Is anyone working on the problem? Previous Comments: [2007-12-19 13:26:19] superfelo at yahoo dot com Is there any progress? Is working on the problem? [2007-08-15 08:33:02] [EMAIL PROTECTED] Assigned to the maintainer. [2007-05-14 15:29:36] superfelo at yahoo dot com Description: As it is possible to see bellow, a COM Object is opened, then Data Base is read by a Recordset and a OLE object is loaded in such Recordset. Later, using a GetChunk which is a Recordset function a number of bytes in OLE object is read but this function just result in the number of printable characters and it discards or ignore for instance, byte 0 or any other not printable character. In the second example, it is possible to see a function to read 20 bytes after a certain position. Now the problem is similar. The 20 bytes has been counted by the results are just printable characters of such 20 bytes. So, result is less than 20 character because not all 20 characters are printable. Reproduce code: --- $engine = new COM(DAO.DBEngine.35); $engine-SystemDB = c:\system.mda; $engine-defaultuser = admin; $engine-defaultpassword = ; $db = $engine-OpenDataBase(c:\bd.mdb); $sqlstr = SELECT DISTINCTROW tabla1.* FROM tabla1; ; $rst = $db-OpenRecordset(RsConfig,$sqlstr); echo $rst-Fields[Campo1]-GetChunk(1,20); //- $mstream = new COM(ADODB.Stream); $mstream-Type = 1; // 'adTypeBinary $mstream-Open; $mstream-Write($rst-Fields[Campo1]-Value); $mstream-position = 0; echo $mstream-Read(20); Expected result: The actual number of bytes in a OLE object stored in a Recordset: This number of bytes of course, must include printable and not printable characters. Actual result: -- Just the number of printable characters. -- Edit this bug report at http://bugs.php.net/?id=41388edit=1
#46568 [Com]: Segfault on 64bit when chaining function calls that generate exceptions
ID: 46568
Comment by: crrodriguez at opensuse dot org
Reported By: phpbugs at colin dot guthr dot ie
Status: Feedback
Bug Type: Scripting Engine problem
Operating System: * (64bit)
PHP Version: 5.2.7RC3
New Comment:
Cannot reproduce,in opensuse 11 64 bit , GCC 4.3.1 either with or
without suhosin.
I suspect either your system or your compiler is doing something wrong.
Previous Comments:
[2008-11-17 21:51:09] phpbugs at colin dot guthr dot ie
My configure line is just the default. All I did was pass a custom
prefix.
I'll try and find some other 64 bit systems to play on. I should be
able to fire a few different systems into a vm to see if I can reproduce
it with other distros.
[2008-11-17 10:18:57] [EMAIL PROTECTED]
I can not reproduce this within x86_64 Centos 5 using latest PHP_5_2
checkout. Would be nice to know your configure line for PHP too..?
[2008-11-16 08:03:46] bruno at ioda dot net
I've try this on 3 differents openSUSE 10.3 all with the lastest
opensuse build services php version 5.2.6.
And the result was the expected exception
Fatal error: Uncaught exception 'Exception' with message 'Wibble' in
/tmp/bugs.php:10
Stack trace:
#0 /tmp/bugs.php(14): foo-wibble()
#1 /tmp/bugs.php(23): foo-bug()
#2 {main}
thrown in /tmp/bugs.php on line 10
PHP 5.2.6 with Suhosin-Patch 0.9.6.2 (cli) (built: Nov 5 2008
13:42:52)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies
with Suhosin v0.9.27, Copyright (c) 2007, by SektionEins GmbH
For 10.3 gcc is :
Target: x86_64-suse-linux
Configuré avec: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.2.1
--enable-ssp --disable-libssp --disable-libgcj --with-slibdir=/lib64
--with-system-zlib --enable-shared --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--program-suffix=-4.2 --enable-version-specific-runtime-libs
--without-system-libunwind --with-cpu=generic --host=x86_64-suse-linux
Modèle de thread: posix
version gcc 4.2.1 (SUSE Linux)
I've not yet try on the lastest 11.0 x64 which have the gcc
gcc version 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision
135036] (SUSE Linux)
[2008-11-13 22:41:05] phpbugs at colin dot guthr dot ie
Well I've confirmed this problem on three Mandriva systems with
Mandriva packages but for this bug report I built a fresh vanilla
version from the 5.2.7rc3 tarball on my own machine to ensure it was
nothing to do with any additional patches in the Mandriva package
causing the problem.
I do not have access to any non-Mandriva 64 bit build hosts here to do
more tests...
FWIW, the GCC version is 4.3.2.
I can tarball up the installed version if you want to give my build a
run and see if it crashes on your machine. If it does crash then I'd
expect the problem to be related to GCC.
[2008-11-13 22:23:05] [EMAIL PROTECTED]
I can't reproduce it on FreeBSD amd64.
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/46568
--
Edit this bug report at http://bugs.php.net/?id=46568edit=1
#46600 [Com]: _empty_ key in objects (see #41504)
ID: 46600
Comment by: matt at mpcm dot com
Reported By: Matt at mpcm dot com
Status: Verified
Bug Type: JSON related
Operating System: *
PHP Version: 5CVS, 6CVS (2008-11-18)
New Comment:
The language seems to create a key that cannot be reached, so even if
this `bug` is fixed, we am still facing a broader issue it seems.
?
$key = ;
$o = (object) array($key=4,example=8);
var_dump($o);
print 'blank key test:' . (isset($o-$key)?'true':'false');
print $o-{$key};
var_dump($o-$key);
?
output:
object(stdClass)#1 (2) {
[]=
int(4)
[example]=
int(8)
}
blank key test:falsebr /
bFatal error/b: Cannot access empty property in
bPHPDocument1/b on line b8/bbr /
All throws Notice: line 4 - Illegal member variable name
Previous Comments:
[2008-11-18 15:43:05] matt at mpcm dot com
All the work arounds I am looking at are throwing Error Text: Illegal
member variable name when I convert/cast an object with a blank
property.
Is this json_decode `bug` a result of a larger object mechanism
limitation inside of php's object handling?
[2008-11-18 03:13:51] Matt at mpcm dot com
Description:
json_decode() treats empty property name as _empty_ not . This was
fixed in #41504 for arrays, but not for objects. (seems to happen in PHP
Version 5.2.4-2ubuntu5.3 and 5.3.0alpha2.
Reproduce code:
---
?
$s = '{:test}';
var_dump(json_decode($s));
?
Expected result:
object(stdClass)#1 (1) { []= string(4) test }
Actual result:
--
object(stdClass)#2 (1) { [_empty_]= string(4) test }
--
Edit this bug report at http://bugs.php.net/?id=46600edit=1
#46568 [Fbk-Opn]: Segfault on 64bit when chaining function calls that generate exceptions
ID: 46568
User updated by: phpbugs at colin dot guthr dot ie
Reported By: phpbugs at colin dot guthr dot ie
-Status: Feedback
+Status: Open
Bug Type: Scripting Engine problem
Operating System: * (64bit)
PHP Version: 5.2.7RC3
New Comment:
Thanks for all the feedback/help. I will have to investigate further. I
do not think my system hardware is at fault due to having confirmed on
two other machines, although both Mandriva based. This is why I
suspected the compiler.
I will try and work out more info.
Previous Comments:
[2008-11-18 17:23:16] crrodriguez at opensuse dot org
Cannot reproduce,in opensuse 11 64 bit , GCC 4.3.1 either with or
without suhosin.
I suspect either your system or your compiler is doing something wrong.
[2008-11-17 21:51:09] phpbugs at colin dot guthr dot ie
My configure line is just the default. All I did was pass a custom
prefix.
I'll try and find some other 64 bit systems to play on. I should be
able to fire a few different systems into a vm to see if I can reproduce
it with other distros.
[2008-11-17 10:18:57] [EMAIL PROTECTED]
I can not reproduce this within x86_64 Centos 5 using latest PHP_5_2
checkout. Would be nice to know your configure line for PHP too..?
[2008-11-16 08:03:46] bruno at ioda dot net
I've try this on 3 differents openSUSE 10.3 all with the lastest
opensuse build services php version 5.2.6.
And the result was the expected exception
Fatal error: Uncaught exception 'Exception' with message 'Wibble' in
/tmp/bugs.php:10
Stack trace:
#0 /tmp/bugs.php(14): foo-wibble()
#1 /tmp/bugs.php(23): foo-bug()
#2 {main}
thrown in /tmp/bugs.php on line 10
PHP 5.2.6 with Suhosin-Patch 0.9.6.2 (cli) (built: Nov 5 2008
13:42:52)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies
with Suhosin v0.9.27, Copyright (c) 2007, by SektionEins GmbH
For 10.3 gcc is :
Target: x86_64-suse-linux
Configuré avec: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.2.1
--enable-ssp --disable-libssp --disable-libgcj --with-slibdir=/lib64
--with-system-zlib --enable-shared --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--program-suffix=-4.2 --enable-version-specific-runtime-libs
--without-system-libunwind --with-cpu=generic --host=x86_64-suse-linux
Modèle de thread: posix
version gcc 4.2.1 (SUSE Linux)
I've not yet try on the lastest 11.0 x64 which have the gcc
gcc version 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision
135036] (SUSE Linux)
[2008-11-13 22:41:05] phpbugs at colin dot guthr dot ie
Well I've confirmed this problem on three Mandriva systems with
Mandriva packages but for this bug report I built a fresh vanilla
version from the 5.2.7rc3 tarball on my own machine to ensure it was
nothing to do with any additional patches in the Mandriva package
causing the problem.
I do not have access to any non-Mandriva 64 bit build hosts here to do
more tests...
FWIW, the GCC version is 4.3.2.
I can tarball up the installed version if you want to give my build a
run and see if it crashes on your machine. If it does crash then I'd
expect the problem to be related to GCC.
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/46568
--
Edit this bug report at http://bugs.php.net/?id=46568edit=1
#46572 [Fbk-Opn]: Apache unable to Load php_ldap.dll
ID: 46572
User updated by: gdjsmith at gmail dot com
Reported By: gdjsmith at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: Dynamic loading
Operating System: Windows Server 2003
PHP Version: 5.2.6
New Comment:
Yes the CLI works it is the apache module that will not load
php_ldap.dll.
Previous Comments:
[2008-11-14 10:09:37] [EMAIL PROTECTED]
Works here, try to load it using the CLI, to get the exact error
message.
[2008-11-14 06:23:12] gdjsmith at gmail dot com
Description:
My Env is as follows:
Windows Server 2003 Sp2
PHP 5.2.6
Apache 2.0.x
PHP Warning: PHP Startup: Unable to load dynamic library
'%PHPRC%\\ext\\php_ldap.dll' - The operating system cannot run %1.\r\n
in Unknown on line 0
The Apache php module will load all of the other libraries except this
one.
I've been looking into the ssleay32.dll and libeay32.dll and making
sure I have the right ones and that they are in the PATH so the OS can
find them.
I've used the MSI and zip versions of PHP but get the same results.
Not sure where else to turn to.
Reproduce code:
---
?php
$ldapconn =ldap_connect(ldap.test.com, 389);
if($ldapconn){
echo Success ;
}
else{
echo Fail;
}
?
Expected result:
Succss or Fail
Actual result:
--
Fatal error: Call to undefined function ldap_connect()
--
Edit this bug report at http://bugs.php.net/?id=46572edit=1
#46568 [Com]: Segfault on 64bit when chaining function calls that generate exceptions
ID: 46568
Comment by: crrodriguez at opensuse dot org
Reported By: phpbugs at colin dot guthr dot ie
Status: Open
Bug Type: Scripting Engine problem
Operating System: * (64bit)
PHP Version: 5.2.7RC3
New Comment:
Did you built 5.2.7RC3 with --enable-debug ? if not, try that, does it
crash anyway ?
Previous Comments:
[2008-11-18 17:36:56] phpbugs at colin dot guthr dot ie
Thanks for all the feedback/help. I will have to investigate further. I
do not think my system hardware is at fault due to having confirmed on
two other machines, although both Mandriva based. This is why I
suspected the compiler.
I will try and work out more info.
[2008-11-18 17:23:16] crrodriguez at opensuse dot org
Cannot reproduce,in opensuse 11 64 bit , GCC 4.3.1 either with or
without suhosin.
I suspect either your system or your compiler is doing something wrong.
[2008-11-17 21:51:09] phpbugs at colin dot guthr dot ie
My configure line is just the default. All I did was pass a custom
prefix.
I'll try and find some other 64 bit systems to play on. I should be
able to fire a few different systems into a vm to see if I can reproduce
it with other distros.
[2008-11-17 10:18:57] [EMAIL PROTECTED]
I can not reproduce this within x86_64 Centos 5 using latest PHP_5_2
checkout. Would be nice to know your configure line for PHP too..?
[2008-11-16 08:03:46] bruno at ioda dot net
I've try this on 3 differents openSUSE 10.3 all with the lastest
opensuse build services php version 5.2.6.
And the result was the expected exception
Fatal error: Uncaught exception 'Exception' with message 'Wibble' in
/tmp/bugs.php:10
Stack trace:
#0 /tmp/bugs.php(14): foo-wibble()
#1 /tmp/bugs.php(23): foo-bug()
#2 {main}
thrown in /tmp/bugs.php on line 10
PHP 5.2.6 with Suhosin-Patch 0.9.6.2 (cli) (built: Nov 5 2008
13:42:52)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies
with Suhosin v0.9.27, Copyright (c) 2007, by SektionEins GmbH
For 10.3 gcc is :
Target: x86_64-suse-linux
Configuré avec: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.2.1
--enable-ssp --disable-libssp --disable-libgcj --with-slibdir=/lib64
--with-system-zlib --enable-shared --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--program-suffix=-4.2 --enable-version-specific-runtime-libs
--without-system-libunwind --with-cpu=generic --host=x86_64-suse-linux
Modèle de thread: posix
version gcc 4.2.1 (SUSE Linux)
I've not yet try on the lastest 11.0 x64 which have the gcc
gcc version 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision
135036] (SUSE Linux)
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/46568
--
Edit this bug report at http://bugs.php.net/?id=46568edit=1
#45591 [NoF-Csd]: Bus error on file_get_contents
ID: 45591 Updated by: [EMAIL PROTECTED] Reported By: rommer at active dot by -Status: No Feedback +Status: Closed Bug Type: Reproducible crash Operating System: linux-2.6.x i386 PHP Version: 5.2CVS-2008-07-22 (snap) Previous Comments: [2008-11-14 21:48:39] [EMAIL PROTECTED] Looks like this is fixed in php-5.2.6+ (I just tested this). Can you please verify if this is still an open issue for you as well using latest CVS or php-5.2.6+ [2008-10-27 19:12:38] steveh at brendata dot co dot uk I'm seeing the same issue, also, the original poster has supplied the required information but has not changed the status so this may have been missed? php -v PHP 5.2.4-2ubuntu5.3 with Suhosin-Patch 0.9.6.2 (cli) (built: Jul 23 2008 06:44:49) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies with Xdebug v2.0.3, Copyright (c) 2002-2007, by Derick Rethans php -m [PHP Modules] bcmath bz2 calendar ctype date dba dom exif fileinfo filter ftp gd gettext hash iconv json libxml mbstring mime_magic mysql mysqli ncurses openssl pcntl pcre PDO pdo_mysql posix readline Reflection session shmop SimpleXML soap sockets SPL standard sysvmsg sysvsem sysvshm tokenizer wddx xdebug xml xmlreader xmlwriter zip zlib [Zend Modules] Xdebug [2008-09-29 15:29:48] rlucia at iscanet dot com # php -v PHP 5.2.5 (cli) (built: Apr 16 2008 19:24:05) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies with eAccelerator v0.9.5.3, Copyright (c) 2004-2006 eAccelerator, by eAccelerator # php -m [PHP Modules] ctype curl date dom eAccelerator ffmpeg filter gd geoip hash iconv json libxml magickwand mcrypt memcache mysql mysqli openssl pcre PDO pdo_mysql pdo_sqlite posix Reflection session SimpleXML SPL SQLite standard tokenizer xml xmlreader xmlwriter zlib [Zend Modules] eAccelerator Core was generated by `/usr/local/apache2//bin/httpd -k start'. Program terminated with signal 7, Bus error. #0 0xb7d09b35 in memcpy () from /lib/tls/i686/cmov/libc.so.6 (gdb) bt #0 0xb7d09b35 in memcpy () from /lib/tls/i686/cmov/libc.so.6 #1 0xb7af3f4c in _php_stream_copy_to_mem (src=0xb6ed7db8, buf=0xbff4f9bc, maxlen=4294967295, persistent=0) at /usr/local/src/php-5.2.5/main/streams/streams.c:1223 #2 0xb7a83106 in zif_file_get_contents (ht=1, return_value=0xb2372fd4, return_value_ptr=0x0, this_ptr=0x0, return_value_used=1) at /usr/local/src/php-5.2.5/ext/standard/file.c:563 #3 0xb7b3cbb2 in zend_do_fcall_common_helper_SPEC (execute_data=0xbff4fbd0) at /usr/local/src/php-5.2.5/Zend/zend_vm_execute.h:200 #4 0xb7b3bbe8 in execute (op_array=0xb23b6330) at /usr/local/src/php-5.2.5/Zend/zend_vm_execute.h:92 #5 0xb7b3c618 in zend_do_fcall_common_helper_SPEC (execute_data=0xbff4fe10) at /usr/local/src/php-5.2.5/Zend/zend_vm_execute.h:234 #6 0xb7b3bbe8 in execute (op_array=0xb23b6330) at /usr/local/src/php-5.2.5/Zend/zend_vm_execute.h:92 #7 0xb7b3c618 in zend_do_fcall_common_helper_SPEC (execute_data=0xbff50050) at /usr/local/src/php-5.2.5/Zend/zend_vm_execute.h:234 #8 0xb7b3bbe8 in execute (op_array=0xb23b6330) at /usr/local/src/php-5.2.5/Zend/zend_vm_execute.h:92 #9 0xb7b3c618 in zend_do_fcall_common_helper_SPEC (execute_data=0xbff50290) at /usr/local/src/php-5.2.5/Zend/zend_vm_execute.h:234 #10 0xb7b3bbe8 in execute (op_array=0xb23b6330) at /usr/local/src/php-5.2.5/Zend/zend_vm_execute.h:92 #11 0xb7b3c618 in zend_do_fcall_common_helper_SPEC (execute_data=0xbff50740) at /usr/local/src/php-5.2.5/Zend/zend_vm_execute.h:234 #12 0xb7b3bbe8 in execute (op_array=0xb23b5e9c) at /usr/local/src/php-5.2.5/Zend/zend_vm_execute.h:92 #13 0xb7b3c618 in zend_do_fcall_common_helper_SPEC (execute_data=0xbff50a40) at /usr/local/src/php-5.2.5/Zend/zend_vm_execute.h:234 #14 0xb7b3bbe8 in execute (op_array=0xb23af4b8) at /usr/local/src/php-5.2.5/Zend/zend_vm_execute.h:92 #15 0xb7b13df8 in zend_call_function (fci=0xbff50b88, fci_cache=0xbff50bac) at /usr/local/src/php-5.2.5/Zend/zend_execute_API.c:990 #16 0xb7a03ca5 in zim_reflection_method_invokeArgs (ht=2, return_value=0xb236d4f8, return_value_ptr=0x0, this_ptr=0xb236cedc, return_value_used=1) at /usr/local/src/php-5.2.5/ext/reflection/php_reflection.c:2479 #17 0xb7b3cbb2 in zend_do_fcall_common_helper_SPEC (execute_data=0xbff50dc0) at /usr/local/src/php-5.2.5/Zend/zend_vm_execute.h:200 #18 0xb7b3bbe8 in execute (op_array=0xb23e9094) at /usr/local/src/php-5.2.5/Zend/zend_vm_execute.h:92 #19 0xb7b3c618 in zend_do_fcall_common_helper_SPEC (execute_data=0xbff51080) at /usr/local/src/php-5.2.5/Zend/zend_vm_execute.h:234 #20 0xb7b3bbe8 in execute (op_array=0xb23e9160) at
#46568 [Opn]: Segfault on 64bit when chaining function calls that generate exceptions
ID: 46568 User updated by: phpbugs at colin dot guthr dot ie Reported By: phpbugs at colin dot guthr dot ie Status: Open Bug Type: Scripting Engine problem Operating System: * (64bit) PHP Version: 5.2.7RC3 New Comment: Just tried --enable-debug and when built this way, it does indeed work as expected. Does this suggest anything else I can try to narrow down the problem. I also tried make test and did get several failures. I uploaded the test results to http://kenobi.mandriva.com/~colin/php_test_results_20081118_2006.txt although none of these look particularly relevant. I will do another build sans --enable-debug and see if any different standard tests fail. Previous Comments: [2008-11-18 18:11:21] crrodriguez at opensuse dot org Did you built 5.2.7RC3 with --enable-debug ? if not, try that, does it crash anyway ? [2008-11-18 17:36:56] phpbugs at colin dot guthr dot ie Thanks for all the feedback/help. I will have to investigate further. I do not think my system hardware is at fault due to having confirmed on two other machines, although both Mandriva based. This is why I suspected the compiler. I will try and work out more info. [2008-11-18 17:23:16] crrodriguez at opensuse dot org Cannot reproduce,in opensuse 11 64 bit , GCC 4.3.1 either with or without suhosin. I suspect either your system or your compiler is doing something wrong. [2008-11-17 21:51:09] phpbugs at colin dot guthr dot ie My configure line is just the default. All I did was pass a custom prefix. I'll try and find some other 64 bit systems to play on. I should be able to fire a few different systems into a vm to see if I can reproduce it with other distros. [2008-11-17 10:18:57] [EMAIL PROTECTED] I can not reproduce this within x86_64 Centos 5 using latest PHP_5_2 checkout. Would be nice to know your configure line for PHP too..? 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/46568 -- Edit this bug report at http://bugs.php.net/?id=46568edit=1
#46568 [Opn]: Segfault on 64bit when chaining function calls that generate exceptions
ID: 46568 User updated by: phpbugs at colin dot guthr dot ie Reported By: phpbugs at colin dot guthr dot ie Status: Open Bug Type: Scripting Engine problem Operating System: * (64bit) PHP Version: 5.2.7RC3 New Comment: OK, I repeated the make test sans-debug and it seems that a couple more tests fail under this scenario. http://kenobi.mandriva.com/~colin/php_test_results_20081118_2054.txt The most interesting extra failure is: Bug #30707 (Segmentation fault on exception in method) [Zend/tests/bug30707.phpt] This could perhaps provide some clues? For convenience, here is a diff of non-debug vs. debug: http://kenobi.mandriva.com/~colin/php-make-test.diff.txt Previous Comments: [2008-11-18 20:46:09] phpbugs at colin dot guthr dot ie Just tried --enable-debug and when built this way, it does indeed work as expected. Does this suggest anything else I can try to narrow down the problem. I also tried make test and did get several failures. I uploaded the test results to http://kenobi.mandriva.com/~colin/php_test_results_20081118_2006.txt although none of these look particularly relevant. I will do another build sans --enable-debug and see if any different standard tests fail. [2008-11-18 18:11:21] crrodriguez at opensuse dot org Did you built 5.2.7RC3 with --enable-debug ? if not, try that, does it crash anyway ? [2008-11-18 17:36:56] phpbugs at colin dot guthr dot ie Thanks for all the feedback/help. I will have to investigate further. I do not think my system hardware is at fault due to having confirmed on two other machines, although both Mandriva based. This is why I suspected the compiler. I will try and work out more info. [2008-11-18 17:23:16] crrodriguez at opensuse dot org Cannot reproduce,in opensuse 11 64 bit , GCC 4.3.1 either with or without suhosin. I suspect either your system or your compiler is doing something wrong. [2008-11-17 21:51:09] phpbugs at colin dot guthr dot ie My configure line is just the default. All I did was pass a custom prefix. I'll try and find some other 64 bit systems to play on. I should be able to fire a few different systems into a vm to see if I can reproduce it with other distros. 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/46568 -- Edit this bug report at http://bugs.php.net/?id=46568edit=1
#46605 [NEW]: isset does not work correctly after ArrayObject
From: roman dot tvrdy at gmail dot com
Operating system: Linux - Gentoo
PHP version: 5.2.6
PHP Bug Type: *General Issues
Bug description: isset does not work correctly after ArrayObject
Description:
Function isset does not work identically for object created by
ArrayObject(). For example code I have this output :
object(ArrayObject)[1]
public 'aa' = string 'some content' (length=12)
ko : isset does not work after ArrayObject()
object(stdClass)[2]
public 'aa' = string 'some content' (length=12)
ok : isset work after (object)
Reproduce code:
---
$content = array('aa' = 'some content');
// * //
$prm = new ArrayObject($content);
var_dump($prm);
if (isset($prm-aa) === true) echo 'ok : isset work after ArrayObject()';
else echo 'ko : isset does not work after ArrayObject()';
// * //
$prm = (object) $content;
var_dump($prm);
if (isset($prm-aa) === true) echo 'ok : isset work after (object)';
else echo 'ko : isset does not work after (object)';
Expected result:
Same behavior for both use.
--
Edit bug report at http://bugs.php.net/?id=46605edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=46605r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=46605r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=46605r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=46605r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=46605r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=46605r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=46605r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=46605r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=46605r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=46605r=support
Expected behavior:
http://bugs.php.net/fix.php?id=46605r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=46605r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=46605r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=46605r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46605r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=46605r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=46605r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=46605r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=46605r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=46605r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=46605r=mysqlcfg
#46408 [Opn]: Locale number format settings can cause pg_query_params to break with numerics
ID: 46408 User updated by: alec at smecher dot bc dot ca Reported By: alec at smecher dot bc dot ca Status: Open Bug Type: PostgreSQL related Operating System: Debian testing PHP Version: 5.2.7RC2 New Comment: Thanks, lsmith and RhodiumToad. FYI, this bug also exists in PDO (I can post reproduce code if it's helpful). Previous Comments: [2008-11-18 22:59:44] [EMAIL PROTECTED] RhodiumToad lsmith: in a parameterized query it's always wrong to use locale-specific delimiters RhodiumToad is also known as Andrew Gierth and is a highly respected expert on #postgresql on freenode. As such I will reopen the bug .. [2008-11-10 17:59:56] alec at smecher dot bc dot ca [EMAIL PROTECTED], please have a look at PostgreSQL's number parsing function (set_var_from_str in src/backend/utils/adt/numeric.c, e.g. at http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/adt/numeric.c?rev=1.114). It's hard-coded to expect a period as the decimal separator. Long story short, if you supply a floating point value to pg_query_params and you're using a PHP locale that formats floats with a comma, pg_query_params will generate SQL that will cause a parse error. IMO, the use of a locale-specific float-to-string conversion in PHP's implementation of pg_query_params is the bug. [2008-10-31 18:28:57] alec at smecher dot bc dot ca FYI, there's a discussion of the same bug, which also appeared (in a separate implementation) in the implementation of the Pear::DB package: http://pear.php.net/bugs/bug.php?id=3021 [2008-10-28 22:54:37] alec at smecher dot bc dot ca In case it wasn't clear, the bug IMO is that pg_query_params is using a means to convert doubles to strings that is potentially incompatible with the database. [2008-10-28 21:35:51] alec at smecher dot bc dot ca Sorry if I've missed something in the documentation, but this definitely looks like a bug to me. I expect pg_query_params, when given a double, to communicate it to the database properly regardless of PHP's number format settings. Could I have a little more feedback? 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/46408 -- Edit this bug report at http://bugs.php.net/?id=46408edit=1
#46605 [Opn-Bgs]: isset does not work correctly after ArrayObject
ID: 46605
Updated by: [EMAIL PROTECTED]
Reported By: roman dot tvrdy at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: *General Issues
Operating System: Linux - Gentoo
PHP Version: 5.2.6
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
Try isset($prm['aa'])
Previous Comments:
[2008-11-18 22:03:30] roman dot tvrdy at gmail dot com
Description:
Function isset does not work identically for object created by
ArrayObject(). For example code I have this output :
object(ArrayObject)[1]
public 'aa' = string 'some content' (length=12)
ko : isset does not work after ArrayObject()
object(stdClass)[2]
public 'aa' = string 'some content' (length=12)
ok : isset work after (object)
Reproduce code:
---
$content = array('aa' = 'some content');
// * //
$prm = new ArrayObject($content);
var_dump($prm);
if (isset($prm-aa) === true) echo 'ok : isset work after
ArrayObject()';
else echo 'ko : isset does not work after ArrayObject()';
// * //
$prm = (object) $content;
var_dump($prm);
if (isset($prm-aa) === true) echo 'ok : isset work after (object)';
else echo 'ko : isset does not work after (object)';
Expected result:
Same behavior for both use.
--
Edit this bug report at http://bugs.php.net/?id=46605edit=1
#46408 [Bgs-Opn]: Locale number format settings can cause pg_query_params to break with numerics
ID: 46408 Updated by: [EMAIL PROTECTED] Reported By: alec at smecher dot bc dot ca -Status: Bogus +Status: Open Bug Type: PostgreSQL related Operating System: Debian testing PHP Version: 5.2.7RC2 New Comment: RhodiumToad lsmith: in a parameterized query it's always wrong to use locale-specific delimiters RhodiumToad is also known as Andrew Gierth and is a highly respected expert on #postgresql on freenode. As such I will reopen the bug .. Previous Comments: [2008-11-10 17:59:56] alec at smecher dot bc dot ca [EMAIL PROTECTED], please have a look at PostgreSQL's number parsing function (set_var_from_str in src/backend/utils/adt/numeric.c, e.g. at http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/adt/numeric.c?rev=1.114). It's hard-coded to expect a period as the decimal separator. Long story short, if you supply a floating point value to pg_query_params and you're using a PHP locale that formats floats with a comma, pg_query_params will generate SQL that will cause a parse error. IMO, the use of a locale-specific float-to-string conversion in PHP's implementation of pg_query_params is the bug. [2008-10-31 18:28:57] alec at smecher dot bc dot ca FYI, there's a discussion of the same bug, which also appeared (in a separate implementation) in the implementation of the Pear::DB package: http://pear.php.net/bugs/bug.php?id=3021 [2008-10-28 22:54:37] alec at smecher dot bc dot ca In case it wasn't clear, the bug IMO is that pg_query_params is using a means to convert doubles to strings that is potentially incompatible with the database. [2008-10-28 21:35:51] alec at smecher dot bc dot ca Sorry if I've missed something in the documentation, but this definitely looks like a bug to me. I expect pg_query_params, when given a double, to communicate it to the database properly regardless of PHP's number format settings. Could I have a little more feedback? [2008-10-28 21:30:50] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php 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/46408 -- Edit this bug report at http://bugs.php.net/?id=46408edit=1
#46594 [Opn]: call to OtherClass::__construct within MyClass::__construct
ID: 46594
Updated by: [EMAIL PROTECTED]
Reported By: dckorah at gmail dot com
Status: Open
Bug Type: Class/Object related
Operating System: Linux (Ububtu 7.10)
PHP Version: 5.2.6
New Comment:
Actually this has nothing to do with __construct(), same happens with
regular methods too.
Previous Comments:
[2008-11-17 14:04:31] dckorah at gmail dot com
Description:
?php
class A {
function __construct() {
$this-a_property = 'property set from A';
}
}
class B {
function __construct() {
A::__construct();
$this-b_property = 'property set from B';
}
}
?
In the above code, if you initialise class B and inspect the properties
of it, you will see that both a_property and b_property are set.
This is quite unexpected from an OO language.
version info:
PHP 5.2.3-1ubuntu6.4 (cli) (built: Jul 23 2008 06:20:35)
Copyright (c) 1997-2007 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies
Reproduce code:
---
?php
class A {
function __construct() {
$this-a_property = 'property set from A';
}
}
class B {
function __construct() {
A::__construct();
$this-b_property = 'property set from B';
}
}
?
Expected result:
Class A has got nothing to do with class B and this should not happen.
If at all an user trys this, it should throw an error.
Actual result:
--
Please see description.
--
Edit this bug report at http://bugs.php.net/?id=46594edit=1
#36311 [Com]: mb_convert_case with MB_CASE_TITLE could be better
ID: 36311 Comment by: kriskra at gmail dot com Reported By: alex at agileware dot net Status: Open Bug Type: Feature/Change Request Operating System: linux PHP Version: 4.4.2 New Comment: Description: mb_convert_case with MB_CASE_TITLE capitalises the 's' after an number. Reproduce code: --- ?php print mb_convert_case(IN THE 5TH CENTURY NOTING WAS CAPITALISED, MB_CASE_TITLE); ? Expected result: In The 5th Century Noting Was Capitalised Actual result: -- In The 5Th Century Noting Was Capitalised Previous Comments: [2006-02-07 12:31:25] [EMAIL PROTECTED] Reclassified as feature request. [2006-02-07 02:47:54] alex at agileware dot net Description: mb_convert_case with MB_CASE_TITLE capitalises the 's' after an apostrophe. It could also optionally accept an array of words not to change, such as 'a', 'at', 'in', 'of', etc. Reproduce code: --- ?php print mb_convert_case(THE APOSTROPHE'S 'S' SHOULD NOT BE CAPITALISED, MB_CASE_TITLE); ? Expected result: The Apostrophe's 'S' Should Not Be Capitalised Actual result: -- The Apostrophe'S 'S' Should Not Be Capitalised -- Edit this bug report at http://bugs.php.net/?id=36311edit=1
#46607 [NEW]: mb_convert_case with MB_CASE_TITLE should be improved
From: kriskra at gmail dot com Operating system: CENT OS PHP version: 5.2.6 PHP Bug Type: Feature/Change Request Bug description: mb_convert_case with MB_CASE_TITLE should be improved Description: mb_convert_case with MB_CASE_TITLE capitalises the 's' after an apostrophe. mb_convert_case with MB_CASE_TITLE capitalises the 't' after a number. Reproduce code: --- ?php print mb_convert_case(THE APOSTROPHE'S 'S' SHOULD NOT BE CAPITALISED, MB_CASE_TITLE); print mb_convert_case(IN THE 5TH CENTURY NOTING WAS CAPITALISED, MB_CASE_TITLE); ? Expected result: The Apostrophe's 'S' Should Not Be Capitalised In The 5th Century Noting Was Capitalised Actual result: -- The Apostrophe'S 'S' Should Not Be Capitalised In The 5Th Century Noting Was Capitalised -- Edit bug report at http://bugs.php.net/?id=46607edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46607r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46607r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46607r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46607r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=46607r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=46607r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46607r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=46607r=needscript Try newer version: http://bugs.php.net/fix.php?id=46607r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46607r=support Expected behavior: http://bugs.php.net/fix.php?id=46607r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46607r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46607r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46607r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46607r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=46607r=dst IIS Stability: http://bugs.php.net/fix.php?id=46607r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46607r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46607r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46607r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=46607r=mysqlcfg
#46596 [Opn]: Setting an associative array $var with the key $var: $var[$var] = true
ID: 46596
Updated by: [EMAIL PROTECTED]
-Summary: Setting an associative array $var with the key $var
... unexpected behaviour
Reported By: benjaminNOpickSPAM at web dot de
Status: Open
Bug Type: Arrays related
Operating System: Linux
PHP Version: 5.2CVS-2008-11-17 (CVS)
New Comment:
This is just side-effect of the fact that [] is also used for
strings. It's not just for arrays.
Previous Comments:
[2008-11-17 17:20:40] benjaminNOpickSPAM at web dot de
Description:
As the following lines are ok:
$var = $var + 1;
$var[trim($var2)] = '';
I expected PHP to first evaluate the $key-String ([$var]), then modify
$var. So a line like:
$var = 'a';
$var[$var] = 0;
should work.
Reproduce code:
---
?php
$var = 'x';
$var[$var] = true;
var_dump($var);
?
Expected result:
array(1) { [x]= bool(true) }
or a warning like:
Warning: Cannot use a scalar value as an array
Actual result:
--
string(5) 1
Depending on what code was before it, or what was in $var before, the
first character is not always '1'.
--
Edit this bug report at http://bugs.php.net/?id=46596edit=1
#46049 [Asn-Fbk]: feof() hangs
ID: 46049
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Assigned
+Status: Feedback
Bug Type: Streams related
Operating System: Linux
PHP Version: 5.3CVS-2008-09-11 (CVS)
Assigned To: dsp
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Previous Comments:
[2008-11-05 13:43:24] [EMAIL PROTECTED]
Jani: I think it's an issue with the ssl socks, as my patch didn't
patch
those. I try to have time to have a look on this, but I
cannot reproduce the patch yet even though I sit down with sebstian and
try to figure out what's going wrong.
[2008-10-28 22:08:32] [EMAIL PROTECTED]
David, I guess we just have to revert that bad patch of yours then?
[2008-09-11 12:17:57] [EMAIL PROTECTED]
David, it appears that this problem is caused by this patch of yours:
http://news.php.net/php.cvs/52689
Take a look at it please.
[2008-09-11 12:13:58] [EMAIL PROTECTED]
Description:
The code below works fine with PHP 5.2.6 (and earlier), but not with
the unreleased PHP 5.2.7 and PHP 5.3.0:
892 $handle = @fopen($url, 'r');
893
894 if (!$handle) {
895 throw new RuntimeException(
896 'Could not connect to the Selenium RC server.'
897 );
898 }
899
900 stream_set_blocking($handle, 1);
901 stream_set_timeout($handle, 0, $this-timeout);
902
903 $info = stream_get_meta_data($handle);
904 $response = '';
905
906 while ((!feof($handle)) (!$info['timed_out'])) {
907 $response .= fgets($handle, 4096);
908 $info = stream_get_meta_data($handle);
909 }
910
911 fclose($handle);
The code above hangs with PHP 5.2.7 and PHP 5.3.0 in line 906 as shown
using Xdebug's tracing:
fopen() Driver.php:892
stream_set_blocking() Driver.php:900
stream_set_timeout() Driver.php:901
stream_get_meta_data() Driver.php:903
feof() Driver.php:906
fgets() Driver.php:907
stream_get_meta_data() Driver.php:908
feof() Driver.php:906
The second feof() call above hangs.
More information can be found here:
- http://static.phpunit.de/trace.818532121.xt
- http://static.phpunit.de/strace.txt
Changing the loop to
while (!$info['eof'] !$info['timed_out']) {
$response .= fgets($handle, 4096);
$info = stream_get_meta_data($handle);
}
fixes the problem. This means a difference between feof() and
$info['eof'].
--
Edit this bug report at http://bugs.php.net/?id=46049edit=1
#46565 [Opn]: oci_fetch_all() returns ORA-01002
ID: 46565 Updated by: [EMAIL PROTECTED] Reported By: james_blond at hipernet dot brda dot net Status: Open Bug Type: OCI8 related Operating System: * PHP Version: 5.2.6 -Assigned To: +Assigned To: sixd New Comment: The oci_fetch_all() function was designed to cancel a query after being called once. The behavior you see is expected. However it sounds like a possible enhancement. Previous Comments: [2008-11-13 13:00:26] james_blond at hipernet dot brda dot net Description: function oci_fetch_all on second use return error ORA-01002: fetch out of sequence. Reproduce code: --- $dbstr = (DESCRIPTION = (ADDRESS = PROTOCOL = TCP (HOST = host)(PORT = 1521))(CONNECT_DATA = (SID = sid))); $c = oci_connect(user,pass,$dbstr,UTF8); $SQL = SELECT * FROM table ; // table have more then 100 rec $s = oci_parse($c,$SQL); oci_execute($s,OCI_COMMIT_ON_SUCCESS); oci_fetch_all($s,$Row,0,10, OCI_NUM); print_r($Row); oci_fetch_all($s,$Row,10,10, OCI_NUM);// here return error ORA-01002 print_r($Row); Expected result: printed array $Row Actual result: -- array $Row is printed only on first time on second $Row is empty , oci_fetch_all - return error ORA-01002: fetch out of sequence. -- Edit this bug report at http://bugs.php.net/?id=46565edit=1
#46568 [Com]: Segfault on 64bit when chaining function calls that generate exceptions
ID: 46568 Comment by: crrodriguez at opensuse dot org Reported By: phpbugs at colin dot guthr dot ie Status: Open Bug Type: Scripting Engine problem Operating System: * (64bit) PHP Version: 5.2.7RC3 New Comment: Yes, it suggest that your compiler optimized badly.. try export CFLAGS=-O2 -fno-strict-aliasing and rebuild. if still crashes... try -O1.. Previous Comments: [2008-11-18 21:20:43] phpbugs at colin dot guthr dot ie OK, I repeated the make test sans-debug and it seems that a couple more tests fail under this scenario. http://kenobi.mandriva.com/~colin/php_test_results_20081118_2054.txt The most interesting extra failure is: Bug #30707 (Segmentation fault on exception in method) [Zend/tests/bug30707.phpt] This could perhaps provide some clues? For convenience, here is a diff of non-debug vs. debug: http://kenobi.mandriva.com/~colin/php-make-test.diff.txt [2008-11-18 20:46:09] phpbugs at colin dot guthr dot ie Just tried --enable-debug and when built this way, it does indeed work as expected. Does this suggest anything else I can try to narrow down the problem. I also tried make test and did get several failures. I uploaded the test results to http://kenobi.mandriva.com/~colin/php_test_results_20081118_2006.txt although none of these look particularly relevant. I will do another build sans --enable-debug and see if any different standard tests fail. [2008-11-18 18:11:21] crrodriguez at opensuse dot org Did you built 5.2.7RC3 with --enable-debug ? if not, try that, does it crash anyway ? [2008-11-18 17:36:56] phpbugs at colin dot guthr dot ie Thanks for all the feedback/help. I will have to investigate further. I do not think my system hardware is at fault due to having confirmed on two other machines, although both Mandriva based. This is why I suspected the compiler. I will try and work out more info. [2008-11-18 17:23:16] crrodriguez at opensuse dot org Cannot reproduce,in opensuse 11 64 bit , GCC 4.3.1 either with or without suhosin. I suspect either your system or your compiler is doing something wrong. 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/46568 -- Edit this bug report at http://bugs.php.net/?id=46568edit=1
