[PHP-BUG] Bug #53217 [NEW]: PDO treats backslashes in pgsql passwords as escape characters
From:
Operating system: Ubuntu 10.04 AMD64 W/S
PHP version: 5.3.3
Package: PDO related
Bug Type: Bug
Bug description:PDO treats backslashes in pgsql passwords as escape characters
Description:
When using a password containing a backslash to connect to PostgreSQL
database via PDO the driver appears to be treating the backslash as an
escape charcter.
The problem is not global to PDO since MySQL works as expected.
It is not global to libpq since PearDB and the psql command line tool work
as expected.
Further explanation in the comments in the test script.
Test script:
---
$host = 'localhost';
$database = 'imix';
$username = 'imix';
// Password is |\/|ix3dUp
/*
Works for MySQL - Doesn't work for pgsql - wireshark shows |/x3edUp sent
to server, error message shows password correctly
*/
$mysql_password = '|\/|ix3dUp';
/*
Doesn't work for pg - |/x3edUp still sent to server - error message still
shows password correctly - this is because \ is one of the two chars
escaped in a single quoted string
*/
// $password = '|\\/|ix3dUp';
/*
Works for pgsql, not for mysql - Error message on mysql attempt shows two
backslashes
Initial parse treats the first one as an escape, handing two to PDO -
pgsql driver seems to interpret the first remaining one as an escape which
really doesn't sound right ...
*/
$pgsql_password = '|\\\/|ix3dUp';
$mysql_connection = new PDO('mysql:host='.$host.';dbname='.$database,
$username, $mysql_password);
$pgsql_connection = new PDO('pgsql:host='.$host.';dbname='.$database,
$username, $pgsql_password);
Expected result:
I would expect the password as used for MySQL to work for both the engines.
Actual result:
--
Test script as it stands executes without error.
--
Edit bug report at http://bugs.php.net/bug.php?id=53217&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53217&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53217&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53217&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53217&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53217&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53217&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53217&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53217&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53217&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53217&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53217&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53217&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53217&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53217&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53217&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53217&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53217&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53217&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53217&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53217&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53217&r=mysqlcfg
Bug #53210 [Com]: mysql_fetch_assoc (mysql_query (SQL) inside a while loop can cause DoS
Edit report at http://bugs.php.net/bug.php?id=53210&edit=1
ID: 53210
Comment by: exilianmelody at google dot com
Reported by:yoyahack at undersecurity dot net
Summary:mysql_fetch_assoc (mysql_query (SQL) inside a while
loop can cause DoS
Status: Open
Type: Bug
Package:Filesystem function related
Operating System: Fedora 13
PHP Version:5.3.3
Block user comment: N
New Comment:
hi,buddy, in my thought,you just have a structure mistake,because in
while loop,it have to have a static value,but your argument is a dynamic
generated,so everytime anyhow the while loop is true,and each output
record is the first item in your table,except your table is empty.solve
it below:
$link = mysql_connect('127.0.0.1','root', 'root');
mysql_select_db('test', $link);
$resouce = mysql_query('select * from table', $link);
while($row = mysql_fetch_assoc($resource))
{
echo $row['col1'].nl2br('/r');
}
Previous Comments:
[2010-10-30 22:54:59] yoyahack at undersecurity dot net
Description:
If income mysql_fetch_assoc (mysql_query (SQL) within a while loop cause
denial
of service
Test script:
---
Expected result:
it generates an infinite loop that never ends
--
Edit this bug report at http://bugs.php.net/bug.php?id=53210&edit=1
Bug #53210 [Com]: mysql_fetch_assoc (mysql_query (SQL) inside a while loop can cause DoS
Edit report at http://bugs.php.net/bug.php?id=53210&edit=1
ID: 53210
Comment by: exilianmelody at gmail dot com
Reported by:yoyahack at undersecurity dot net
Summary:mysql_fetch_assoc (mysql_query (SQL) inside a while
loop can cause DoS
Status: Open
Type: Bug
Package:Filesystem function related
Operating System: Fedora 13
PHP Version:5.3.3
Block user comment: N
New Comment:
i am so sorry for leaved my incorrect mail adress,:)
Previous Comments:
[2010-11-01 08:12:54] exilianmelody at google dot com
hi,buddy, in my thought,you just have a structure mistake,because in
while loop,it have to have a static value,but your argument is a dynamic
generated,so everytime anyhow the while loop is true,and each output
record is the first item in your table,except your table is empty.solve
it below:
$link = mysql_connect('127.0.0.1','root', 'root');
mysql_select_db('test', $link);
$resouce = mysql_query('select * from table', $link);
while($row = mysql_fetch_assoc($resource))
{
echo $row['col1'].nl2br('/r');
}
[2010-10-30 22:54:59] yoyahack at undersecurity dot net
Description:
If income mysql_fetch_assoc (mysql_query (SQL) within a while loop cause
denial
of service
Test script:
---
Expected result:
it generates an infinite loop that never ends
--
Edit this bug report at http://bugs.php.net/bug.php?id=53210&edit=1
Bug #50977 [Com]: imap_headerinfo Address buffer overflow
Edit report at http://bugs.php.net/bug.php?id=50977&edit=1 ID: 50977 Comment by: paul at fubra dot com Reported by:lokitek at gmail dot com Summary:imap_headerinfo Address buffer overflow Status: Feedback Type: Bug Package:IMAP related Operating System: CentOS 5.4 PHP Version:5.2.12 Block user comment: N New Comment: I'm also experiencing this error with CentOS release 5.3 (Final). yum list libc-client libc-client.i386 2004g-2.2.1 Previous Comments: [2010-04-25 20:06:28] fel...@php.net Any news? [2010-02-20 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2010-02-10 20:26:50] lokitek at gmail dot com drop centOS isn't all that easy - What would you recommend instead? ;) I'll update c-client and will let you know. Thanks! [2010-02-10 16:24:41] paj...@php.net Yes, or you may drop centos as well, known to have outdated versions of everything. Please let us know if it still happens once you have a decent version if c-client. [2010-02-10 16:06:17] lokitek at gmail dot com The c-client library is: libc-client 2004g-2.2.1 2004 sounds somewhat old, should I try to find an upgrade for it? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=50977 -- Edit this bug report at http://bugs.php.net/bug.php?id=50977&edit=1
Bug #1164 [Com]: Unable to connect to PostgreSQL, unsupported protocol
Edit report at http://bugs.php.net/bug.php?id=1164&edit=1 ID: 1164 Comment by: lakshmi at nace dot co dot in Reported by:B dot Ogryczak at students dot mimuw dot edu dot pl Summary:Unable to connect to PostgreSQL, unsupported protocol Status: Closed Type: Bug Package:PostgreSQL related Operating System: Linux (RH 5.2) PHP Version:3.0.5 Block user comment: N New Comment: i couldnt able to connect to postgresql database, when i am using pg_connect it is simply throwing an error as undefined function pg_connect() Previous Comments: [1999-02-20 12:49:15] eschmid It's not a PHP problem. Can you connect throu the psql-monitor? If you can, you should be able to connect from PHP as well. [1999-02-19 12:07:47] B dot Ogryczak at students dot mimuw dot edu dot pl Since version 6.4.x PostgreSQL introduced new frontend/backend protocol (v 2.0), even tho I recompiled PHP3 with the new libpg it doesn't support this protocol. I get error: Unable to connect to PostgreSQL server, Unsupported frontend protocol in ... I'm running Linux, RH 5.2 with PostgreSQL 6.4.2 PHP 3.0.5. -- Edit this bug report at http://bugs.php.net/bug.php?id=1164&edit=1
Bug #1164 [Com]: Unable to connect to PostgreSQL, unsupported protocol
Edit report at http://bugs.php.net/bug.php?id=1164&edit=1 ID: 1164 Comment by: lakshmi at nace dot co dot in Reported by:B dot Ogryczak at students dot mimuw dot edu dot pl Summary:Unable to connect to PostgreSQL, unsupported protocol Status: Closed Type: Bug Package:PostgreSQL related Operating System: Linux (RH 5.2) PHP Version:3.0.5 Block user comment: N New Comment: Hi, Can anyone tell me what would be the mistake in below mentioned program, when I execute this program simply it is throwing an error as : Call to undefined function pg_connect(),I can able to connect from psql separately but while trying to connect it from php it is throwing error. " .pg_last_error(). pg_errormessage($database)); } ?> Previous Comments: [2010-11-01 12:07:54] lakshmi at nace dot co dot in i couldnt able to connect to postgresql database, when i am using pg_connect it is simply throwing an error as undefined function pg_connect() [1999-02-20 12:49:15] eschmid It's not a PHP problem. Can you connect throu the psql-monitor? If you can, you should be able to connect from PHP as well. [1999-02-19 12:07:47] B dot Ogryczak at students dot mimuw dot edu dot pl Since version 6.4.x PostgreSQL introduced new frontend/backend protocol (v 2.0), even tho I recompiled PHP3 with the new libpg it doesn't support this protocol. I get error: Unable to connect to PostgreSQL server, Unsupported frontend protocol in ... I'm running Linux, RH 5.2 with PostgreSQL 6.4.2 PHP 3.0.5. -- Edit this bug report at http://bugs.php.net/bug.php?id=1164&edit=1
Bug #47643 [Asn->Csd]: array_diff() takes over 3000 times longer than php 5.2.4
Edit report at http://bugs.php.net/bug.php?id=47643&edit=1 ID: 47643 Updated by: fel...@php.net Reported by:viper7 at viper-7 dot com Summary:array_diff() takes over 3000 times longer than php 5.2.4 -Status: Assigned +Status: Closed Type: Bug Package:Performance problem Operating System: * PHP Version:5.*, 6CVS (2009-04-13) Assigned To:felipe Block user comment: N New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2010-11-01 18:16:49] fel...@php.net Automatic comment from SVN on behalf of felipe Revision: http://svn.php.net/viewvc/?view=revision&revision=305011 Log: - Fixed bug #47643 (array_diff() takes over 3000 times longer than php 5.2.4) [2010-08-04 05:21:29] lonnyk at gmail dot com I feel as though the actual bug here is the fix that caused this issue. If you revert the fix and typecast the variables passed into the custom compare function as (string) then this works fine. This is in line with other non-user defined comparison functions, they compare as === and not == [2010-04-16 22:20:37] sylvain at jamendo dot com I would also appreciate a patch, this issue made our servers crash after a php 5.3 upgrade :-/ thanks! [2010-02-17 20:53:53] maarten at talkin dot nl Why dont you only reset ptr if (behavior & DIFF_ASSOC) ? [2010-01-17 12:09:15] emiel dot bruijntjes at copernica dot com This bug is now open for 10 months. Are you still working on this? 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/bug.php?id=47643 -- Edit this bug report at http://bugs.php.net/bug.php?id=47643&edit=1
Bug #53217 [Opn->Bgs]: PDO treats backslashes in pgsql passwords as escape characters
Edit report at http://bugs.php.net/bug.php?id=53217&edit=1
ID: 53217
Updated by: fel...@php.net
Reported by:bell at ctrlf5 dot co dot za
Summary:PDO treats backslashes in pgsql passwords as escape
characters
-Status: Open
+Status: Bogus
Type: Bug
Package:PDO related
Operating System: Ubuntu 10.04 AMD64 W/S
PHP Version:5.3.3
Block user comment: N
New Comment:
This is due the libpq behavior. See
http://www.postgresql.org/docs/8.1/static/libpq.html
Previous Comments:
[2010-11-01 08:04:30] bell at ctrlf5 dot co dot za
Description:
When using a password containing a backslash to connect to PostgreSQL
database via PDO the driver appears to be treating the backslash as an
escape charcter.
The problem is not global to PDO since MySQL works as expected.
It is not global to libpq since PearDB and the psql command line tool
work as expected.
Further explanation in the comments in the test script.
Test script:
---
$host = 'localhost';
$database = 'imix';
$username = 'imix';
// Password is |\/|ix3dUp
/*
Works for MySQL - Doesn't work for pgsql - wireshark shows |/x3edUp
sent to server, error message shows password correctly
*/
$mysql_password = '|\/|ix3dUp';
/*
Doesn't work for pg - |/x3edUp still sent to server - error message
still shows password correctly - this is because \ is one of the two
chars escaped in a single quoted string
*/
// $password = '|\\/|ix3dUp';
/*
Works for pgsql, not for mysql - Error message on mysql attempt shows
two backslashes
Initial parse treats the first one as an escape, handing two to PDO -
pgsql driver seems to interpret the first remaining one as an escape
which really doesn't sound right ...
*/
$pgsql_password = '|\\\/|ix3dUp';
$mysql_connection = new PDO('mysql:host='.$host.';dbname='.$database,
$username, $mysql_password);
$pgsql_connection = new PDO('pgsql:host='.$host.';dbname='.$database,
$username, $pgsql_password);
Expected result:
I would expect the password as used for MySQL to work for both the
engines.
Actual result:
--
Test script as it stands executes without error.
--
Edit this bug report at http://bugs.php.net/bug.php?id=53217&edit=1
Req #53215 [Bgs]: Method overload on PHP
Edit report at http://bugs.php.net/bug.php?id=53215&edit=1
ID: 53215
User updated by:jonimane at gmail dot com
Reported by:jonimane at gmail dot com
Summary:Method overload on PHP
Status: Bogus
Type: Feature/Change Request
Package:Class/Object related
Operating System: Windows XP
PHP Version:Irrelevant
Block user comment: N
New Comment:
hm =/
To polymorphism would greatly help
function t(Test $t)
{
...
}
function t(NoTest $t)
{
...
}
so, thank you anyway =]
if it were implemented would be great *-*
thx again =]
Previous Comments:
[2010-11-01 04:55:07] cataphr...@php.net
Not adequate to PHP for several reasons:
* Type of arguments cannot be provided expect in limited circumstances,
and even then it's not required.
* The only differentiating factor would be the number of arguments, but
in PHP a function can take more arguments than it declares, so even
then...
[2010-11-01 01:34:11] jonimane at gmail dot com
Description:
Can you implements overload methods?
look test script x.x
my english is so so bad, sorry.
if you didn't understand me, i can explain you x.x
thx
Test script:
---
hello(); // print "hello"
$c->hello("PHP"); // print "hello PHP"
?>
Expected result:
don't give errors and method overload work
Actual result:
--
Fatal error: Cannot redeclare Test::hello() in C:\...\Test.php on line 9
--
Edit this bug report at http://bugs.php.net/bug.php?id=53215&edit=1
Bug #53217 [Com]: PDO treats backslashes in pgsql passwords as escape characters
Edit report at http://bugs.php.net/bug.php?id=53217&edit=1
ID: 53217
Comment by: bell at ctrlf5 dot co dot za
Reported by:bell at ctrlf5 dot co dot za
Summary:PDO treats backslashes in pgsql passwords as escape
characters
Status: Bogus
Type: Bug
Package:PDO related
Operating System: Ubuntu 10.04 AMD64 W/S
PHP Version:5.3.3
Block user comment: N
New Comment:
So you believe that it is not PDO's responsibility to escape input
values before passing them to underlying functions?
That doesn't sound right.
Previous Comments:
[2010-11-01 18:24:06] fel...@php.net
This is due the libpq behavior. See
http://www.postgresql.org/docs/8.1/static/libpq.html
[2010-11-01 08:04:30] bell at ctrlf5 dot co dot za
Description:
When using a password containing a backslash to connect to PostgreSQL
database via PDO the driver appears to be treating the backslash as an
escape charcter.
The problem is not global to PDO since MySQL works as expected.
It is not global to libpq since PearDB and the psql command line tool
work as expected.
Further explanation in the comments in the test script.
Test script:
---
$host = 'localhost';
$database = 'imix';
$username = 'imix';
// Password is |\/|ix3dUp
/*
Works for MySQL - Doesn't work for pgsql - wireshark shows |/x3edUp
sent to server, error message shows password correctly
*/
$mysql_password = '|\/|ix3dUp';
/*
Doesn't work for pg - |/x3edUp still sent to server - error message
still shows password correctly - this is because \ is one of the two
chars escaped in a single quoted string
*/
// $password = '|\\/|ix3dUp';
/*
Works for pgsql, not for mysql - Error message on mysql attempt shows
two backslashes
Initial parse treats the first one as an escape, handing two to PDO -
pgsql driver seems to interpret the first remaining one as an escape
which really doesn't sound right ...
*/
$pgsql_password = '|\\\/|ix3dUp';
$mysql_connection = new PDO('mysql:host='.$host.';dbname='.$database,
$username, $mysql_password);
$pgsql_connection = new PDO('pgsql:host='.$host.';dbname='.$database,
$username, $pgsql_password);
Expected result:
I would expect the password as used for MySQL to work for both the
engines.
Actual result:
--
Test script as it stands executes without error.
--
Edit this bug report at http://bugs.php.net/bug.php?id=53217&edit=1
Bug #53141 [Opn]: autoload misbehaves if called from closing session
Edit report at http://bugs.php.net/bug.php?id=53141&edit=1
ID: 53141
User updated by:ladislav at marek dot su
Reported by:ladislav at marek dot su
Summary:autoload misbehaves if called from closing session
Status: Open
Type: Bug
Package:SPL related
Operating System: GNU Linux
PHP Version:5.3SVN-2010-10-23 (SVN)
Block user comment: N
New Comment:
It looks like that --with-mysql=mysqlnd configuration causes different
order of
extensions, so SPL extension is destroyed before the session is.
Adding session dependency to SPL fixes this bug (I'm not sure if is it
correct
way).
Previous Comments:
[2010-10-24 13:51:55] ladislav at marek dot su
I can reproduce it with '--with-mysql=mysqlnd' configuration.
[2010-10-23 17:38:12] ladislav at marek dot su
I updated PHP from the SVN (rev 304664). With PHP compiled only with
"--with-config-file-path=/etc/php" script runs as
expected, but fails with configure options:
--with-config-file-path=/etc/php --with-openssl --with-kerberos
--with-zlib --enable-bcmath --with-bz2 --with-curl --with-
curlwrappers --enable-dba --enable-ftp --with-gd
--with-jpeg-dir=/usr/include --with-png-dir=/usr/include --with-zlib-
dir=/usr/include --with-xpm-dir=/usr/include
--with-freetype-dir=/usr/lib --enable-gd-native-ttf --with-gettext
--with-mhash
--with-imap --with-imap-ssl --with-ldap --enable-mbstring --with-mcrypt
--with-mysql=mysqlnd --with-mysqli=mysqlnd --with-
pdo-mysql=mysqlnd --with-pdo-pgsql --with-pgsql --enable-shmop
--enable-soap --enable-sockets --enable-sqlite-utf8 --enable-
sysvmsg --with-tidy --with-xmlrpc --with-xsl --enable-zip --enable-intl
--enable-fpm
[2010-10-23 16:55:02] fel...@php.net
I got the expected result when testing on the 5.3 SVN version. Are you
actually using the lastest SVN version?
[2010-10-23 10:36:09] ladislav at marek dot su
Description:
SPL autoload triggers fatal error if is called from currently closing
session.
With __autoload function scripts works fine.
Test script:
---
spl_autoload_register(function ($class) {
var_dump("Loading $class");
eval('class Bar {}');
});
class Foo
{
function __sleep()
{
new Bar;
return array();
}
}
session_start();
$_SESSION['foo'] = new Foo;
Expected result:
string(11) "Loading Bar"
Actual result:
--
Fatal error: spl_autoload(): Class Bar could not be loaded in
/var/www/hosts/tests.l/index.php on line 14
--
Edit this bug report at http://bugs.php.net/bug.php?id=53141&edit=1
Bug #53217 [Bgs->Opn]: PDO treats backslashes in pgsql passwords as escape characters
Edit report at http://bugs.php.net/bug.php?id=53217&edit=1
ID: 53217
Updated by: fel...@php.net
Reported by:bell at ctrlf5 dot co dot za
Summary:PDO treats backslashes in pgsql passwords as escape
characters
-Status: Bogus
+Status: Open
Type: Bug
Package:PDO related
Operating System: Ubuntu 10.04 AMD64 W/S
PHP Version:5.3.3
Block user comment: N
New Comment:
Well, I was wondering about the connect string using the password with
others parameters, not when using the password on a separated parameter
(as in your example). In this case, I guess it could be escaped, as
requested.
Previous Comments:
[2010-11-01 18:44:20] bell at ctrlf5 dot co dot za
So you believe that it is not PDO's responsibility to escape input
values before passing them to underlying functions?
That doesn't sound right.
[2010-11-01 18:24:06] fel...@php.net
This is due the libpq behavior. See
http://www.postgresql.org/docs/8.1/static/libpq.html
[2010-11-01 08:04:30] bell at ctrlf5 dot co dot za
Description:
When using a password containing a backslash to connect to PostgreSQL
database via PDO the driver appears to be treating the backslash as an
escape charcter.
The problem is not global to PDO since MySQL works as expected.
It is not global to libpq since PearDB and the psql command line tool
work as expected.
Further explanation in the comments in the test script.
Test script:
---
$host = 'localhost';
$database = 'imix';
$username = 'imix';
// Password is |\/|ix3dUp
/*
Works for MySQL - Doesn't work for pgsql - wireshark shows |/x3edUp
sent to server, error message shows password correctly
*/
$mysql_password = '|\/|ix3dUp';
/*
Doesn't work for pg - |/x3edUp still sent to server - error message
still shows password correctly - this is because \ is one of the two
chars escaped in a single quoted string
*/
// $password = '|\\/|ix3dUp';
/*
Works for pgsql, not for mysql - Error message on mysql attempt shows
two backslashes
Initial parse treats the first one as an escape, handing two to PDO -
pgsql driver seems to interpret the first remaining one as an escape
which really doesn't sound right ...
*/
$pgsql_password = '|\\\/|ix3dUp';
$mysql_connection = new PDO('mysql:host='.$host.';dbname='.$database,
$username, $mysql_password);
$pgsql_connection = new PDO('pgsql:host='.$host.';dbname='.$database,
$username, $pgsql_password);
Expected result:
I would expect the password as used for MySQL to work for both the
engines.
Actual result:
--
Test script as it stands executes without error.
--
Edit this bug report at http://bugs.php.net/bug.php?id=53217&edit=1
Req #52173 [Opn->Tbd]: ext/pcntl doesn't store/report errors
Edit report at http://bugs.php.net/bug.php?id=52173&edit=1 ID: 52173 Updated by: lbarn...@php.net Reported by:nick dot telford at gmail dot com Summary:ext/pcntl doesn't store/report errors -Status: Open +Status: To be documented Type: Feature/Change Request Package:PCNTL related Operating System: Linux PHP Version:trunk-SVN-2010-06-24 (SVN) Block user comment: N New Comment: Fixed, thanks ! Previous Comments: [2010-11-01 21:22:26] lbarn...@php.net Automatic comment from SVN on behalf of lbarnaud Revision: http://svn.php.net/viewvc/?view=revision&revision=305016 Log: MFH Fix bug #52173 (ext/pcntl doesn't store/report errors) (patch by nick dot telford at gmail dot com) [2010-11-01 21:10:19] lbarn...@php.net Automatic comment from SVN on behalf of lbarnaud Revision: http://svn.php.net/viewvc/?view=revision&revision=305015 Log: Fix bug #52173 (ext/pcntl doesn't store/report errors) (patch by nick dot telford at gmail dot com) [2010-06-24 19:10:03] nick dot telford at gmail dot com I've attached a patch that implements solution #3. The patch used the extent of my amazing copy/paste skills to extract the posix_get_last_error() and posix_strerror() functionality from ext/posix and duplicate it in ext/pcntl. If there's anything wrong with this patch, please let me know. But let me down lately - this is the first time I've written (if you can call it that) any C, let alone worked on a PHP extension. We've all gotta start somewhere :) If you need me to write tests etc. please let me know, also any tips on how to go about doing so. I've tested this using the example in the description and it works a treat. [2010-06-24 18:19:05] phi...@php.net I like option #3. [2010-06-24 16:58:59] nick dot telford at gmail dot com Minor addendum: A solid use-case as to why it is useful for the userland code to read the error code. When calling pcntl_wait(), -1 will be returned if there are no child processes running (errno == ECHILD) and also if the call is interrupted by a signal (errno == EINTR). This makes determining whether there are children left to wait on tricky, as -1 could simply be an interrupt from a signal being handled. 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/bug.php?id=52173 -- Edit this bug report at http://bugs.php.net/bug.php?id=52173&edit=1
[PHP-BUG] Bug #53219 [NEW]: Argentina's DST setting is wrong - DST should not be applied
From:
Operating system: Ubuntu Linux
PHP version: Irrelevant
Package: Date/time related
Bug Type: Bug
Bug description:Argentina's DST setting is wrong - DST should not be applied
Description:
I'm trying to troubleshoot and solve this problem: the server I'm working
on (php 5.2.9 on Linux), has the correct local time
(America/Buenos_Aires):
u...@server [/home/site/public_html]$ date
Mon Nov 1 17:11:14 ART 2010
php.ini is set with date.timezone = "America/Buenos_Aires" I also tried to
set the timezone directly in the script with
";
echo "ini: ", ini_get('date.timezone'), "";
$now = date("H:i:s T I");
$nowdate = date("Y-m-d");
echo $nowdate." ".$now;
?>
but to no avail, the result is
ini: America/Buenos_Aires
2010-11-01 18:11:14 ARST 1
when it should read 17:11 (It's consistently one hour ahead).
I checked and as you can see in the code, PHP thinks it should be applying
DST, and Argentina decided to not apply it this year.
I tried dumping the timezones transition as suggested. I got the
following:
The timezone America/Buenos_Aires switches to standard time on 20 Mar 2011
@ 02:00.
The new GMT offset will be: -10800 (ART)
--
Edit bug report at http://bugs.php.net/bug.php?id=53219&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53219&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53219&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53219&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53219&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53219&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53219&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53219&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53219&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53219&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53219&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53219&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53219&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53219&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53219&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53219&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53219&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53219&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53219&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53219&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53219&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53219&r=mysqlcfg
[PHP-BUG] Bug #53220 [NEW]: 'make install' fails in a phar install phase
From: Operating system: armv5tel-linux PHP version: 5.3.3 Package: PHAR related Bug Type: Bug Bug description:'make install' fails in a phar install phase Description: php 5.3.3 fails to install the pear phar archive in the default installation, so the "make install" phase fails. Here is an excerpt of the log: building install-pear-installer phar "/tmp/nix-build-9p0djf6sp8zavcpqy5wmyzd69v4745l2-php_configurable-5.3.3.drv-0/php-5.3.3/pear/install-pear-nozlib.phar" does not have a signature Warning: require_once(phar://install-pear-nozlib.phar/index.php): failed to open stream: phar error: invalid url or non-existent phar "phar://install-pear-nozlib.phar/index.php" in /tmp/nix-build-9p0djf6sp8zavcpqy5wmyzd69v4745l2-php_configurable-5.3.3.drv-0/php-5.3.3/pear/install-pear-nozlib.phar on line 1236 make[1]: *** [install-pear-installer] Error 255 The same build and install script works in x86_64-linux and mips-linux, but on armv5tel-linux it fails. If I run manually the line as specified in the Makefile.frag, I get the same error: # ../sapi/cli/php -n -dshort_open_tag=0 -dsafe_mode=0 -dopen_basedir= -derror_reporting=1803 -dmemory_limit=-1 -ddetect_unicode=0 install-pear-nozlib.phar -d /tmp/pear phar "/tmp/nix-build-9p0djf6sp8zavcpqy5wmyzd69v4745l2-php_configurable-5.3.3.drv-0/php-5.3.3/pear/install-pear-nozlib.phar" does not have a signature If I run the same line calling php 5.2.13 (which I had around) instead of the just compiled 5.3.3, the complain does not appear. I'm using gcc 4.5.1, glibc 2.12.1, linux 2.6.35.3, in a native build on NixOS. Test script: --- ../sapi/cli/php -n -dshort_open_tag=0 -dsafe_mode=0 -dopen_basedir= -derror_reporting=1803 -dmemory_limit=-1 -ddetect_unicode=0 install-pear-nozlib.phar -d /tmp/pear Expected result: In other systems, I see that the install-pear-nozlib.phar file gets installed normally. Actual result: -- phar "/tmp/nix-build-9p0djf6sp8zavcpqy5wmyzd69v4745l2-php_configurable-5.3.3.drv-0/php-5.3.3/pear/install-pear-nozlib.phar" does not have a signature Warning: require_once(phar://install-pear-nozlib.phar/index.php): failed to open stream: phar error: invalid url or non-existent phar "phar://install-pear-nozlib.phar/index.php" in /tmp/nix-build-9p0djf6sp8zavcpqy5wmyzd69v4745l2-php_configurable-5.3.3.drv-0/php-5.3.3/pear/install-pear-nozlib.phar on line 1236 -- Edit bug report at http://bugs.php.net/bug.php?id=53220&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53220&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53220&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53220&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53220&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53220&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53220&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53220&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53220&r=needscript Try newer version: http://bugs.php.net/fix.php?id=53220&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53220&r=support Expected behavior: http://bugs.php.net/fix.php?id=53220&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53220&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53220&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53220&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53220&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53220&r=dst IIS Stability: http://bugs.php.net/fix.php?id=53220&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53220&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53220&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53220&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53220&r=mysqlcfg
[PHP-BUG] Bug #53221 [NEW]: Date since epoch is incorrect
From: Operating system: Windows 7 PHP version: 5.3.3 Package: Date/time related Bug Type: Bug Bug description:Date since epoch is incorrect Description: Checked the number of seconds since the epoch using the code shown in the 'Test script' section below. There is a discrepancy when number of seconds = 100 in that time goes backwards, i.e. 1973 to 2001 to 2014 to 2008. Number of seconds since epoch = 1, date = 1 January 1970 01:00:01 Number of seconds since epoch = 10, date = 1 January 1970 01:00:10 Number of seconds since epoch = 100, date = 1 January 1970 01:01:40 Number of seconds since epoch = 1000, date = 1 January 1970 01:16:40 Number of seconds since epoch = 1, date = 1 January 1970 03:46:40 Number of seconds since epoch = 10, date = 2 January 1970 04:46:40 Number of seconds since epoch = 100, date = 12 January 1970 14:46:40 Number of seconds since epoch = 1000, date = 26 April 1970 18:46:40 Number of seconds since epoch = 1, date = 3 March 1973 10:46:40 Number of seconds since epoch = 10, date = 9 September 2001 03:46:40 Number of seconds since epoch = 100, date = 7 September 2014 06:50:08 Number of seconds since epoch = 1000, date = 11 July 2008 06:56:32 Test script: --- "; } ?> -- Edit bug report at http://bugs.php.net/bug.php?id=53221&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53221&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53221&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53221&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53221&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53221&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53221&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53221&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53221&r=needscript Try newer version: http://bugs.php.net/fix.php?id=53221&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53221&r=support Expected behavior: http://bugs.php.net/fix.php?id=53221&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53221&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53221&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53221&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53221&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53221&r=dst IIS Stability: http://bugs.php.net/fix.php?id=53221&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53221&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53221&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53221&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53221&r=mysqlcfg
Bug #53221 [Opn->Bgs]: Date since epoch is incorrect
Edit report at http://bugs.php.net/bug.php?id=53221&edit=1 ID: 53221 Updated by: ras...@php.net Reported by:c dot d dot claxton at googlemail dot com Summary:Date since epoch is incorrect -Status: Open +Status: Bogus Type: Bug Package:Date/time related Operating System: Windows 7 PHP Version:5.3.3 Block user comment: N New Comment: It is just a 32-bit signed integer overflow. Note that even 64-bit Windows still uses 32-bit integers. Platforms with 64-bit integers won't overflow and don't have this problem. Not much we can do about this. Previous Comments: [2010-11-01 22:18:00] c dot d dot claxton at googlemail dot com Description: Checked the number of seconds since the epoch using the code shown in the 'Test script' section below. There is a discrepancy when number of seconds = 100 in that time goes backwards, i.e. 1973 to 2001 to 2014 to 2008. Number of seconds since epoch = 1, date = 1 January 1970 01:00:01 Number of seconds since epoch = 10, date = 1 January 1970 01:00:10 Number of seconds since epoch = 100, date = 1 January 1970 01:01:40 Number of seconds since epoch = 1000, date = 1 January 1970 01:16:40 Number of seconds since epoch = 1, date = 1 January 1970 03:46:40 Number of seconds since epoch = 10, date = 2 January 1970 04:46:40 Number of seconds since epoch = 100, date = 12 January 1970 14:46:40 Number of seconds since epoch = 1000, date = 26 April 1970 18:46:40 Number of seconds since epoch = 1, date = 3 March 1973 10:46:40 Number of seconds since epoch = 10, date = 9 September 2001 03:46:40 Number of seconds since epoch = 100, date = 7 September 2014 06:50:08 Number of seconds since epoch = 1000, date = 11 July 2008 06:56:32 Test script: --- "; } ?> -- Edit this bug report at http://bugs.php.net/bug.php?id=53221&edit=1
Bug #53153 [Opn]: Memory leak with phpinfo() + output buffering + zlib compression
Edit report at http://bugs.php.net/bug.php?id=53153&edit=1
ID: 53153
Updated by: cataphr...@php.net
Reported by:cataphr...@php.net
Summary:Memory leak with phpinfo() + output buffering + zlib
compression
Status: Open
Type: Bug
Package:Output Control
Operating System: Windows 7 x64
PHP Version:trunk-SVN-2010-10-25 (SVN)
Block user comment: N
New Comment:
Adding a line in output.c:810:
handler->buffer.data = erealloc(handler->buffer.data,
handler->buffer.size + grow_max);
fprintf(stderr, "%X: %d\n", handler->buffer.data,
php_output_get_level(TSRMLS_C));
handler->buffer.size += grow_max;
D55368: 3
D62748: 3
D70088: 2
D7C0C0: 2
[Mon Nov 01 21:58:47 2010] Script:
'zdö`â¼`â¼â¼Â¬Â½Ã�...@Ãâº'
c:\users\cataphract\documents\php-src\main\output.c(809) : Freeing
0x00D70088 (
49152 bytes), script=zdö`â¼`â¼â¼Â¬Â½Ã�...@Ãâº
At level 2 it's the zlib handler.
Previous Comments:
[2010-10-25 19:38:47] cataphr...@php.net
Note: there seems to be no leak if the environment variables
HTTP_ACCEPT_ENCODING actually triggers the zlib compression.
[2010-10-25 19:26:56] cataphr...@php.net
Interestingly there's also some corrupted/uninitialized memory in the
memory leak message:
[Mon Oct 25 18:19:39 2010] Script:
'z8ââ¥⥥?dâ�...@Ã
âº'
c:\users\cataphract\documents\php-src\main\output.c(809) : Freeing
0x012B0088 (
49152 bytes), script=z8ââ¥⥥?dâ�...@Ãâº
=== Total 1 memory leaks detected ===
[2010-10-25 19:25:44] cataphr...@php.net
Description:
There is a memory leak on memory allocated on \main\output.c(809):
if ((handler->buffer.size - handler->buffer.used) <= buf->used)
{
size_t grow_int =
PHP_OUTPUT_HANDLER_INITBUF_SIZE(handler->size);
size_t grow_buf =
PHP_OUTPUT_HANDLER_INITBUF_SIZE(buf->used -
(handler->buffer.size - handler->buffer.used));
size_t grow_max = MAX(grow_int, grow_buf);
handler->buffer.data = erealloc(handler->buffer.data,
handler->buffer.size + grow_max); /* memory was allocated here */
handler->buffer.size += grow_max;
}
phpinfo() code:
/* Andale! Andale! Yee-Hah! */
php_output_start_default(TSRMLS_C);
php_print_info(flag TSRMLS_CC);
php_output_end(TSRMLS_C);
Test script:
---
File file.php
---
http://bugs.php.net/bug.php?id=53153&edit=1
Bug #52784 [Asn->Csd]: Race condition when handling many concurrent signals
Edit report at http://bugs.php.net/bug.php?id=52784&edit=1 ID: 52784 Updated by: lbarn...@php.net Reported by:nick dot telford at gmail dot com Summary:Race condition when handling many concurrent signals -Status: Assigned +Status: Closed Type: Bug Package:PCNTL related Operating System: Linux 2.6+ PHP Version:5.3.3 Assigned To:lbarnaud Block user comment: N New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Thanks ! Previous Comments: [2010-11-01 23:44:01] lbarn...@php.net Automatic comment from SVN on behalf of lbarnaud Revision: http://svn.php.net/viewvc/?view=revision&revision=305020 Log: MFH fixed bug #52784 (Race condition when handling many concurrent signals) [2010-11-01 23:29:27] lbarn...@php.net Automatic comment from SVN on behalf of lbarnaud Revision: http://svn.php.net/viewvc/?view=revision&revision=305018 Log: fixed bug #52784 (Race condition when handling many concurrent signals) [2010-09-06 18:15:23] nick dot telford at gmail dot com It's been suggested that signal.h isn't portable and should be checked for in config.m4. Thing is, if this functionality is disabled, there exists a potentially crippling race condition. Given the small number of people who actually use this extension, I would recommend that signal.h/sigprocmask etc. should be a pre-requisite for activating custom signal handling. Without it, all userland signal handling should be disabled - thoughts? [2010-09-06 18:09:03] nick dot telford at gmail dot com Description: When a user-defined signal handler has been defined and many concurrent signals are being delivered to it through ext/pcntl, a race-condition can occur causing memory corruption. ext/pcntl handles signals to user-defined functions by placing incoming signals in to a "pending signals queue" (linked-list), which is then iterated when pcntl_signal_dispatch() is called (either explicitly, or via a tick). However, if another signal interrupts the execution of the signal handler whilst it is manipulating this linked list, it can become corrupted. The correct solution is to block signals from being delivered to the handler whilst it is handling a signal. This is achieved using sigprocmask(SIG_BLOCK). We have two patches, the first just cleans up the allocation of the pending signals queue. The second directly addresses the problem by wrapping any block of code that alters the pending signal queue with a set of syscalls to block the handling of any new signals. This is the safest approach as blocking the signals will cause the kernel to queue and deliver them once the handler has been unblocked. -- Edit this bug report at http://bugs.php.net/bug.php?id=52784&edit=1
Bug #53153 [Opn->Asn]: Memory leak with phpinfo() + output buffering + zlib compression
Edit report at http://bugs.php.net/bug.php?id=53153&edit=1
ID: 53153
Updated by: fel...@php.net
Reported by:cataphr...@php.net
Summary:Memory leak with phpinfo() + output buffering + zlib
compression
-Status: Open
+Status: Assigned
Type: Bug
Package:Output Control
Operating System: Windows 7 x64
PHP Version:trunk-SVN-2010-10-25 (SVN)
-Assigned To:
+Assigned To:mike
Block user comment: N
Previous Comments:
[2010-11-01 23:04:00] cataphr...@php.net
Adding a line in output.c:810:
handler->buffer.data = erealloc(handler->buffer.data,
handler->buffer.size + grow_max);
fprintf(stderr, "%X: %d\n", handler->buffer.data,
php_output_get_level(TSRMLS_C));
handler->buffer.size += grow_max;
D55368: 3
D62748: 3
D70088: 2
D7C0C0: 2
[Mon Nov 01 21:58:47 2010] Script:
'zdö`â¼`â¼â¼Â¬Â½Ã�...@Ãâº'
c:\users\cataphract\documents\php-src\main\output.c(809) : Freeing
0x00D70088 (
49152 bytes), script=zdö`â¼`â¼â¼Â¬Â½Ã�...@Ãâº
At level 2 it's the zlib handler.
[2010-10-25 19:38:47] cataphr...@php.net
Note: there seems to be no leak if the environment variables
HTTP_ACCEPT_ENCODING actually triggers the zlib compression.
[2010-10-25 19:26:56] cataphr...@php.net
Interestingly there's also some corrupted/uninitialized memory in the
memory leak message:
[Mon Oct 25 18:19:39 2010] Script:
'z8ââ¥⥥?dâ�...@Ã
âº'
c:\users\cataphract\documents\php-src\main\output.c(809) : Freeing
0x012B0088 (
49152 bytes), script=z8ââ¥⥥?dâ�...@Ãâº
=== Total 1 memory leaks detected ===
[2010-10-25 19:25:44] cataphr...@php.net
Description:
There is a memory leak on memory allocated on \main\output.c(809):
if ((handler->buffer.size - handler->buffer.used) <= buf->used)
{
size_t grow_int =
PHP_OUTPUT_HANDLER_INITBUF_SIZE(handler->size);
size_t grow_buf =
PHP_OUTPUT_HANDLER_INITBUF_SIZE(buf->used -
(handler->buffer.size - handler->buffer.used));
size_t grow_max = MAX(grow_int, grow_buf);
handler->buffer.data = erealloc(handler->buffer.data,
handler->buffer.size + grow_max); /* memory was allocated here */
handler->buffer.size += grow_max;
}
phpinfo() code:
/* Andale! Andale! Yee-Hah! */
php_output_start_default(TSRMLS_C);
php_print_info(flag TSRMLS_CC);
php_output_end(TSRMLS_C);
Test script:
---
File file.php
---
http://bugs.php.net/bug.php?id=53153&edit=1
Bug #53219 [Opn->Bgs]: Argentina's DST setting is wrong - DST should not be applied
Edit report at http://bugs.php.net/bug.php?id=53219&edit=1
ID: 53219
Updated by: cataphr...@php.net
Reported by:moranar at gmail dot com
Summary:Argentina's DST setting is wrong - DST should not be
applied
-Status: Open
+Status: Bogus
Type: Bug
Package:Date/time related
Operating System: Ubuntu Linux
PHP Version:Irrelevant
Block user comment: N
New Comment:
One can't expect PHP to have the timezone database up-to-date between
releases, much less when using such an old version.
The timezonedb pecl extensions exists precisely for this purpose.
Previous Comments:
[2010-11-01 21:46:31] moranar at gmail dot com
Description:
I'm trying to troubleshoot and solve this problem: the server I'm
working on (php 5.2.9 on Linux), has the correct local time
(America/Buenos_Aires):
u...@server [/home/site/public_html]$ date
Mon Nov 1 17:11:14 ART 2010
php.ini is set with date.timezone = "America/Buenos_Aires" I also tried
to set the timezone directly in the script with
";
echo "ini: ", ini_get('date.timezone'), "";
$now = date("H:i:s T I");
$nowdate = date("Y-m-d");
echo $nowdate." ".$now;
?>
but to no avail, the result is
ini: America/Buenos_Aires
2010-11-01 18:11:14 ARST 1
when it should read 17:11 (It's consistently one hour ahead).
I checked and as you can see in the code, PHP thinks it should be
applying DST, and Argentina decided to not apply it this year.
I tried dumping the timezones transition as suggested. I got the
following:
The timezone America/Buenos_Aires switches to standard time on 20 Mar
2011 @ 02:00.
The new GMT offset will be: -10800 (ART)
--
Edit this bug report at http://bugs.php.net/bug.php?id=53219&edit=1
Bug #51986 [Ana->Csd]: array_filter breaks references when a callback is used
Edit report at http://bugs.php.net/bug.php?id=51986&edit=1
ID: 51986
Updated by: fel...@php.net
Reported by:daniel dot menard at ehesp dot fr
Summary:array_filter breaks references when a callback is
used
-Status: Analyzed
+Status: Closed
Type: Bug
Package:Arrays related
Operating System: Windows XP
PHP Version:5.3.2
Assigned To:dmitry
Block user comment: N
Previous Comments:
[2010-09-29 23:12:16] cataphr...@php.net
The following patch has been added/updated:
Patch Name: bug_51986_5_3
Revision: 1285794735
URL:
http://bugs.php.net/patch-display.php?bug=51986&patch=bug_51986_5_3&revision=1285794735
[2010-09-29 23:11:41] cataphr...@php.net
Sorry, it doesn't work on trunk, it works on my patched trunk :p
Fixing bug #52940 would fix this. However, the patch for that bug has
one effect that changes the current behavior of call_user_func_array
(removes check for internal function) and another change when the
refcount of the zval is <= 1 and it's a reference (a rare case).
Attached a patch that changes as little as possible, yet fixes this bug.
[2010-09-29 13:05:51] cataphr...@php.net
Reproducible on PHP 5.3, but not on trunk.
[2010-06-03 14:29:38] daniel dot menard at ehesp dot fr
Thanks for your comment: your workaround works.
However, having to redefine standard php functions like trim() or
count() just to be able to use them with array_filter() is not very
convenient, is it?
The fact is that the function behaviour changed in a "revision release"
which should not have broken my code...
;-)
[2010-06-03 13:00:43] sjo...@php.net
Use a reference in your callback function:
function my_trim(& $a)
{
return trim($a);
}
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/bug.php?id=51986
--
Edit this bug report at http://bugs.php.net/bug.php?id=51986&edit=1
[PHP-BUG] Bug #53222 [NEW]: "less than" operator returning true even if numbers are equal
From:
Operating system: fedora 13
PHP version: 5.3.3
Package: Scripting Engine problem
Bug Type: Bug
Bug description:"less than" operator returning true even if numbers are equal
Description:
I am using the following PHP version:
PHP 5.3.3 (cli) (built: Jul 22 2010 15:57:00)
Info: re-typing everything to (float), (double) or "no type specified" does
not fix the problem.
Test script:
---
0)
{
$i=$min;
while($i<$max)
{
echo($i." < $max ");
var_dump($i,$max,$step);
echo("");
$i+=$step;
}
}
if($i>$max) echo("WHAT?"); ?>
Expected result:
44 < 54545 float(44) float(54545) float(5450.1)
5494.1 < 54545 float(5494.1) float(54545) float(5450.1)
10944.2 < 54545 float(10944.2) float(54545) float(5450.1)
16394.3 < 54545 float(16394.3) float(54545) float(5450.1)
21844.4 < 54545 float(21844.4) float(54545) float(5450.1)
27294.5 < 54545 float(27294.5) float(54545) float(5450.1)
32744.6 < 54545 float(32744.6) float(54545) float(5450.1)
38194.7 < 54545 float(38194.7) float(54545) float(5450.1)
43644.8 < 54545 float(43644.8) float(54545) float(5450.1)
49094.9 < 54545 float(49094.9) float(54545) float(5450.1)
Actual result:
--
44 < 54545 float(44) float(54545) float(5450.1)
5494.1 < 54545 float(5494.1) float(54545) float(5450.1)
10944.2 < 54545 float(10944.2) float(54545) float(5450.1)
16394.3 < 54545 float(16394.3) float(54545) float(5450.1)
21844.4 < 54545 float(21844.4) float(54545) float(5450.1)
27294.5 < 54545 float(27294.5) float(54545) float(5450.1)
32744.6 < 54545 float(32744.6) float(54545) float(5450.1)
38194.7 < 54545 float(38194.7) float(54545) float(5450.1)
43644.8 < 54545 float(43644.8) float(54545) float(5450.1)
49094.9 < 54545 float(49094.9) float(54545) float(5450.1)
54545 < 54545 float(54545) float(54545) float(5450.1)
WHAT?
--
Edit bug report at http://bugs.php.net/bug.php?id=53222&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53222&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53222&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53222&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53222&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53222&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53222&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53222&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53222&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53222&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53222&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53222&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53222&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53222&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53222&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53222&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53222&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53222&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53222&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53222&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53222&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53222&r=mysqlcfg
Bug #53222 [Opn->Csd]: "less than" operator returning true even if numbers are equal
Edit report at http://bugs.php.net/bug.php?id=53222&edit=1
ID: 53222
User updated by:viliam dot kubis at gmail dot com
Reported by:viliam dot kubis at gmail dot com
Summary:"less than" operator returning true even if numbers
are equal
-Status: Open
+Status: Closed
Type: Bug
Package:Scripting Engine problem
Operating System: fedora 13
PHP Version:5.3.3
Block user comment: N
New Comment:
I'm sorry, my mistake. Did not read carefully about floats in the
manual. Sure you can't safely compare them for equality, but that also
means you can't safely compare them with "<" and ">" operators. The code
works when using BCMath. Thanks.
Previous Comments:
[2010-11-02 02:06:04] viliam dot kubis at gmail dot com
Description:
I am using the following PHP version:
PHP 5.3.3 (cli) (built: Jul 22 2010 15:57:00)
Info: re-typing everything to (float), (double) or "no type specified"
does not fix the problem.
Test script:
---
0)
{
$i=$min;
while($i<$max)
{
echo($i." < $max ");
var_dump($i,$max,$step);
echo("");
$i+=$step;
}
}
if($i>$max) echo("WHAT?"); ?>
Expected result:
44 < 54545 float(44) float(54545) float(5450.1)
5494.1 < 54545 float(5494.1) float(54545) float(5450.1)
10944.2 < 54545 float(10944.2) float(54545) float(5450.1)
16394.3 < 54545 float(16394.3) float(54545) float(5450.1)
21844.4 < 54545 float(21844.4) float(54545) float(5450.1)
27294.5 < 54545 float(27294.5) float(54545) float(5450.1)
32744.6 < 54545 float(32744.6) float(54545) float(5450.1)
38194.7 < 54545 float(38194.7) float(54545) float(5450.1)
43644.8 < 54545 float(43644.8) float(54545) float(5450.1)
49094.9 < 54545 float(49094.9) float(54545) float(5450.1)
Actual result:
--
44 < 54545 float(44) float(54545) float(5450.1)
5494.1 < 54545 float(5494.1) float(54545) float(5450.1)
10944.2 < 54545 float(10944.2) float(54545) float(5450.1)
16394.3 < 54545 float(16394.3) float(54545) float(5450.1)
21844.4 < 54545 float(21844.4) float(54545) float(5450.1)
27294.5 < 54545 float(27294.5) float(54545) float(5450.1)
32744.6 < 54545 float(32744.6) float(54545) float(5450.1)
38194.7 < 54545 float(38194.7) float(54545) float(5450.1)
43644.8 < 54545 float(43644.8) float(54545) float(5450.1)
49094.9 < 54545 float(49094.9) float(54545) float(5450.1)
54545 < 54545 float(54545) float(54545) float(5450.1)
WHAT?
--
Edit this bug report at http://bugs.php.net/bug.php?id=53222&edit=1
Bug #53222 [Csd->Bgs]: "less than" operator returning true even if numbers are equal
Edit report at http://bugs.php.net/bug.php?id=53222&edit=1
ID: 53222
Updated by: paj...@php.net
Reported by:viliam dot kubis at gmail dot com
Summary:"less than" operator returning true even if numbers
are equal
-Status: Closed
+Status: Bogus
Type: Bug
Package:Scripting Engine problem
Operating System: fedora 13
PHP Version:5.3.3
Block user comment: N
Previous Comments:
[2010-11-02 02:24:59] viliam dot kubis at gmail dot com
I'm sorry, my mistake. Did not read carefully about floats in the
manual. Sure you can't safely compare them for equality, but that also
means you can't safely compare them with "<" and ">" operators. The code
works when using BCMath. Thanks.
[2010-11-02 02:06:04] viliam dot kubis at gmail dot com
Description:
I am using the following PHP version:
PHP 5.3.3 (cli) (built: Jul 22 2010 15:57:00)
Info: re-typing everything to (float), (double) or "no type specified"
does not fix the problem.
Test script:
---
0)
{
$i=$min;
while($i<$max)
{
echo($i." < $max ");
var_dump($i,$max,$step);
echo("");
$i+=$step;
}
}
if($i>$max) echo("WHAT?"); ?>
Expected result:
44 < 54545 float(44) float(54545) float(5450.1)
5494.1 < 54545 float(5494.1) float(54545) float(5450.1)
10944.2 < 54545 float(10944.2) float(54545) float(5450.1)
16394.3 < 54545 float(16394.3) float(54545) float(5450.1)
21844.4 < 54545 float(21844.4) float(54545) float(5450.1)
27294.5 < 54545 float(27294.5) float(54545) float(5450.1)
32744.6 < 54545 float(32744.6) float(54545) float(5450.1)
38194.7 < 54545 float(38194.7) float(54545) float(5450.1)
43644.8 < 54545 float(43644.8) float(54545) float(5450.1)
49094.9 < 54545 float(49094.9) float(54545) float(5450.1)
Actual result:
--
44 < 54545 float(44) float(54545) float(5450.1)
5494.1 < 54545 float(5494.1) float(54545) float(5450.1)
10944.2 < 54545 float(10944.2) float(54545) float(5450.1)
16394.3 < 54545 float(16394.3) float(54545) float(5450.1)
21844.4 < 54545 float(21844.4) float(54545) float(5450.1)
27294.5 < 54545 float(27294.5) float(54545) float(5450.1)
32744.6 < 54545 float(32744.6) float(54545) float(5450.1)
38194.7 < 54545 float(38194.7) float(54545) float(5450.1)
43644.8 < 54545 float(43644.8) float(54545) float(5450.1)
49094.9 < 54545 float(49094.9) float(54545) float(5450.1)
54545 < 54545 float(54545) float(54545) float(5450.1)
WHAT?
--
Edit this bug report at http://bugs.php.net/bug.php?id=53222&edit=1
Bug #53204 [Opn->Bgs]: IF Statement Long String
Edit report at http://bugs.php.net/bug.php?id=53204&edit=1
ID: 53204
Updated by: ahar...@php.net
Reported by:diemuzi at gmail dot com
Summary:IF Statement Long String
-Status: Open
+Status: Bogus
Type: Bug
Package:Unknown/Other Function
Operating System: Archlinux
PHP Version:5.3.3
Block user comment: N
New Comment:
As comment #1 indicates, this is due to the fact that you're actually
dealing with floating point values, not integers.
Not a bug -> closing.
Previous Comments:
[2010-10-30 23:04:52] phristen at yahoo dot com
PHP integers are 32 bit.
The actual value of $o is not what you think it is... Do this:
var_dump($o);
[2010-10-29 22:50:14] diemuzi at gmail dot com
Description:
I was testing long strings of numbers against an IF statement (see test)
script and it was outputting information which was not true.
Test script:
---
This works:
$o = 33;
if ($o >= 29 && $o <= 32)
{
echo "true";
} else {
echo "false";
}
This does not work:
$o = 336571324099282374385465584513479344133;
if ($o >= 336571324099282374385465584513479344129 && $o <=
336571324099282374385465584513479344132)
{
echo "true";
} else {
echo "false";
}
Expected result:
In the working example, the output should be false. This is working as
expected.
In the non-working example, the output should be false. However, it is
returning true.
--
Edit this bug report at http://bugs.php.net/bug.php?id=53204&edit=1
Req #53205 [Opn->Wfx]: Make $php_errormsg global
Edit report at http://bugs.php.net/bug.php?id=53205&edit=1 ID: 53205 Updated by: ahar...@php.net Reported by:info at fedushin dot ru Summary:Make $php_errormsg global -Status: Open +Status: Wont fix Type: Feature/Change Request Package:*General Issues PHP Version:5.3.3 Block user comment: N New Comment: Given that $php_errormsg and track_errors are leftovers from PHP 3, I don't think there's much likelihood of them receiving any changes at this point. (Honestly, I'd rather just see them removed.) At any rate, you can emulate this easily enough in a PHP script by setting a global variable within a custom error handler. No need for another configuration option or a global variable to clutter up the global namespace. Closing won't fix. Previous Comments: [2010-10-30 13:37:36] info at fedushin dot ru Description: $php_errormsg would be much more useful for developers if it were available in global scope. F.e. its value might be displayed in user-defined assert handler set by assert_options(ASSERT_CALLBACK,..). Suggestion is to add boolean variable "track_errors_global" to php.ini. If it's "On" $php_errormsg should be available in global scope (or maybe even be "super-global"). -- Edit this bug report at http://bugs.php.net/bug.php?id=53205&edit=1
Req #53213 [Fbk->Opn]: Adler32 algorithm is very slow
Edit report at http://bugs.php.net/bug.php?id=53213&edit=1
ID: 53213
Updated by: ahar...@php.net
Reported by:zavasek at yandex dot ru
Summary:Adler32 algorithm is very slow
-Status: Feedback
+Status: Open
Type: Feature/Change Request
Package:hash related
Operating System: Any
PHP Version:5.3.3
Block user comment: N
Previous Comments:
[2010-10-31 20:45:28] paj...@php.net
svn diff > mypatch.txt
and upload mypatch.txt here using the Add Patch link.
[2010-10-31 20:40:47] zavasek at yandex dot ru
I've never used SVN and do not know how to create patches.
[2010-10-31 19:14:48] paj...@php.net
Can you provide a patch and attach it to this bug please ("Add a
patch")?
[2010-10-31 18:22:17] zavasek at yandex dot ru
Description:
Now adler32 algorithm for each byte uses two operations " % 65521". It
is very slow.
I propose to change the function PHP_ADLER32Update in the file
hash_adler32.c
{
php_hash_uint32 i, s[2];
s[0] = context->state & 0x;
s[1] = (context->state >> 16) & 0x;
for (i = 0; i < len; ++i) {
s[0] += input[i];
s[1] += s[0];
if (s[1]>0x7fff)
{
s[0] = s[0] % 65521;
s[1] = s[1] % 65521;
}
}
s[0] = s[0] % 65521;
s[1] = s[1] % 65521;
context->state = s[0] + (s[1] << 16);
}
Test script:
---
Actual result:
--
PHP 5.3.3 showed:
85ffb2c5
2174 ms
After modification the file:
85ffb2c5
664 ms
Speed was higher than about 3 times
--
Edit this bug report at http://bugs.php.net/bug.php?id=53213&edit=1
Bug #53153 [Asn->Csd]: Memory leak with phpinfo() + output buffering + zlib compression
Edit report at http://bugs.php.net/bug.php?id=53153&edit=1
ID: 53153
Updated by: cataphr...@php.net
Reported by:cataphr...@php.net
Summary:Memory leak with phpinfo() + output buffering + zlib
compression
-Status: Assigned
+Status: Closed
Type: Bug
Package:Output Control
Operating System: Windows 7 x64
PHP Version:trunk-SVN-2010-10-25 (SVN)
-Assigned To:mike
+Assigned To:cataphract
Block user comment: N
Previous Comments:
[2010-11-02 04:49:50] cataphr...@php.net
Automatic comment from SVN on behalf of cataphract
Revision: http://svn.php.net/viewvc/?view=revision&revision=305022
Log: - Fixed bug #53153 (memory leak with phpinfo() + output buffering +
zlib compression).
[2010-11-01 23:04:00] cataphr...@php.net
Adding a line in output.c:810:
handler->buffer.data = erealloc(handler->buffer.data,
handler->buffer.size + grow_max);
fprintf(stderr, "%X: %d\n", handler->buffer.data,
php_output_get_level(TSRMLS_C));
handler->buffer.size += grow_max;
D55368: 3
D62748: 3
D70088: 2
D7C0C0: 2
[Mon Nov 01 21:58:47 2010] Script:
'zdö`â¼`â¼â¼Â¬Â½Ã�...@Ãâº'
c:\users\cataphract\documents\php-src\main\output.c(809) : Freeing
0x00D70088 (
49152 bytes), script=zdö`â¼`â¼â¼Â¬Â½Ã�...@Ãâº
At level 2 it's the zlib handler.
[2010-10-25 19:38:47] cataphr...@php.net
Note: there seems to be no leak if the environment variables
HTTP_ACCEPT_ENCODING actually triggers the zlib compression.
[2010-10-25 19:26:56] cataphr...@php.net
Interestingly there's also some corrupted/uninitialized memory in the
memory leak message:
[Mon Oct 25 18:19:39 2010] Script:
'z8ââ¥⥥?dâ�...@Ã
âº'
c:\users\cataphract\documents\php-src\main\output.c(809) : Freeing
0x012B0088 (
49152 bytes), script=z8ââ¥⥥?dâ�...@Ãâº
=== Total 1 memory leaks detected ===
[2010-10-25 19:25:44] cataphr...@php.net
Description:
There is a memory leak on memory allocated on \main\output.c(809):
if ((handler->buffer.size - handler->buffer.used) <= buf->used)
{
size_t grow_int =
PHP_OUTPUT_HANDLER_INITBUF_SIZE(handler->size);
size_t grow_buf =
PHP_OUTPUT_HANDLER_INITBUF_SIZE(buf->used -
(handler->buffer.size - handler->buffer.used));
size_t grow_max = MAX(grow_int, grow_buf);
handler->buffer.data = erealloc(handler->buffer.data,
handler->buffer.size + grow_max); /* memory was allocated here */
handler->buffer.size += grow_max;
}
phpinfo() code:
/* Andale! Andale! Yee-Hah! */
php_output_start_default(TSRMLS_C);
php_print_info(flag TSRMLS_CC);
php_output_end(TSRMLS_C);
Test script:
---
File file.php
---
http://bugs.php.net/bug.php?id=53153&edit=1
