#47712 [Com]: (mysqlnd) last fetched row may get corrupted after calling mysql_free_result()
ID: 47712 Comment by: ninzya at inbox dot lv Reported By: ninzya at inbox dot lv Status: Open Bug Type: MySQL related Operating System: Windows XP PHP Version: 5.3.0RC2 Assigned To: mysql New Comment: People started reporting memory leaks when working with mysql (through PDO, mysqli, mysql). I didn't try to investigate this issue, but i assume the leaks may have taken place after andrey has switched zval cache to off. You should take a look at this. See some bug reports after andrey has posted about the change he has made to CVS. Previous Comments: [2009-06-11 20:13:23] ninzya at inbox dot lv The problem with turned zval cache off is away, but with turned on zval cache bug still exists, so i assume the bug is NOT fixed, turning zval cache off is a temporary fix, that's why i keep the bug open. Or i shouldn't? [2009-06-11 17:30:45] and...@php.net Do you still experience the problem? You said you don't or you see it again? The zval cache is switched off and there is no way to enable it without recompiling. If the problem persist we have to search for the problem somewhere else. [2009-06-10 23:51:39] ninzya at inbox dot lv I guess zval cache is not fixed on windows yet, so i open the bug. [2009-06-09 13:47:54] and...@php.net Turning on is only possible through a recompilation. Maybe we can add an ini option (INI_SYSTEM) to switch it without recompilation. But currently the CVS is locked for changes. [2009-06-09 11:05:57] ninzya at inbox dot lv Well, seems something is wrong with concurrent access to zval cache on windows. Try turning zval cache on and test my code on windows machine. 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/47712 -- Edit this bug report at http://bugs.php.net/?id=47712edit=1
#48547 [NEW]: DirectoryIterator Slash issue with getPathname Windows with Apache
From: BinaryKitten at jkrswebsolutions dot co dot uk
Operating system: XP SP3
PHP version: 5.2.9
PHP Bug Type: SPL related
Bug description: DirectoryIterator Slash issue with getPathname Windows with
Apache
Description:
When using the DirectoryIterator to go through files/folders on Windows
under apache, the path has a mismatch of \ and /
Reproduce code:
---
?php
$dir = new DirectoryIterator( $_SERVER['DOCUMENT_ROOT'] );
echo strong.$dir-getPath()./strongbr /;
foreach($dir as $file ) {
$dirName = $file-getPathname();
echo $dirName.br /;
}
?
Expected result:
With the Document root as C:\HTDOCS Apache returns
$_SERVER['DOCUMENT_ROOT'] as c:/HTDOCS
Expected Output
C:/HTDOCS/.
C:/HTDOCS/..
C:/HTDOCS/css
C:/HTDOCS/index.php
C:/HTDOCS/js
C:/HTDOCS/
Actual result:
--
C:/HTDOCS\.
C:/HTDOCS\..
C:/HTDOCS\css
C:/HTDOCS\index.php
C:/HTDOCS\js
--
Edit bug report at http://bugs.php.net/?id=48547edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48547r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48547r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48547r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48547r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48547r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48547r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48547r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48547r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48547r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48547r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48547r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48547r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48547r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48547r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48547r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48547r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48547r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48547r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48547r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48547r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48547r=mysqlcfg
#44597 [Com]: Postgres driver does not prepare booleans correctly
ID: 44597
Comment by: execut3 at gmail dot com
Reported By: kenaniah at gmail dot com
Status: No Feedback
Bug Type: PDO related
Operating System: Red Hat 4.1.1
PHP Version: 5.2.6
New Comment:
The issue is still not fixed, I'm with PHP 5.2.6 on Ubuntu and
postgresql 8.3.
ERROR: invalid input syntax for type boolean:
Previous Comments:
[2009-05-03 01:00:12] 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-25 15:02:13] 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/
[2009-02-04 03:57:28] kenaniah at gmail dot com
This issue seems like it would be a very easy fix and can be reproduced
without fail, regardless of server environment or PHP version.
A fix would be greatly appreciated
[2008-10-07 19:23:48] dac514 at hotmail dot com
This is happening to me too, OS X and CentOS, PHP 5.2.6
I am converting a web application from MySql to PostgreSQL and i've
run into a roadbloack that is forcing me to find every single boolean
query and manually binding it instead of benefiting from execute()
$input_parameters. PITA! I discovered the explanation to this bug
here:
http://ca.php.net/manual/en/pdostatement.execute.php#84990
As of 5.2.6 you still can't use PDOStatement-execute()
$input_parameters to pass a boolean to PostgreSQL. To do that, you'll
have to call bindParam() with explicit types for *each* parameter in
the query.
Pseudo example, where col5 is of type boolean (i.e. tinyint(1) in
MySQL)
$q = 'INSERT INTO table (col1, col2, col3, col4, col5, col6) VALUES (?
, ?, ?, ?, ?, ?)';
$v = array('foo1', 'foo2', 'foo3', foo4', false, 'foo6');
$st = $db-prepare($q);
$st-execute($v);
PostgreSQL complains and the script dies. Leaving me in the cold and I
have to rewrite the code, which becomes excessively painful when the
queries are dynamically generated. PostgreSQL workaround, boo!
$q = 'INSERT INTO table (col1, col2, col3, col4, col5, col6) VALUES (?
, ?, ?, ?, ?, ?)';
$v = array('foo1', 'foo2', 'foo3', foo4', false, 'foo6');
$st = $db-prepare($q);
$st-bindParam(1, $v[0]], PDO::PARAM_STR);
$st-bindParam(2, $v[1]], PDO::PARAM_STR);
$st-bindParam(3, $v[2]], PDO::PARAM_STR);
$st-bindParam(4, $v[3]], PDO::PARAM_STR);
$st-bindParam(5, $v[4]], PDO::PARAM_BOOL);
$st-bindParam(6, $v[5]], PDO::PARAM_STR);
$st-execute();
Can we get a fix for this soon?
[2008-04-01 21:00:50] kenaniah at gmail dot com
Description:
When using postgres via PDO and attempting to execute an INSERT or
UPDATE query using $stmt-execute(array_values($data)) syntax, postgres
returns an error for any boolean fields that may be present.
Reproduce code:
---
?php
// $db is my PDO connection object
$values = array(true, false);
$sql = UPDATE table SET boolean_column1 = ?, boolean_column2 = ?;
$stmt = $db-prepare($sql);
$stmt-execute($values);
?
Expected result:
PDO will recognize that the values in the array are boolean, and will
provide these values to the prepared statement as correctly-formatted
booleans.
Actual result:
--
PostgreSQL 8.1.9 returns an error stating that the provided values for
the booleans are not in the correct format, and may need to be
type-casted.
--
Edit this bug report at http://bugs.php.net/?id=44597edit=1
#47384 [Opn]: static references resolved incorrectly with class inheritance
ID: 47384
User updated by: alreece45 at gmail dot com
-Summary: self and parent aren't using the class where defined
Reported By: alreece45 at gmail dot com
Status: Open
-Bug Type: Documentation problem
+Bug Type: Scripting Engine problem
Operating System: Linux/Windows
-PHP Version: Irrelevant
+PHP Version: PHP5/PHP6
New Comment:
Perhaps this is not a Documentation Problem, but a scripting problem? I
set it as documentation because I wasn't sure if this behavior was
intentional or not. If it was intentional, the documentation needed to
be updated because it currently says:
Static references to the current class like self:: or __CLASS__ are
resolved using the class in which the function belongs, as in where it
was defined
I'd appreciate it to know, at the very least, if this behavior is
intentional or not for two reasons:
1) Avoid using the feature in PHP projects.
2) So I know if I take the time to try make a patch: I know I didn't
just waste my time (even if I fail).
also: updating the summary to be more clear (hopefully)
Previous Comments:
[2009-02-13 22:55:01] alreece45 at gmail dot com
Description:
When defining properties using constants with parent or self, they are
resolved using computed classes instead of defined classes.
This behavior appears to have existed since PHP 5.0.5 and still exists
in PHP 5.3beta3, a 5.3 CVS snapshot (200902122000), and 5.2 CVS snapshot
(200902121200).
Someone has brought this up before in php-internals:
http://marc.info/?l=php-internalsm=118839969729862w=2
Reproduce code:
---
?php
class Father {
const my_name = 'Father';
public $name = self::my_name;
}
class Son extends Father {
const my_name = 'Son';
public $daddy = parent::my_name;
}
class GrandSon extends Son {
const my_name = 'Grandchild';
}
$older = new GrandSon;
echo {$older-name}\n;
echo {$older-daddy}\n;
?
Expected result:
Father
Father
Actual result:
--
Grandchild
Son
--
Edit this bug report at http://bugs.php.net/?id=47384edit=1
#48548 [NEW]: file_exists() returns false on paths using ../ in middle
From: adam at e-nition dot com
Operating system: Linux
PHP version: 5.2.9
PHP Bug Type: Scripting Engine problem
Bug description: file_exists() returns false on paths using ../ in middle
Description:
The file_exists() function returns false on files that do exist but use a
directory traversal in the path. Not at the start of the path, I mean in
the middle of the path. (This type of path works fine on the include
function)
Works fine on windows apache2.2.11 php5.2.9
Reproduce code:
---
(Example based on a file called 'real_file.php' being placed in a
directory called 'real_dir')
$test_path = 'real_dir/fake_dir/../real_file.php',
if (file_exists($test_path)) {
echo 'File does existbr /';
echo (@include($test_path)) ? 'File included' : 'File NOT included';
} else {
echo 'File does Not existbr /';
echo (@include($test_path)) ? 'File included' : 'File NOT included';
}
Expected result:
File does exist
File included
Actual result:
--
File does NOT exist
File included
--
Edit bug report at http://bugs.php.net/?id=48548edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48548r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48548r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48548r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48548r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48548r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48548r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48548r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48548r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48548r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48548r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48548r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48548r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48548r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48548r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48548r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48548r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48548r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48548r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48548r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48548r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48548r=mysqlcfg
#48549 [NEW]: Loop at start-up
From: jom at grosjo dot net Operating system: Linux OpenSUSE 11.0 x86_64 PHP version: 5.3.0RC3 PHP Bug Type: *General Issues Bug description: Loop at start-up Description: PHP loops (without starting parsing the PHP script) on the following error (while date.timezone is correctly set in /etc/php.ini) Warning: PHP Startup: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Helsinki' for 'EEST/3.0/DST' instead in Unknown on line 0 Reproduce code: --- Compile PHP with following settings ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --enable-mod-charset --with-apxs2=/usr/sbin/apxs --enable-force-cgi-redirect --enable-discard-path --enable-fastcgi --disable-debug --enable-wddx --enable-sigchild --enable-magic-quotes --with-openssl --with-zlib --enable-bcmath --with-bz2 --enable-calendar --with-curl --with-curlwrappers --enable-dba --enable-flatfile --with-db4 --with-gdbm --enable-inifile --enable-ftp --with-gd=/usr --with-gettext --with-gmp --with-imap=/usr -without-interbase --with-ldap=/usr --with-ldap-sasl --enable-mbstring --with-mcrypt --with-mhash --disable-gcov --with-mime-magic --with-mysql --with-mysql-sock=/data/mysql/mysql.sock --with-ncurses --enable-pcntl --without-pdo-firebird --with-pdo-mysql --with-pdo-pgsql --disable-safe-mode --disable-ipv6 --with-ttf=/usr --with-libedit --with-readline --with-mm --enable-shmop --enable-soap --with-snmp --enable-sockets --enable-sysvmsg --enable-sysvsem --enable-sysvshm --enable-xml --with-xmlrpc --with-xsl --enable-zip --enable-largefile s --with-imap-ssl --with-jpeg-dir=/usr --enable-shared --enable-tatic --with-xpm-dir=/usr --with-png-dir=/usr --enable-gd-native-ttf --with-freetype-dir=/usr --with-t1lib --with-config-file-path=/etc --enable-fileinfo --enable-filter --with-pgsql --enable-pcntl --enable-cgi --enable-exif --enable-json --enable-intl --enable-phar --with-pear --with-pic Run ./sapi/cli/php Expected result: - -- Edit bug report at http://bugs.php.net/?id=48549edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48549r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48549r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48549r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48549r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48549r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48549r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48549r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48549r=needscript Try newer version: http://bugs.php.net/fix.php?id=48549r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48549r=support Expected behavior: http://bugs.php.net/fix.php?id=48549r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48549r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48549r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48549r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48549r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48549r=dst IIS Stability: http://bugs.php.net/fix.php?id=48549r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48549r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48549r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48549r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48549r=mysqlcfg
#48550 [NEW]: cURL does not work when the URL has a � character in it.
From: victorepand at gmail dot com Operating system: FreeBSD PHP version: 5.2.9 PHP Bug Type: cURL related Bug description: cURL does not work when the URL has a â character in it. Description: cURL does not work when the URL has a â character in it. Such as, for example, this one: http://www.motorcycle-superstore.com/ProductImages/60/2009_GMax_Womenâs_GM17_Derk_Open-Face_Helmet.jpg Reproduce code: --- $ch=curl_init(); $url=http://www.motorcycle-superstore.com/ProductImages/60/2009_GMax_Womenâs_GM17_Derk_Open-Face_Helmet.jpg; curl_setopt($ch,CURLOPT_URL,$url); $result=curl_exec ($ch); Expected result: thumbnail image in binary stored in result Actual result: -- curl error -- Edit bug report at http://bugs.php.net/?id=48550edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48550r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48550r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48550r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48550r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48550r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48550r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48550r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48550r=needscript Try newer version: http://bugs.php.net/fix.php?id=48550r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48550r=support Expected behavior: http://bugs.php.net/fix.php?id=48550r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48550r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48550r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48550r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48550r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48550r=dst IIS Stability: http://bugs.php.net/fix.php?id=48550r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48550r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48550r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48550r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48550r=mysqlcfg
#47531 [Com]: No way of removing redundant xmlns: declarations
ID: 47531
Comment by: robin2009 at altruists dot org
Reported By: sgunderson at bigfoot dot com
Status: Open
Bug Type: DOM XML related
Operating System: Debian
PHP Version: 5.3CVS-2009-02-28 (snap)
New Comment:
You can run DOMs through an XSLT identity transform to strip redundant
namespaces, since this removes (what it deems to be) unused namespaces
(i.e. namespaces which don't appear as elements or attributes).
This method is not only slow for large DOMs, if you're working with
XSDs or XSLTs, both of which use namespaces inside attribute values, it
would need modification, since XSLT strips them.
Previous Comments:
[2009-02-28 15:19:14] sgunderson at bigfoot dot com
Description:
There seems to be no good way of manipulating XML namespace
declarations at all. In particular, they never get garbage collected in
any way, and you cannot remove them manually, so they will stick around
forever unless you create a new one. My typical use case is shown in the
reproduce code below (although the element will typically have child
elements).
Since 5.3 (bug #38949) it seems I can getAttribute() the xmlns element,
but still not remove it it any reasonable way (and it should really just
disappear by itself; it does in other languages).
Reproduce code:
---
?php
$doc = new DOMDocument;
$doc-loadXML('html xmlns=somethingelement xmlns:ns=whatever
ns:foo=bar //html');
$root = $doc-documentElement;
$elem = $root-firstChild;
$elem-removeAttributeNode($elem-attributes-item(0));
print $doc-saveXML();
?
Expected result:
?xml version=1.0?
html xmlns=somethingelement//html
Actual result:
--
?xml version=1.0?
html xmlns=somethingelement xmlns:ns=whatever//html
--
Edit this bug report at http://bugs.php.net/?id=47531edit=1
#48547 [Com]: DirectoryIterator Slash issue with getPathname Windows with Apache
ID: 48547
Comment by: webmaster at asylum-et dot cm
Reported By: BinaryKitten at jkrswebsolutions dot co dot uk
Status: Open
Bug Type: SPL related
Operating System: XP SP3
PHP Version: 5.2.9
New Comment:
I have tested this on Windows XP SP3 with PHP 5.2.5 and have the same
findings as BinaryKitten at jkrswebsolutions dot co dot uk
Previous Comments:
[2009-06-14 11:47:49] BinaryKitten at jkrswebsolutions dot co dot uk
Description:
When using the DirectoryIterator to go through files/folders on Windows
under apache, the path has a mismatch of \ and /
Reproduce code:
---
?php
$dir = new DirectoryIterator( $_SERVER['DOCUMENT_ROOT'] );
echo strong.$dir-getPath()./strongbr /;
foreach($dir as $file ) {
$dirName = $file-getPathname();
echo $dirName.br /;
}
?
Expected result:
With the Document root as C:\HTDOCS Apache returns
$_SERVER['DOCUMENT_ROOT'] as c:/HTDOCS
Expected Output
C:/HTDOCS/.
C:/HTDOCS/..
C:/HTDOCS/css
C:/HTDOCS/index.php
C:/HTDOCS/js
C:/HTDOCS/
Actual result:
--
C:/HTDOCS\.
C:/HTDOCS\..
C:/HTDOCS\css
C:/HTDOCS\index.php
C:/HTDOCS\js
--
Edit this bug report at http://bugs.php.net/?id=48547edit=1
#47384 [Opn-Bgs]: static references resolved incorrectly with class inheritance
ID: 47384
Updated by: scott...@php.net
Reported By: alreece45 at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Linux/Windows
PHP Version: PHP5/PHP6
New Comment:
You can use static:: in PHP 5.3+ this is Late Static Binding.
Previous Comments:
[2009-06-14 13:51:01] alreece45 at gmail dot com
Perhaps this is not a Documentation Problem, but a scripting problem? I
set it as documentation because I wasn't sure if this behavior was
intentional or not. If it was intentional, the documentation needed to
be updated because it currently says:
Static references to the current class like self:: or __CLASS__ are
resolved using the class in which the function belongs, as in where it
was defined
I'd appreciate it to know, at the very least, if this behavior is
intentional or not for two reasons:
1) Avoid using the feature in PHP projects.
2) So I know if I take the time to try make a patch: I know I didn't
just waste my time (even if I fail).
also: updating the summary to be more clear (hopefully)
[2009-02-13 22:55:01] alreece45 at gmail dot com
Description:
When defining properties using constants with parent or self, they are
resolved using computed classes instead of defined classes.
This behavior appears to have existed since PHP 5.0.5 and still exists
in PHP 5.3beta3, a 5.3 CVS snapshot (200902122000), and 5.2 CVS snapshot
(200902121200).
Someone has brought this up before in php-internals:
http://marc.info/?l=php-internalsm=118839969729862w=2
Reproduce code:
---
?php
class Father {
const my_name = 'Father';
public $name = self::my_name;
}
class Son extends Father {
const my_name = 'Son';
public $daddy = parent::my_name;
}
class GrandSon extends Son {
const my_name = 'Grandchild';
}
$older = new GrandSon;
echo {$older-name}\n;
echo {$older-daddy}\n;
?
Expected result:
Father
Father
Actual result:
--
Grandchild
Son
--
Edit this bug report at http://bugs.php.net/?id=47384edit=1
#48551 [NEW]: Unable to compile
From: hckurniawan at gmail dot com Operating system: Debian 5 PHP version: 5.3.0RC3 PHP Bug Type: Compile Failure Bug description: Unable to compile Description: Compile crash when trying to compile PHAR Reproduce code: --- Compile PHP with PHAR Expected result: PHP Compiled? Actual result: -- PHP 5.3RC3 failed to compile -- Edit bug report at http://bugs.php.net/?id=48551edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48551r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48551r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48551r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48551r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48551r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48551r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48551r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48551r=needscript Try newer version: http://bugs.php.net/fix.php?id=48551r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48551r=support Expected behavior: http://bugs.php.net/fix.php?id=48551r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48551r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48551r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48551r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48551r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48551r=dst IIS Stability: http://bugs.php.net/fix.php?id=48551r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48551r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48551r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48551r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48551r=mysqlcfg
#48551 [Com]: Unable to compile
ID: 48551 Comment by: hckurniawan at gmail dot com Reported By: hckurniawan at gmail dot com Status: Open Bug Type: Compile Failure Operating System: Debian 5 PHP Version: 5.3.0RC3 New Comment: Here's the point where PHP compile crashed with segfault. Generating phar.php /bin/sh: line 1: 11538 Segmentation fault ` if test -x /home/testbuild/php-5.3.0RC3/sapi/cli/php; then /home/testbuild/php-5.3.0RC3/build/shtool echo -n -- /home/testbuild/php-5.3.0RC3/sapi/cli/php -n; if test x/home/testbuild/php-5.3.0RC3/modules/openssl.la /home/testbuild/php-5.3.0RC3/modules/sqlite3.la /home/testbuild/php-5.3.0RC3/modules/zlib.la /home/testbuild/php-5.3.0RC3/modules/bz2.la /home/testbuild/php-5.3.0RC3/modules/curl.la /home/testbuild/php-5.3.0RC3/modules/gd.la /home/testbuild/php-5.3.0RC3/modules/imap.la /home/testbuild/php-5.3.0RC3/modules/mbstring.la /home/testbuild/php-5.3.0RC3/modules/mcrypt.la /home/testbuild/php-5.3.0RC3/modules/mysql.la /home/testbuild/php-5.3.0RC3/modules/pdo.la /home/testbuild/php-5.3.0RC3/modules/pdo_mysql.la /home/testbuild/php-5.3.0RC3/modules/pdo_pgsql.la /home/testbuild/php-5.3.0RC3/modules/pdo_sqlite.la /home/testbuild/php-5.3.0RC3/modules/pgsql.la /home/testbuild/php-5.3.0RC3/modules/soap.la /home/testbuild/php-5.3.0RC3/modules/sqlite.la /home/testbuild/php-5.3.0RC3/modules/xmlrpc.la /home/testbuild/php-5.3.0RC3/modules/xsl.la /home/testbuild/php-5.3.0RC3/modules/zip.la != x; then /home/testbuild/php-5.3.0RC3/build/shtool echo -n -- -d extension_dir=/home/testbuild/php-5.3.0RC3/modules; for i in bz2 zlib phar; do if test -f /home/testbuild/php-5.3.0RC3/modules/$i.la; then . /home/testbuild/php-5.3.0RC3/modules/$i.la; /home/testbuild/php-5.3.0RC3/build/shtool echo -n -- -d extension=$dlname; fi; done; fi; else /home/testbuild/php-5.3.0RC3/build/shtool echo -n -- ; fi;` -d 'open_basedir=' -d 'output_buffering=0' -d 'memory_limit=-1' -d phar.readonly=0 -d 'safe_mode=0' /home/testbuild/php-5.3.0RC3/ext/phar/build_precommand.php ext/phar/phar.php make: *** [ext/phar/phar.php] Error 139 Previous Comments: [2009-06-14 23:53:49] hckurniawan at gmail dot com Description: Compile crash when trying to compile PHAR Reproduce code: --- Compile PHP with PHAR Expected result: PHP Compiled? Actual result: -- PHP 5.3RC3 failed to compile -- Edit this bug report at http://bugs.php.net/?id=48551edit=1
#48552 [NEW]: register_shutdown_function random behavior on different platforms after exit
From: cagret at gmail dot com
Operating system: Win/Linux/Apache/Lighttpd
PHP version: 5.2.9
PHP Bug Type: Unknown/Other Function
Bug description: register_shutdown_function random behavior on different
platforms after exit
Description:
Function registered with register_shutdown_function() sometimes is
executed / sometimes it is not, after you exit (outside of registered
function) - depends on php configuration.
Win+Apache+php5 as mod - shutdown.txt IS NOT created.
Win+Apache+php5 as cgi - shutdown.txt IS created
Win+Apache+php4 as mod - shutdown.txt IS created
Win+Lighttpd+php5 as fcgi - shutdown.txt IS created
Linux+Apache+php4 as mod - shutdown.txt IS created
Linux+Lighttpd+php5 as fcgi - shutdown.txt IS created
I've thought this is a bug on Win+Apache+php5asmod, and reported it, but
j...@php.net (http://bugs.php.net/bug.php?id=48475) says it is an expected
behavior: Expected behaviour. exit() is supposed to exit immediately.
Nothing is supposed to be run after you call exit.
If this is an expected behavior, then seems like there is a bug on other
php configurations.
Reproduce code:
---
?php
function shutdown()
{
file_put_contents(dirname(__FILE__).'/shutdown.txt', time());
}
register_shutdown_function('shutdown');
exit();
?
Expected result:
shutdown.txt should not be created.
Actual result:
--
shutdown.txt is created
--
Edit bug report at http://bugs.php.net/?id=48552edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48552r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48552r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48552r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48552r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48552r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48552r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48552r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48552r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48552r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48552r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48552r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48552r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48552r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48552r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48552r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48552r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48552r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48552r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48552r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48552r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48552r=mysqlcfg
