#46534 [Com]: Incorrect usage of SI-prefixes by PHP
ID: 46534 Comment by: kriceslo at gmail dot com Reported By: alexanderpas at yahoo dot co dot uk Status: Open Bug Type: Feature/Change Request Operating System: * PHP Version: 5.3.0alpha2 New Comment: This needs to be addressed. We, in the IT field, need to start using the correct units--now standardized and accepted BY LAW in some countries. Great job alexanderpas! Previous Comments: [2008-11-10 14:00:16] alexanderpas at yahoo dot co dot uk proper table... decimal value binary valuedifference 1000^1 = 10^3 1024^1 = 2^10 2.4% 1000^2 = 10^6 1024^2 = 2^20 4.9% 1000^3 = 10^9 1024^3 = 2^30 7.4% 1000^4 = 10^12 1024^4 = 2^40 10.0% 1000^5 = 10^15 1024^5 = 2^50 12.6% 1000^6 = 10^18 1024^6 = 2^60 15.3% 1000^7 = 10^21 1024^7 = 2^70 18.1% 1000^8 = 10^24 1024^8 = 2^80 20.9% [2008-11-10 11:12:13] alexanderpas at yahoo dot co dot uk Description: PHP is handling kilo and other SI prefixes as multiples of 1024. The SI prefixes should only be used in the decimal sense: kilobyte and megabyte denote one thousand bytes and one million bytes respectively, while kibibyte and mebibyte denote 1024 bytes and 1,048,576 bytes respectively. This recommendation has been adopted by SI, IEEE, CIPM, NIST, ISO/IEC and some other leading national and international standards, which now state that the prefixes k, M and G should always refer to powers of ten, even in the context of information technology. (reference: ISO/IEC IEC 8-13:2008 ) reduced timeline: 1998: IEC introduces unambigous prefixes for binary multiples (KiB, MiB, GiB etc.), reserving kB, MB, GB and so on for their decimal sense. 2005: IEC prefixes are adopted by the IEEE after a two-year trial period. 2008: NIST guidelines require use of IEC prefixes KiB, MiB ... (and not kB, MB) for binary byte multiples The names and symbols for the prefixes corresponding to 2 10 , 2 20 , 2 30 , 2 40 , 2 50 , and 2 60 are, respectively: kibi, Ki; mebi, Mi; gibi, Gi; tebi, Ti; pebi, Pi; and exbi, Ei. Thus, for example, one kibibyte would be written: 1 KiB = 2 10 B = 1024 B, where B denotes a byte. Although these prefixes are not part of the SI, they should be used in the field of information technology to avoid the incorrect usage of the SI prefixes. also remember this: decimal value binary valuedifference 10001 = 103 10241 = 210 2.4% 10002 = 106 10242 = 220 4.9% 10003 = 109 10243 = 230 7.4% 10004 = 101210244 = 240 10.0% 10005 = 101510245 = 250 12.6% 10006 = 101810246 = 260 15.3% 10007 = 102110247 = 270 18.1% 10008 = 102410248 = 280 20.9% also, this has a usability impact, since using the same wording with two different meanings is JUST PLAIN WRONG, and should end RIGHT NOW, Regular users don't know that the units have dual meanings, and we shouldn't continue confusing them in this way. also "man 7 units" on your linux-box ;) (please put in correct category!) Reproduce code: --- http://bugs.php.net/?id=46534&edit=1
#48063 [Bgs]: Spontaneously disappearing, cookie-based sessions
ID: 48063
User updated by: myselfasunder at gmail dot com
Reported By: myselfasunder at gmail dot com
Status: Bogus
Bug Type: Session related
Operating System: Ubuntu
PHP Version: 5.2.9
New Comment:
This is just a project, at work, that I've been working on, and this is
just all from the perspective of my local system... so, it's very
unlikely that any other sessionized web-apps are running without me
being able to think of them.
I don't exactly know the format of the session file, but since it deals
with serialized information and a predictable data-size, you can
presumably put the lifetime information at the end of the file without
interfering with backward compatibility..?
Previous Comments:
[2009-04-23 21:59:15] scott...@php.net
It's not that smart, it just looks through the session directory and
kills anything that looks like a session file based on the last time the
file was read and the currently lifetime value.
If there are zero other scripts on the system then it should be fine,
but I suspect there is one somewhere you are missing. Can you add this
to the php.ini file and see if you can reproduce it?
We could look to adding the session lifetime to the file but that would
break backwards compatibility and you could accidentally set a session
to 10 years from now and it would never get removed.
[2009-04-23 21:24:24] myselfasunder at gmail dot com
Even if this is the only script that executes on the system (a
front-controller in the only application)?
How about the fact that my session-name is 'COOKIE' in this
test-script... Wouldn't only everything that uses a session-name of
COOKIE interfere with each other, in this case?
[2009-04-23 21:02:23] scott...@php.net
You need to set it in the php.ini, if any other script uses sessions
and doesn't set it to be the same value it will delete the sessions.
[2009-04-23 19:06:20] myselfasunder at gmail dot com
");
else
print("Session DOES NOT exist.");
$_SESSION['aa'] = true;
[2009-04-23 17:33:38] j...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
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/48063
--
Edit this bug report at http://bugs.php.net/?id=48063&edit=1
#48065 [Com]: mysqli can not have two called procedure queries active at once
ID: 48065 Comment by: schwern at pobox dot com Reported By: schwern at pobox dot com Status: Open Bug Type: MySQLi related Operating System: OS X PHP Version: 5.2CVS-2009-04-23 (snap) New Comment: For reference, here's the MySQL 5.0 docs on "Commands out of sync". http://dev.mysql.com/doc/refman/5.0/en/commands-out-of-sync.html Previous Comments: [2009-04-23 23:10:26] schwern at pobox dot com Description: mysqli does not like having two query results active at the same time if a stored procedure was queried. MySQL balks with "Commands out of sync; you can't run this command now". The equivalent SELECT does not have this problem, nor does Perl's DBD::mysql for comparison. Work arounds appear to be explicitly free'ing the result before calling the next one, but that is not easily possible through the Drupal DB API, for example. Also I might want to return a query result from a function and have it live on out of my function's control. And its a general violation of OO to have the two result objects interfere with each other. Reproduce code: --- http://rafb.net/p/XnP3AN31.html (Writes to the test database and user) The script creates a table with a few rows and a stored procedure doing a "select *" on that table. It then illustrates that two concurrent calls to that procedure cause an error while two "SELECT *" queries do not. Replicated on OS X with their stock PHP 5.2.6 and a fresh php5.2-200904232230 snapshot with --with-mysqli. Using a local mysql server compiled from MacPorts. mysql Ver 14.12 Distrib 5.0.77, for apple-darwin9.6.0 (i386) using readline 6.0 Expected result: Doing call get_stuff Done Doing select * from stuff Done Actual result: -- Doing call get_stuff Second query FAILED: Commands out of sync; you can't run this command now Done Doing select * from stuff Done -- Edit this bug report at http://bugs.php.net/?id=48065&edit=1
#48065 [NEW]: mysqli can not have two called procedure queries active at once
From: schwern at pobox dot com Operating system: OS X PHP version: 5.2CVS-2009-04-23 (snap) PHP Bug Type: MySQLi related Bug description: mysqli can not have two called procedure queries active at once Description: mysqli does not like having two query results active at the same time if a stored procedure was queried. MySQL balks with "Commands out of sync; you can't run this command now". The equivalent SELECT does not have this problem, nor does Perl's DBD::mysql for comparison. Work arounds appear to be explicitly free'ing the result before calling the next one, but that is not easily possible through the Drupal DB API, for example. Also I might want to return a query result from a function and have it live on out of my function's control. And its a general violation of OO to have the two result objects interfere with each other. Reproduce code: --- http://rafb.net/p/XnP3AN31.html (Writes to the test database and user) The script creates a table with a few rows and a stored procedure doing a "select *" on that table. It then illustrates that two concurrent calls to that procedure cause an error while two "SELECT *" queries do not. Replicated on OS X with their stock PHP 5.2.6 and a fresh php5.2-200904232230 snapshot with --with-mysqli. Using a local mysql server compiled from MacPorts. mysql Ver 14.12 Distrib 5.0.77, for apple-darwin9.6.0 (i386) using readline 6.0 Expected result: Doing call get_stuff Done Doing select * from stuff Done Actual result: -- Doing call get_stuff Second query FAILED: Commands out of sync; you can't run this command now Done Doing select * from stuff Done -- Edit bug report at http://bugs.php.net/?id=48065&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48065&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48065&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48065&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48065&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48065&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48065&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48065&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48065&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48065&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48065&r=support Expected behavior: http://bugs.php.net/fix.php?id=48065&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48065&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48065&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48065&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48065&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48065&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48065&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48065&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48065&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48065&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48065&r=mysqlcfg
#47940 [Opn->Csd]: imap_body() leaks memory
ID: 47940
Updated by: paj...@php.net
Reported By: jake dot levitt at mailtrust dot com
-Status: Open
+Status: Closed
Bug Type: IMAP related
Operating System: Ubuntu 8.04 (linux:2.6.24-21)
PHP Version: 5.2.9
New Comment:
Slightly modified version committed in all branches. Thanks for your
work!
Previous Comments:
[2009-04-23 21:37:27] jake dot levitt at mailtrust dot com
Here's a unified diff:
diff -u php-5.2.9/ext/imap/php_imap.c
php-5.2.9-fixed/ext/imap/php_imap.c
--- php-5.2.9/ext/imap/php_imap.c2008-12-31 06:17:38.0
-0500
+++ php-5.2.9-fixed/ext/imap/php_imap.c2009-04-23
13:56:26.0 -0400
@@ -1250,7 +1250,10 @@
RETURN_FALSE;
}
-RETVAL_STRING(mail_fetchtext_full
(imap_le_struct->imap_stream, Z_LVAL_PP(msgno), NIL, myargc==3 ?
Z_LVAL_PP(pflags) : NIL), 1);
+char *body = mail_fetchtext_full (imap_le_struct->imap_stream,
Z_LVAL_PP(msgno), NIL, myargc==3 ? Z_LVAL_PP(pflags) : NIL);
+
+RETVAL_STRING(body, 1);
+free(body);
}
/* }}} */
[2009-04-23 21:03:39] scott...@php.net
Can you provide the patch as a unified diff, just use the -u flag to
cvs diff.
[2009-04-23 19:05:24] jake dot levitt at mailtrust dot com
A co-worker and I have created a diff that seems to fix this issue.
Would someone else mind checking it out and seeing if there are any
problems with it?
diff php_imap.c php_imap_fixed.c
1251a1252
> char *body = mail_fetchtext_full (imap_le_struct->imap_stream,
Z_LVAL_PP(msgno), NIL, myargc==3 ? Z_LVAL_PP(pflags) : NIL);
1253c1254,1255
< RETVAL_STRING(mail_fetchtext_full (imap_le_struct->imap_stream,
Z_LVAL_PP(msgno), NIL, myargc==3 ? Z_LVAL_PP(pflags) : NIL), 1);
---
> RETVAL_STRING(body, 1);
> free(body);
[2009-04-14 18:41:36] jake dot levitt at mailtrust dot com
I tried closing and freeing the imap connection every 100 calls to
imap_body() to see if it was the resource that was holding on to the
memory. This did not help.
Code:
if ($i % 100 === 0) {
echo "Releasing mailbox\n";
imap_close($mailbox);
$mailbox = null;
unset($mailbox);
$mailbox = @imap_open($connect_string, $username, $password, 0,
3);
$reopen_success = imap_reopen($mailbox, $connect_string, 0, 3);
}
[2009-04-14 15:43:56] jake dot levitt at mailtrust dot com
I have now confirmed that this bug also exists in PHP version 5.3.0RC1
on CentOs 5.1.
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/47940
--
Edit this bug report at http://bugs.php.net/?id=47940&edit=1
#48056 [Bgs]: require works differently in the interactive console
ID: 48056
User updated by: neerolyte at gmail dot com
Reported By: neerolyte at gmail dot com
Status: Bogus
Bug Type: *General Issues
Operating System: Linux
PHP Version: 5.2.9
New Comment:
I can't see anything in the manual that even mentions the interactive
console and it states that require is identical to include except for
it's error reporting and include should return anything passed to return
inside the included file.
As for the PHP Bugs guide I can't see what I've done wrong there
either.
Would anyone mind giving me more of a clue?
Previous Comments:
[2009-04-23 16:12:05] j...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
[2009-04-23 06:45:34] neerolyte at gmail dot com
Description:
Normally any return statements in a file included via require keyword
will cause the require call to return what ever was passed to the return
statement with in the included file.
Reproduce code:
---
include.php:
interactive code:
print_r(require("include.php"));
Expected result:
$ echo '' > include.php
$ php -r 'print_r(require("include.php"));'
stuff from include
$ php -a
Interactive shell
php > print_r(require("include.php"));
stuff from include
Actual result:
--
$ echo '' > include.php
$ php -r 'print_r(require("include.php"));'
stuff from include
$ php -a
Interactive shell
php > print_r(require("include.php"));
1
--
Edit this bug report at http://bugs.php.net/?id=48056&edit=1
#48063 [Bgs]: Spontaneously disappearing, cookie-based sessions
ID: 48063
Updated by: scott...@php.net
Reported By: myselfasunder at gmail dot com
Status: Bogus
Bug Type: Session related
Operating System: Ubuntu
PHP Version: 5.2.9
New Comment:
It's not that smart, it just looks through the session directory and
kills anything that looks like a session file based on the last time the
file was read and the currently lifetime value.
If there are zero other scripts on the system then it should be fine,
but I suspect there is one somewhere you are missing. Can you add this
to the php.ini file and see if you can reproduce it?
We could look to adding the session lifetime to the file but that would
break backwards compatibility and you could accidentally set a session
to 10 years from now and it would never get removed.
Previous Comments:
[2009-04-23 21:24:24] myselfasunder at gmail dot com
Even if this is the only script that executes on the system (a
front-controller in the only application)?
How about the fact that my session-name is 'COOKIE' in this
test-script... Wouldn't only everything that uses a session-name of
COOKIE interfere with each other, in this case?
[2009-04-23 21:02:23] scott...@php.net
You need to set it in the php.ini, if any other script uses sessions
and doesn't set it to be the same value it will delete the sessions.
[2009-04-23 19:06:20] myselfasunder at gmail dot com
");
else
print("Session DOES NOT exist.");
$_SESSION['aa'] = true;
[2009-04-23 17:33:38] j...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
[2009-04-23 16:51:26] myselfasunder at gmail dot com
Description:
I have set the following:
session_name('GOLDENCOLLECTION');
session_set_cookie_params(86400 * 3);
ini_set('session.use_only_cookies', '1');
ini_set('session.gc_maxlifetime', 86400 * 3);
I can load the same page many times successfully. However, if I wait a
while, around twenty minutes, the session's members are no longer
available.
This is the first time I've used cookies to carry the SID (instead of
putting them in the URL).
I have administrative control of the system.
Reproduce code:
---
session_start();
Expected result:
The session should be started and all preexisting members should be
available. They -does- happen, but until only around twenty or thirty
minutes have elapsed, and then they'll be gone.
Actual result:
--
They'll disappear without me doing anything.
--
Edit this bug report at http://bugs.php.net/?id=48063&edit=1
#47940 [Opn]: imap_body() leaks memory
ID: 47940
User updated by: jake dot levitt at mailtrust dot com
Reported By: jake dot levitt at mailtrust dot com
Status: Open
Bug Type: IMAP related
Operating System: Ubuntu 8.04 (linux:2.6.24-21)
PHP Version: 5.2.9
New Comment:
Here's a unified diff:
diff -u php-5.2.9/ext/imap/php_imap.c
php-5.2.9-fixed/ext/imap/php_imap.c
--- php-5.2.9/ext/imap/php_imap.c2008-12-31 06:17:38.0
-0500
+++ php-5.2.9-fixed/ext/imap/php_imap.c2009-04-23
13:56:26.0 -0400
@@ -1250,7 +1250,10 @@
RETURN_FALSE;
}
-RETVAL_STRING(mail_fetchtext_full
(imap_le_struct->imap_stream, Z_LVAL_PP(msgno), NIL, myargc==3 ?
Z_LVAL_PP(pflags) : NIL), 1);
+char *body = mail_fetchtext_full (imap_le_struct->imap_stream,
Z_LVAL_PP(msgno), NIL, myargc==3 ? Z_LVAL_PP(pflags) : NIL);
+
+RETVAL_STRING(body, 1);
+free(body);
}
/* }}} */
Previous Comments:
[2009-04-23 21:03:39] scott...@php.net
Can you provide the patch as a unified diff, just use the -u flag to
cvs diff.
[2009-04-23 19:05:24] jake dot levitt at mailtrust dot com
A co-worker and I have created a diff that seems to fix this issue.
Would someone else mind checking it out and seeing if there are any
problems with it?
diff php_imap.c php_imap_fixed.c
1251a1252
> char *body = mail_fetchtext_full (imap_le_struct->imap_stream,
Z_LVAL_PP(msgno), NIL, myargc==3 ? Z_LVAL_PP(pflags) : NIL);
1253c1254,1255
< RETVAL_STRING(mail_fetchtext_full (imap_le_struct->imap_stream,
Z_LVAL_PP(msgno), NIL, myargc==3 ? Z_LVAL_PP(pflags) : NIL), 1);
---
> RETVAL_STRING(body, 1);
> free(body);
[2009-04-14 18:41:36] jake dot levitt at mailtrust dot com
I tried closing and freeing the imap connection every 100 calls to
imap_body() to see if it was the resource that was holding on to the
memory. This did not help.
Code:
if ($i % 100 === 0) {
echo "Releasing mailbox\n";
imap_close($mailbox);
$mailbox = null;
unset($mailbox);
$mailbox = @imap_open($connect_string, $username, $password, 0,
3);
$reopen_success = imap_reopen($mailbox, $connect_string, 0, 3);
}
[2009-04-14 15:43:56] jake dot levitt at mailtrust dot com
I have now confirmed that this bug also exists in PHP version 5.3.0RC1
on CentOs 5.1.
[2009-04-09 22:31:04] jake dot levitt at mailtrust dot com
Description:
I am creating a script that migrates e-mail from one server to another.
On really large mailboxes, my script dies with "PHP Fatal error: Out
of memory (allocated 13631488) (tried to allocate 3381512 bytes)" even
though memory_get_usage() function was reporting that the script was
only using around 10 MBs. My memory_limit is set to 1GB (but this isn't
coming into play). When I examined the memory usage of the script using
ps, I noticed that it would gradually increase until it reached ~92% of
system memory (I have 2GB). I eventually found that when I commented
out imap_body, the memory usage would stay flat. I wrote a script that
can reproduce this bug. I run the script in the background and then
watch its memory using: ps -eo pid,ppid,rss,vsize,pcpu,pmem,cmd -ww
--sort=pid | grep "\(memory-usage\)\|\(PID\)" | grep -v grep. Please
let me know if you need additional information. This script is intended
to be run on the cli.
Reproduce code:
---
http://bugs.php.net/?id=47940&edit=1
#48063 [Bgs]: Spontaneously disappearing, cookie-based sessions
ID: 48063
User updated by: myselfasunder at gmail dot com
Reported By: myselfasunder at gmail dot com
Status: Bogus
Bug Type: Session related
Operating System: Ubuntu
PHP Version: 5.2.9
New Comment:
Even if this is the only script that executes on the system (a
front-controller in the only application)?
How about the fact that my session-name is 'COOKIE' in this
test-script... Wouldn't only everything that uses a session-name of
COOKIE interfere with each other, in this case?
Previous Comments:
[2009-04-23 21:02:23] scott...@php.net
You need to set it in the php.ini, if any other script uses sessions
and doesn't set it to be the same value it will delete the sessions.
[2009-04-23 19:06:20] myselfasunder at gmail dot com
");
else
print("Session DOES NOT exist.");
$_SESSION['aa'] = true;
[2009-04-23 17:33:38] j...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
[2009-04-23 16:51:26] myselfasunder at gmail dot com
Description:
I have set the following:
session_name('GOLDENCOLLECTION');
session_set_cookie_params(86400 * 3);
ini_set('session.use_only_cookies', '1');
ini_set('session.gc_maxlifetime', 86400 * 3);
I can load the same page many times successfully. However, if I wait a
while, around twenty minutes, the session's members are no longer
available.
This is the first time I've used cookies to carry the SID (instead of
putting them in the URL).
I have administrative control of the system.
Reproduce code:
---
session_start();
Expected result:
The session should be started and all preexisting members should be
available. They -does- happen, but until only around twenty or thirty
minutes have elapsed, and then they'll be gone.
Actual result:
--
They'll disappear without me doing anything.
--
Edit this bug report at http://bugs.php.net/?id=48063&edit=1
#47940 [Opn]: imap_body() leaks memory
ID: 47940
Updated by: scott...@php.net
Reported By: jake dot levitt at mailtrust dot com
Status: Open
Bug Type: IMAP related
Operating System: Ubuntu 8.04 (linux:2.6.24-21)
PHP Version: 5.2.9
New Comment:
Can you provide the patch as a unified diff, just use the -u flag to
cvs diff.
Previous Comments:
[2009-04-23 19:05:24] jake dot levitt at mailtrust dot com
A co-worker and I have created a diff that seems to fix this issue.
Would someone else mind checking it out and seeing if there are any
problems with it?
diff php_imap.c php_imap_fixed.c
1251a1252
> char *body = mail_fetchtext_full (imap_le_struct->imap_stream,
Z_LVAL_PP(msgno), NIL, myargc==3 ? Z_LVAL_PP(pflags) : NIL);
1253c1254,1255
< RETVAL_STRING(mail_fetchtext_full (imap_le_struct->imap_stream,
Z_LVAL_PP(msgno), NIL, myargc==3 ? Z_LVAL_PP(pflags) : NIL), 1);
---
> RETVAL_STRING(body, 1);
> free(body);
[2009-04-14 18:41:36] jake dot levitt at mailtrust dot com
I tried closing and freeing the imap connection every 100 calls to
imap_body() to see if it was the resource that was holding on to the
memory. This did not help.
Code:
if ($i % 100 === 0) {
echo "Releasing mailbox\n";
imap_close($mailbox);
$mailbox = null;
unset($mailbox);
$mailbox = @imap_open($connect_string, $username, $password, 0,
3);
$reopen_success = imap_reopen($mailbox, $connect_string, 0, 3);
}
[2009-04-14 15:43:56] jake dot levitt at mailtrust dot com
I have now confirmed that this bug also exists in PHP version 5.3.0RC1
on CentOs 5.1.
[2009-04-09 22:31:04] jake dot levitt at mailtrust dot com
Description:
I am creating a script that migrates e-mail from one server to another.
On really large mailboxes, my script dies with "PHP Fatal error: Out
of memory (allocated 13631488) (tried to allocate 3381512 bytes)" even
though memory_get_usage() function was reporting that the script was
only using around 10 MBs. My memory_limit is set to 1GB (but this isn't
coming into play). When I examined the memory usage of the script using
ps, I noticed that it would gradually increase until it reached ~92% of
system memory (I have 2GB). I eventually found that when I commented
out imap_body, the memory usage would stay flat. I wrote a script that
can reproduce this bug. I run the script in the background and then
watch its memory using: ps -eo pid,ppid,rss,vsize,pcpu,pmem,cmd -ww
--sort=pid | grep "\(memory-usage\)\|\(PID\)" | grep -v grep. Please
let me know if you need additional information. This script is intended
to be run on the cli.
Reproduce code:
---
http://bugs.php.net/?id=47940&edit=1
#48063 [Opn->Bgs]: Spontaneously disappearing, cookie-based sessions
ID: 48063
Updated by: scott...@php.net
Reported By: myselfasunder at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Session related
Operating System: Ubuntu
PHP Version: 5.2.9
New Comment:
You need to set it in the php.ini, if any other script uses sessions
and doesn't set it to be the same value it will delete the sessions.
Previous Comments:
[2009-04-23 19:06:20] myselfasunder at gmail dot com
");
else
print("Session DOES NOT exist.");
$_SESSION['aa'] = true;
[2009-04-23 17:33:38] j...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
[2009-04-23 16:51:26] myselfasunder at gmail dot com
Description:
I have set the following:
session_name('GOLDENCOLLECTION');
session_set_cookie_params(86400 * 3);
ini_set('session.use_only_cookies', '1');
ini_set('session.gc_maxlifetime', 86400 * 3);
I can load the same page many times successfully. However, if I wait a
while, around twenty minutes, the session's members are no longer
available.
This is the first time I've used cookies to carry the SID (instead of
putting them in the URL).
I have administrative control of the system.
Reproduce code:
---
session_start();
Expected result:
The session should be started and all preexisting members should be
available. They -does- happen, but until only around twenty or thirty
minutes have elapsed, and then they'll be gone.
Actual result:
--
They'll disappear without me doing anything.
--
Edit this bug report at http://bugs.php.net/?id=48063&edit=1
#48063 [Fbk->Opn]: Spontaneously disappearing, cookie-based sessions
ID: 48063
User updated by: myselfasunder at gmail dot com
Reported By: myselfasunder at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: Session related
Operating System: Ubuntu
PHP Version: 5.2.9
New Comment:
");
else
print("Session DOES NOT exist.");
$_SESSION['aa'] = true;
Previous Comments:
[2009-04-23 17:33:38] j...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
[2009-04-23 16:51:26] myselfasunder at gmail dot com
Description:
I have set the following:
session_name('GOLDENCOLLECTION');
session_set_cookie_params(86400 * 3);
ini_set('session.use_only_cookies', '1');
ini_set('session.gc_maxlifetime', 86400 * 3);
I can load the same page many times successfully. However, if I wait a
while, around twenty minutes, the session's members are no longer
available.
This is the first time I've used cookies to carry the SID (instead of
putting them in the URL).
I have administrative control of the system.
Reproduce code:
---
session_start();
Expected result:
The session should be started and all preexisting members should be
available. They -does- happen, but until only around twenty or thirty
minutes have elapsed, and then they'll be gone.
Actual result:
--
They'll disappear without me doing anything.
--
Edit this bug report at http://bugs.php.net/?id=48063&edit=1
#47940 [Opn]: imap_body() leaks memory
ID: 47940
User updated by: jake dot levitt at mailtrust dot com
Reported By: jake dot levitt at mailtrust dot com
Status: Open
Bug Type: IMAP related
Operating System: Ubuntu 8.04 (linux:2.6.24-21)
PHP Version: 5.2.9
New Comment:
A co-worker and I have created a diff that seems to fix this issue.
Would someone else mind checking it out and seeing if there are any
problems with it?
diff php_imap.c php_imap_fixed.c
1251a1252
> char *body = mail_fetchtext_full (imap_le_struct->imap_stream,
Z_LVAL_PP(msgno), NIL, myargc==3 ? Z_LVAL_PP(pflags) : NIL);
1253c1254,1255
< RETVAL_STRING(mail_fetchtext_full (imap_le_struct->imap_stream,
Z_LVAL_PP(msgno), NIL, myargc==3 ? Z_LVAL_PP(pflags) : NIL), 1);
---
> RETVAL_STRING(body, 1);
> free(body);
Previous Comments:
[2009-04-14 18:41:36] jake dot levitt at mailtrust dot com
I tried closing and freeing the imap connection every 100 calls to
imap_body() to see if it was the resource that was holding on to the
memory. This did not help.
Code:
if ($i % 100 === 0) {
echo "Releasing mailbox\n";
imap_close($mailbox);
$mailbox = null;
unset($mailbox);
$mailbox = @imap_open($connect_string, $username, $password, 0,
3);
$reopen_success = imap_reopen($mailbox, $connect_string, 0, 3);
}
[2009-04-14 15:43:56] jake dot levitt at mailtrust dot com
I have now confirmed that this bug also exists in PHP version 5.3.0RC1
on CentOs 5.1.
[2009-04-09 22:31:04] jake dot levitt at mailtrust dot com
Description:
I am creating a script that migrates e-mail from one server to another.
On really large mailboxes, my script dies with "PHP Fatal error: Out
of memory (allocated 13631488) (tried to allocate 3381512 bytes)" even
though memory_get_usage() function was reporting that the script was
only using around 10 MBs. My memory_limit is set to 1GB (but this isn't
coming into play). When I examined the memory usage of the script using
ps, I noticed that it would gradually increase until it reached ~92% of
system memory (I have 2GB). I eventually found that when I commented
out imap_body, the memory usage would stay flat. I wrote a script that
can reproduce this bug. I run the script in the background and then
watch its memory using: ps -eo pid,ppid,rss,vsize,pcpu,pmem,cmd -ww
--sort=pid | grep "\(memory-usage\)\|\(PID\)" | grep -v grep. Please
let me know if you need additional information. This script is intended
to be run on the cli.
Reproduce code:
---
http://bugs.php.net/?id=47940&edit=1
#42516 [Opn]: __FILE__ resolves symlinks - not mentioned in manual
ID: 42516 User updated by: michael at zedeler dot dk Reported By: michael at zedeler dot dk Status: Open -Bug Type: Documentation problem +Bug Type: Feature/Change Request Operating System: Linux PHP Version: 4.4.7 Assigned To: bjori New Comment: Wrong category. Previous Comments: [2009-04-23 17:53:20] michael at zedeler dot dk Sorry to bug you again, but as I am writing in the report, just putting a description of the errant behaviour is not a useful fix. [2008-04-13 23:46:35] bj...@php.net This bug has been fixed in the documentation's XML sources. Since the online and downloadable versions of the documentation need some time to get updated, we would like to ask you to be a bit patient. Thank you for the report, and for helping us make our documentation better. [2007-09-01 21:02:38] michael at zedeler dot dk Description: __FILE__ does not return the path used to invoke the current file, but resolves symlinks. This behaviour is extremely problematics, since important information is thrown away. The web is teeming with postings from people that are experiencing problems because of this. In http://bugs.php.net/bug.php?id=37603 this bug was mentioned and the response was that it is intended behavior with a reference to the manual. The page http://es.php.net/manual/en/language.constants.predefined.php is the primary source of information for __FILE__, and it does not mention resolving symlinks at all. I'd like if we could have som kind of dialogue about how to solve the problem, in stead of just having this bug being closed with a "Bogus" status. My suggestions are: 1) introduce a new magical constant that behaves as it should. 2) put a parameter in php.ini that changes how __FILE__ behaves. Reproduce code: --- This is basically a reopening of http://bugs.php.net/bug.php?id=37603 Expected result: This is basically a reopening of http://bugs.php.net/bug.php?id=37603 Actual result: -- This is basically a reopening of http://bugs.php.net/bug.php?id=37603 -- Edit this bug report at http://bugs.php.net/?id=42516&edit=1
#23815 [NoF->Fbk]: imagecopymerge doesn't respect alpha-channel in PNG-24 file
ID: 23815
Updated by: paj...@php.net
Reported By: bjorn at smokingmedia dot com
-Status: No Feedback
+Status: Feedback
Bug Type: GD related
Operating System: Linux pluto 2.4.18lvm-r1
PHP Version: 4.3.1
-Assigned To:
+Assigned To: pajoye
New Comment:
Site not accessible (timeout)
Previous Comments:
[2009-04-23 17:52:32] checat at yandex dot ru
PHP version: 5.2.9
CentOS 4
Reproduce code:
http://guppi.spb.ru/php-bug-23815/bg.png');
$over =
imagecreatefrompng('http://guppi.spb.ru/php-bug-23815/over.png');
imagecopymerge($bg, $over, 0,0,0,0,32,32,100);
imagecopymerge($bg, $over, 16,0,0,0,32,32,50);
imagepng($bg, 'imagecopymerge.png');
?>
Expected result:
Proper image:
http://guppi.spb.ru/php-bug-23815/proper.png
Actual result:
Wrong image:
http://guppi.spb.ru/php-bug-23815/imagecopymerge.png
[2003-06-02 17:27:30] sni...@php.net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
[2003-05-26 11:50:26] der...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
[2003-05-26 11:43:05] bjorn at smokingmedia dot com
[[There are similar bugs in the system, but they are either closed or
said to be fixed... i think it's still not fixed..]]
i wanted to do the following. Use a transparent PNG-24(24 bits) file,
with an alpha-channel (with a drop-shadow) and merge it to a background
color. (see sample code).
this works:
imagecopy($backgroundimage, $image_id, 0, 0, 0, 0, $im_X, $im_Y);
this doesn't work:
imagecopymerge($backgroundimage, $image_id, 0, 0, 0, 0, $im_X, $im_Y,
99);
-> with any number instead of 99
sample link:
[change the hex color code to change backgroundcolor]
this is Okay
http://www.smokingmedia.com/test_gd_fb/test?bg=ffee22
this is not okay:
http://www.smokingmedia.com/test_gd_fb/test_nk?bg=ffee22
sample code:
--
Edit this bug report at http://bugs.php.net/?id=23815&edit=1
#48064 [Opn->Bgs]: cURL slow execution time
ID: 48064 Updated by: paj...@php.net Reported By: dgod40 at gmail dot com -Status: Open +Status: Bogus Bug Type: cURL related Operating System: Windows 2000 Pro sp4 PHP Version: 5.2.9 New Comment: no bug :) Previous Comments: [2009-04-23 17:54:36] dgod40 at gmail dot com I am retracting the bug. I found out that if the cookie file is large it takes a while to read/write to it. I dont know if this is a bug or if is standard. [2009-04-23 17:28:15] paj...@php.net Please a script and using localhost as test. [2009-04-23 17:23:23] dgod40 at gmail dot com Description: I recently upgraded from php 5.2.6 to 5.2.9 and now when I run a php script from the command line cURL takes 3 seconds to run. On 5.2.6 it was instantaneous. php 5.2.8 was taking 10 seconds to run. fopen runs instantaneously so it is not a dns lookup issue. All other php scripts run instantaneously. As you can see for the expected result and the actual result php cURL takes a long time to start. Expected result: URL: http://www.google.com [Using CURL] start at 01:13:32 PM Array ( [url] => http://www.google.ca [content_type] => text/html; [http_code] => 200 [header_size] => 375 [request_size] => 497 [filetime] => -1 [ssl_verify_result] => 0 [redirect_count] => 1 [total_time] => 0.437 [namelookup_time] => 0.047 [connect_time] => 0.047 [pretransfer_time] => 0.047 [size_upload] => 0 [size_download] => 6862 [speed_download] => 15702 [speed_upload] => 0 [download_content_length] => [upload_content_length] => -1 [starttransfer_time] => 0.187 [redirect_time] => 0.203 ) end at 01:13:32 PM [Using fopen] - start at 01:13:36 PM Array ( [url] => http://www.google.co [http_code] => 200 ) end at 01:13:36 PM Actual result: -- URL: http://www.google.com [Using CURL] start at 01:13:32 PM Array ( [url] => http://www.google.ca [content_type] => text/html; [http_code] => 200 [header_size] => 375 [request_size] => 497 [filetime] => -1 [ssl_verify_result] => 0 [redirect_count] => 1 [total_time] => 0.437 [namelookup_time] => 0.047 [connect_time] => 0.047 [pretransfer_time] => 0.047 [size_upload] => 0 [size_download] => 6862 [speed_download] => 15702 [speed_upload] => 0 [download_content_length] => [upload_content_length] => -1 [starttransfer_time] => 0.187 [redirect_time] => 0.203 ) end at 01:13:36 PM [Using fopen] - start at 01:13:36 PM Array ( [url] => http://www.google.co [http_code] => 200 ) end at 01:13:36 PM -- Edit this bug report at http://bugs.php.net/?id=48064&edit=1
#48064 [Fbk->Opn]: cURL slow execution time
ID: 48064 User updated by: dgod40 at gmail dot com Reported By: dgod40 at gmail dot com -Status: Feedback +Status: Open Bug Type: cURL related Operating System: Windows 2000 Pro sp4 PHP Version: 5.2.9 New Comment: I am retracting the bug. I found out that if the cookie file is large it takes a while to read/write to it. I dont know if this is a bug or if is standard. Previous Comments: [2009-04-23 17:28:15] paj...@php.net Please a script and using localhost as test. [2009-04-23 17:23:23] dgod40 at gmail dot com Description: I recently upgraded from php 5.2.6 to 5.2.9 and now when I run a php script from the command line cURL takes 3 seconds to run. On 5.2.6 it was instantaneous. php 5.2.8 was taking 10 seconds to run. fopen runs instantaneously so it is not a dns lookup issue. All other php scripts run instantaneously. As you can see for the expected result and the actual result php cURL takes a long time to start. Expected result: URL: http://www.google.com [Using CURL] start at 01:13:32 PM Array ( [url] => http://www.google.ca [content_type] => text/html; [http_code] => 200 [header_size] => 375 [request_size] => 497 [filetime] => -1 [ssl_verify_result] => 0 [redirect_count] => 1 [total_time] => 0.437 [namelookup_time] => 0.047 [connect_time] => 0.047 [pretransfer_time] => 0.047 [size_upload] => 0 [size_download] => 6862 [speed_download] => 15702 [speed_upload] => 0 [download_content_length] => [upload_content_length] => -1 [starttransfer_time] => 0.187 [redirect_time] => 0.203 ) end at 01:13:32 PM [Using fopen] - start at 01:13:36 PM Array ( [url] => http://www.google.co [http_code] => 200 ) end at 01:13:36 PM Actual result: -- URL: http://www.google.com [Using CURL] start at 01:13:32 PM Array ( [url] => http://www.google.ca [content_type] => text/html; [http_code] => 200 [header_size] => 375 [request_size] => 497 [filetime] => -1 [ssl_verify_result] => 0 [redirect_count] => 1 [total_time] => 0.437 [namelookup_time] => 0.047 [connect_time] => 0.047 [pretransfer_time] => 0.047 [size_upload] => 0 [size_download] => 6862 [speed_download] => 15702 [speed_upload] => 0 [download_content_length] => [upload_content_length] => -1 [starttransfer_time] => 0.187 [redirect_time] => 0.203 ) end at 01:13:36 PM [Using fopen] - start at 01:13:36 PM Array ( [url] => http://www.google.co [http_code] => 200 ) end at 01:13:36 PM -- Edit this bug report at http://bugs.php.net/?id=48064&edit=1
#23815 [Com]: imagecopymerge doesn't respect alpha-channel in PNG-24 file
ID: 23815
Comment by: checat at yandex dot ru
Reported By: bjorn at smokingmedia dot com
Status: No Feedback
Bug Type: GD related
Operating System: Linux pluto 2.4.18lvm-r1
PHP Version: 4.3.1
New Comment:
PHP version: 5.2.9
CentOS 4
Reproduce code:
http://guppi.spb.ru/php-bug-23815/bg.png');
$over =
imagecreatefrompng('http://guppi.spb.ru/php-bug-23815/over.png');
imagecopymerge($bg, $over, 0,0,0,0,32,32,100);
imagecopymerge($bg, $over, 16,0,0,0,32,32,50);
imagepng($bg, 'imagecopymerge.png');
?>
Expected result:
Proper image:
http://guppi.spb.ru/php-bug-23815/proper.png
Actual result:
Wrong image:
http://guppi.spb.ru/php-bug-23815/imagecopymerge.png
Previous Comments:
[2003-06-02 17:27:30] sni...@php.net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
[2003-05-26 11:50:26] der...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
[2003-05-26 11:43:05] bjorn at smokingmedia dot com
[[There are similar bugs in the system, but they are either closed or
said to be fixed... i think it's still not fixed..]]
i wanted to do the following. Use a transparent PNG-24(24 bits) file,
with an alpha-channel (with a drop-shadow) and merge it to a background
color. (see sample code).
this works:
imagecopy($backgroundimage, $image_id, 0, 0, 0, 0, $im_X, $im_Y);
this doesn't work:
imagecopymerge($backgroundimage, $image_id, 0, 0, 0, 0, $im_X, $im_Y,
99);
-> with any number instead of 99
sample link:
[change the hex color code to change backgroundcolor]
this is Okay
http://www.smokingmedia.com/test_gd_fb/test?bg=ffee22
this is not okay:
http://www.smokingmedia.com/test_gd_fb/test_nk?bg=ffee22
sample code:
--
Edit this bug report at http://bugs.php.net/?id=23815&edit=1
#48063 [Opn->Fbk]: Spontaneously disappearing, cookie-based sessions
ID: 48063
Updated by: j...@php.net
Reported By: myselfasunder at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: Session related
Operating System: Ubuntu
PHP Version: 5.2.9
New Comment:
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
Previous Comments:
[2009-04-23 16:51:26] myselfasunder at gmail dot com
Description:
I have set the following:
session_name('GOLDENCOLLECTION');
session_set_cookie_params(86400 * 3);
ini_set('session.use_only_cookies', '1');
ini_set('session.gc_maxlifetime', 86400 * 3);
I can load the same page many times successfully. However, if I wait a
while, around twenty minutes, the session's members are no longer
available.
This is the first time I've used cookies to carry the SID (instead of
putting them in the URL).
I have administrative control of the system.
Reproduce code:
---
session_start();
Expected result:
The session should be started and all preexisting members should be
available. They -does- happen, but until only around twenty or thirty
minutes have elapsed, and then they'll be gone.
Actual result:
--
They'll disappear without me doing anything.
--
Edit this bug report at http://bugs.php.net/?id=48063&edit=1
#48064 [Opn->Fbk]: cURL slow execution time
ID: 48064 Updated by: paj...@php.net Reported By: dgod40 at gmail dot com -Status: Open +Status: Feedback Bug Type: cURL related Operating System: Windows 2000 Pro sp4 PHP Version: 5.2.9 New Comment: Please a script and using localhost as test. Previous Comments: [2009-04-23 17:23:23] dgod40 at gmail dot com Description: I recently upgraded from php 5.2.6 to 5.2.9 and now when I run a php script from the command line cURL takes 3 seconds to run. On 5.2.6 it was instantaneous. php 5.2.8 was taking 10 seconds to run. fopen runs instantaneously so it is not a dns lookup issue. All other php scripts run instantaneously. As you can see for the expected result and the actual result php cURL takes a long time to start. Expected result: URL: http://www.google.com [Using CURL] start at 01:13:32 PM Array ( [url] => http://www.google.ca [content_type] => text/html; [http_code] => 200 [header_size] => 375 [request_size] => 497 [filetime] => -1 [ssl_verify_result] => 0 [redirect_count] => 1 [total_time] => 0.437 [namelookup_time] => 0.047 [connect_time] => 0.047 [pretransfer_time] => 0.047 [size_upload] => 0 [size_download] => 6862 [speed_download] => 15702 [speed_upload] => 0 [download_content_length] => [upload_content_length] => -1 [starttransfer_time] => 0.187 [redirect_time] => 0.203 ) end at 01:13:32 PM [Using fopen] - start at 01:13:36 PM Array ( [url] => http://www.google.co [http_code] => 200 ) end at 01:13:36 PM Actual result: -- URL: http://www.google.com [Using CURL] start at 01:13:32 PM Array ( [url] => http://www.google.ca [content_type] => text/html; [http_code] => 200 [header_size] => 375 [request_size] => 497 [filetime] => -1 [ssl_verify_result] => 0 [redirect_count] => 1 [total_time] => 0.437 [namelookup_time] => 0.047 [connect_time] => 0.047 [pretransfer_time] => 0.047 [size_upload] => 0 [size_download] => 6862 [speed_download] => 15702 [speed_upload] => 0 [download_content_length] => [upload_content_length] => -1 [starttransfer_time] => 0.187 [redirect_time] => 0.203 ) end at 01:13:36 PM [Using fopen] - start at 01:13:36 PM Array ( [url] => http://www.google.co [http_code] => 200 ) end at 01:13:36 PM -- Edit this bug report at http://bugs.php.net/?id=48064&edit=1
#48064 [NEW]: cURL slow execution time
From: dgod40 at gmail dot com Operating system: Windows 2000 Pro sp4 PHP version: 5.2.9 PHP Bug Type: cURL related Bug description: cURL slow execution time Description: I recently upgraded from php 5.2.6 to 5.2.9 and now when I run a php script from the command line cURL takes 3 seconds to run. On 5.2.6 it was instantaneous. php 5.2.8 was taking 10 seconds to run. fopen runs instantaneously so it is not a dns lookup issue. All other php scripts run instantaneously. As you can see for the expected result and the actual result php cURL takes a long time to start. Expected result: URL: http://www.google.com [Using CURL] start at 01:13:32 PM Array ( [url] => http://www.google.ca [content_type] => text/html; [http_code] => 200 [header_size] => 375 [request_size] => 497 [filetime] => -1 [ssl_verify_result] => 0 [redirect_count] => 1 [total_time] => 0.437 [namelookup_time] => 0.047 [connect_time] => 0.047 [pretransfer_time] => 0.047 [size_upload] => 0 [size_download] => 6862 [speed_download] => 15702 [speed_upload] => 0 [download_content_length] => [upload_content_length] => -1 [starttransfer_time] => 0.187 [redirect_time] => 0.203 ) end at 01:13:32 PM [Using fopen] - start at 01:13:36 PM Array ( [url] => http://www.google.co [http_code] => 200 ) end at 01:13:36 PM Actual result: -- URL: http://www.google.com [Using CURL] start at 01:13:32 PM Array ( [url] => http://www.google.ca [content_type] => text/html; [http_code] => 200 [header_size] => 375 [request_size] => 497 [filetime] => -1 [ssl_verify_result] => 0 [redirect_count] => 1 [total_time] => 0.437 [namelookup_time] => 0.047 [connect_time] => 0.047 [pretransfer_time] => 0.047 [size_upload] => 0 [size_download] => 6862 [speed_download] => 15702 [speed_upload] => 0 [download_content_length] => [upload_content_length] => -1 [starttransfer_time] => 0.187 [redirect_time] => 0.203 ) end at 01:13:36 PM [Using fopen] - start at 01:13:36 PM Array ( [url] => http://www.google.co [http_code] => 200 ) end at 01:13:36 PM -- Edit bug report at http://bugs.php.net/?id=48064&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48064&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48064&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48064&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48064&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48064&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48064&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48064&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48064&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48064&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48064&r=support Expected behavior: http://bugs.php.net/fix.php?id=48064&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48064&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48064&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48064&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48064&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48064&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48064&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48064&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48064&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48064&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48064&r=mysqlcfg
#48063 [NEW]: Spontaneously disappearing, cookie-based sessions
From: myselfasunder at gmail dot com
Operating system: Ubuntu
PHP version: 5.2.9
PHP Bug Type: Session related
Bug description: Spontaneously disappearing, cookie-based sessions
Description:
I have set the following:
session_name('GOLDENCOLLECTION');
session_set_cookie_params(86400 * 3);
ini_set('session.use_only_cookies', '1');
ini_set('session.gc_maxlifetime', 86400 * 3);
I can load the same page many times successfully. However, if I wait a
while, around twenty minutes, the session's members are no longer
available.
This is the first time I've used cookies to carry the SID (instead of
putting them in the URL).
I have administrative control of the system.
Reproduce code:
---
session_start();
Expected result:
The session should be started and all preexisting members should be
available. They -does- happen, but until only around twenty or thirty
minutes have elapsed, and then they'll be gone.
Actual result:
--
They'll disappear without me doing anything.
--
Edit bug report at http://bugs.php.net/?id=48063&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48063&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48063&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48063&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48063&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48063&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48063&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48063&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48063&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48063&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48063&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48063&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48063&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48063&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48063&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48063&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48063&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48063&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48063&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48063&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48063&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48063&r=mysqlcfg
#45202 [Opn->Fbk]: zlib.output_compression can not be set with ini_set()
ID: 45202 Updated by: j...@php.net Reported By: e dot ehritt at web dot de -Status: Open +Status: Feedback Bug Type: Zlib Related Operating System: Linux 2.6.24.7 i686 PHP Version: 5.2.6 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Previous Comments: [2009-04-21 10:04:24] dypa at bk dot ru not reproduced in win 5.2.9-2 not reproduced in 5.2.6-1+lenny2 [2008-06-07 16:38:11] e dot ehritt at web dot de Description: Configure Command ./configure --prefix=/opt/php/526 --mandir=/opt/php/man --disable-all --disable-cgi --disable-short-tags --enable-memory-limit --with-apxs2=/opt/apache/228/bin/apxs --with-config-file-path=/opt/conf --with-zend-vm=GOTO Server API Apache 2.0 Handler PHP API 20041225 PHP Extension 20060613 Zend Extension 220060519 Debug Build no Thread Safety enabled Zend Memory Manager enabled IPv6 Supportenabled Relevant Part of phpinfo() ZLib Support enabled Stream Wrapper support compress.zlib:// Stream Filtersupport zlib.inflate, zlib.deflate Compiled Version 1.2.3 Linked Version 1.2.3 Directive LocalMaster zlib.output_compressionOn Off zlib.output_compression_level 9-1 zlib.output_handlerno value no value ### Description ### If configuration of zlib.output_compression zlib.output_compression_level is seeded in a php.ini, there are no problems. Output is managed as configured. If configuration of zlib.output_compression zlib.output_compression_level is determined by ini_set(), phpinfo() adopt it but not at all output is compressed. As you can see other Modules are not enabled. Additional zlib extension was built by phpize. Reproduce code: --- -- Edit this bug report at http://bugs.php.net/?id=45202&edit=1
#48050 [Opn->Fbk]: Test Zend/tests/bug30707.phpt Fails
ID: 48050
Updated by: j...@php.net
Reported By: suzuki dot kp at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: Scripting Engine problem
Operating System: Linux
-PHP Version: 5.2.9
+PHP Version: 5.2.6
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Previous Comments:
[2009-04-22 14:49:07] suzuki dot kp at gmail dot com
Description:
Test Zend/tests/bug30707.phpt Fails on 5.2.9.
This test has been failing since at least 5.2.6 version.
Program received signal SIGSEGV, Segmentation fault.
zend_do_fcall_common_helper_SPEC (execute_data=0x7fffbbf0) at
/usr/src/packages/BUILD/php-5.2.6/Zend/zend_vm_execute.h:135
135 if (EX(function_state).function->common.fn_flags &
(ZEND_ACC_ABSTRACT|ZEND_ACC_DEPRECATED)) {
(gdb) bt
#0 zend_do_fcall_common_helper_SPEC (execute_data=0x7fffbbf0) at
/usr/src/packages/BUILD/php-5.2.6/Zend/zend_vm_execute.h:135
#1 0x00657704 in execute (op_array=0xb39e78) at
/usr/src/packages/BUILD/php-5.2.6/Zend/zend_vm_execute.h:92
#2 0x006349e1 in zend_execute_scripts (type=8,
retval=0xb3a5a8, file_count=3) at
/usr/src/packages/BUILD/php-5.2.6/Zend/zend.c:1215
#3 0x005f21cf in php_execute_script
(primary_file=0x7fffe1e0) at
/usr/src/packages/BUILD/php-5.2.6/main/main.c:2026
#4 0x006a6d0e in main (argc=2, argv=0x7fffe3c8) at
/usr/src/packages/BUILD/php-5.2.6/sapi/cli/php_cli.c:1146
(gdb) p *(execute_data)
$11 = {opline = 0xb3a5a8, function_state = {function_symbol_table =
0xb3d810, function = 0x0, reserved = {0x43755fce0d4c3be9, 0xb39f90, 0x0,
0x614740}}, fbc = 0x0, op_array = 0xb39e78, object = 0x0, Ts =
0x7fffba70, CVs = 0x7fffba50, original_in_execution = 0 '\0',
symbol_table = 0x9e6f28, prev_execute_data = 0x0, old_error_reporting
= 0x0}
fbc was zero and thats getting set into function at :
Breakpoint 2, ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x7fffbbf0) at
/usr/src/packages/BUILD/php-5.2.6/Zend/zend_vm_execute.h:321
321 EX(function_state).function = EX(fbc);
Reproduce code:
---
Zend/tests/bug30707.phpt
Actual result:
--
Segmentation fault.
--
Edit this bug report at http://bugs.php.net/?id=48050&edit=1
#48034 [Ver->Ctl]: PHP crashes when script is 8192 (8KB) bytes long
ID: 48034 Updated by: j...@php.net Reported By: ninzya at inbox dot lv -Status: Verified +Status: Critical Bug Type: Reproducible crash Operating System: * PHP Version: 5.3CVS, 6CVS (2009-04-21) Previous Comments: [2009-04-22 11:09:23] bj...@php.net See also bug#48043 [2009-04-21 17:20:21] ninzya at inbox dot lv I did everything mentioned in http://bugs.php.net/bugs-generating-backtrace-win32.php and got these results: Thread 250 - System ID 5552 Entry point msvcrt!_endthreadex+3a Create time 21.04.2009 15:20:51 Time spent in user mode 0 Days 0:0:0.656 Time spent in kernel mode 0 Days 0:0:0.921 Function Arg 1 Arg 2 Arg 3 Source php5ts!lex_scan+447c 0550fa34 010f54a0 002f php5ts!zend_register_auto_global+11f [2009-04-21 15:31:46] lbarn...@php.net It seems related to http://bugs.php.net/bug.php?id=47596 . Not exactly the same problem, though. It seems php_stream_open_for_zend() does not mmap() enough for ZEND_MMAP_AHEAD (PHP_STREAM_OPTION_MMAP_API in plain_wrapper adjusts the mmap length to the filesize, so ignoring ZEND_MMAP_AHEAD), and this may crash when the parser reads ahead of the mmap()ed region. [2009-04-21 11:50:51] ninzya at inbox dot lv PHP is installed as apache module. No fancy filtering, default php/apache installation. All php modules disabled. Bug hits only if file size is 8KB exactly (8192 bytes). PHP 5.2.9 also is affected. By the way, Apache 2.2 is not affected. Seems this is apache 2.0 specific problem. Don't know where to post this issue, here, or in Apache bugtracker. [2009-04-21 11:40:31] j...@php.net Which apache module? Do you have some fancy filtering going on? Does this happen with PHP 5.2.9 ? Do you have any shared extensions loaded? Any Zend extensions like debugger or cache? (disable those and retry) 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/48034 -- Edit this bug report at http://bugs.php.net/?id=48034&edit=1
#48041 [Opn->Fbk]: no headers sent if output is blank
ID: 48041 Updated by: j...@php.net Reported By: mortals at seznam dot cz -Status: Open +Status: Feedback Bug Type: *General Issues Operating System: linux PHP Version: 5.2.9 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ I can not reproduce this on 3 servers (all being 64bit..) Previous Comments: [2009-04-22 09:52:55] mortals at seznam dot cz Description: no headers sent if output is blank on 64bit system (for example redirection dont work). 5.2.9 on 32bit servers is ok. Reproduce code: --- or http://www.example.com'); ?> Expected result: telnet example.com 80 GET /test.php HTTP/1.1 Host: example.com HTTP/1.1 200 OK Date: Wed, 22 Apr 2009 09:23:11 GMT Server: Apache Cache-Control: max-age=7200 Expires: Wed, 22 Apr 2009 11:23:11 GMT Content-Length: 0 Content-Type: text/html Connection closed by foreign host. Actual result: -- telnet example.com 80 GET /test.php HTTP/1.1 Host: example.com Connection closed by foreign host. -- Edit this bug report at http://bugs.php.net/?id=48041&edit=1
#48056 [Opn->Bgs]: require works differently in the interactive console
ID: 48056
Updated by: j...@php.net
Reported By: neerolyte at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: *General Issues
Operating System: Linux
PHP Version: 5.2.9
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Previous Comments:
[2009-04-23 06:45:34] neerolyte at gmail dot com
Description:
Normally any return statements in a file included via require keyword
will cause the require call to return what ever was passed to the return
statement with in the included file.
Reproduce code:
---
include.php:
interactive code:
print_r(require("include.php"));
Expected result:
$ echo '' > include.php
$ php -r 'print_r(require("include.php"));'
stuff from include
$ php -a
Interactive shell
php > print_r(require("include.php"));
stuff from include
Actual result:
--
$ echo '' > include.php
$ php -r 'print_r(require("include.php"));'
stuff from include
$ php -a
Interactive shell
php > print_r(require("include.php"));
1
--
Edit this bug report at http://bugs.php.net/?id=48056&edit=1
#48062 [NEW]: File_exists and clearstatcache not working on network volume
From: dlafond at lenouvelliste dot qc dot ca Operating system: os X Server 10.5.6/Apache 2.2.9 PHP version: 5.2.9 PHP Bug Type: *Directory/Filesystem functions Bug description: File_exists and clearstatcache not working on network volume Description: When files are saved on AFP or SMB mounted sharing, file_exists() and clearstatcache() function are not working as expected. No problem when files are saved on local disk. On AFP or SMB volume, file_exists continue to return true when the file is deleted outside of PHP. clearstatcache() function seems to have no effect. But, if the file is deleted with the unlink() function in php, file_exists return false. Reproduce code: --- Expected result: "exists" when file really exists "not exists" when file doesn't exists Actual result: -- "exists" even after the file was deleted -- Edit bug report at http://bugs.php.net/?id=48062&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48062&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48062&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48062&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48062&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48062&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48062&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48062&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48062&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48062&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48062&r=support Expected behavior: http://bugs.php.net/fix.php?id=48062&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48062&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48062&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48062&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48062&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48062&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48062&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48062&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48062&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48062&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48062&r=mysqlcfg
#48061 [NEW]: Exception when passing array by ref to COM method
From: kmb at kai-m-becker dot de
Operating system: Windows XP SP3
PHP version: 5.2.9
PHP Bug Type: COM related
Bug description: Exception when passing array by ref to COM method
Description:
When calling a COM method with an array argument by reference, a
com_exception "type mismatch" is thrown.
Problem occurs only with arrays(!) as arg by ref.
Scalar types work fine as arg by ref.
php-5.2.9\ext\com_dotnet\com_com.c shows that the exception comes from
IDispatch_Invoke() (Windows-API) called in php_com_invoke_helper().
Reproduce code:
---
$opc = new COM('Matrikon.OPC.Automation'); // <-- certified COM App
$opc->Connect('Matrikon.OPC.Simulation.1');
$opcgroup = $opc->OPCGroups->Add("mes");
// some code to fill $serverhandles
$values = array();
$errors = array();
$qualities = array();
$timestamps = array();
// function SyncRead( // acc. to com_print_typeinfo() and OPC-spec.
///* VT_I2 [2] [in] */ $Source,
///* VT_I4 [3] [in] */ $NumItems,
///* VT_PTR [26] [in] --> VT_SAFEARRAY [27] */ &$ServerHandles,
///* VT_PTR [26] [out] --> VT_SAFEARRAY [27] */ &$Values,
///* VT_PTR [26] [out] --> VT_SAFEARRAY [27] */ &$Errors,
///* VT_PTR [26] [out] --> VT_VARIANT [12] */ &$Qualities,
///* VT_PTR [26] [out] --> VT_VARIANT [12] */ &$TimeStamps
//)
$opcgroup->SyncRead(
OPC_DS_CACHE, count($serverhandles), $serverhandles, // [in] args
$values, $errors, $qualities, $timestamps // [out] args
);
Expected result:
Successful call to SyncRead().
Actual result:
--
com_exception: Parameter 4: Typkonflikt (= type mismatch)
#0 opc_read_test.php(148): variant->SyncRead(1, 56, Array,
Object(variant), Object(variant), Object(variant), Object(variant))
#1 {main}
--
Edit bug report at http://bugs.php.net/?id=48061&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48061&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48061&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48061&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48061&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48061&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48061&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48061&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48061&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48061&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48061&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48061&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48061&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48061&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48061&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48061&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48061&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48061&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48061&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48061&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48061&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48061&r=mysqlcfg
#46274 [Asn->Csd]: pdo_pgsql - Segfault when using PDO::ATTR_STRINGIFY_FETCHES and blob
ID: 46274
Updated by: mbecc...@php.net
Reported By: fel...@php.net
-Status: Assigned
+Status: Closed
Bug Type: PDO related
Operating System: Linux
PHP Version: 5.3CVS-2008-10-11 (CVS)
Assigned To: mbeccati
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2009-04-23 11:41:32] mbecc...@php.net
The fix is not properly working under some circumstances: the get_col
function might be returning a (php_stream *) which is treated like a
string by the empty string check, leading to inconsistent result (empty
LOB) and a memory leak.
I have a fix almost ready, reopening the bug to keep trace of it.
[2008-10-12 13:04:01] fel...@php.net
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2008-10-12 01:23:39] fel...@php.net
Oh, that isn't fixed yet.
[2008-10-11 19:05:50] fel...@php.net
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2008-10-11 00:52:24] fel...@php.net
Description:
See below.
Reproduce code:
---
TRUE));
$res = $db->prepare("SELECT blob1 from test_one_blob");
$res->execute();
var_dump($res->fetch(PDO::FETCH_NUM));
Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb77e26d0 (LWP 18255)]
0x0839a800 in _php_stream_stat (stream=0x88b4500, ssb=0xbfac2124,
tsrm_ls=0x8767070) at /home/felipe/dev/php5/main/streams/streams.c:693
693 if (stream->wrapper && stream->wrapper->wops->stream_stat !=
NULL)
{
(gdb) bt
#0 0x0839a800 in _php_stream_stat (stream=0x88b4500, ssb=0xbfac2124,
tsrm_ls=0x8767070) at /home/felipe/dev/php5/main/streams/streams.c:693
#1 0x0839b9f0 in _php_stream_copy_to_mem (src=0x88b4500,
buf=0xbfac21f0, maxlen=0, persistent=0, __php_stream_call_depth=0,
__zend_filename=0x86bbd58
"/home/felipe/dev/php5/ext/pdo/pdo_stmt.c", __zend_lineno=608,
__zend_orig_filename=0x0, __zend_orig_lineno=0, tsrm_ls=0x8767070)
at /home/felipe/dev/php5/main/streams/streams.c:1254
#2 0x08130c5d in fetch_value (stmt=0x88b3bcc, dest=0x88b394c, colno=0,
type_override=0x0, tsrm_ls=0x8767070) at
/home/felipe/dev/php5/ext/pdo/pdo_stmt.c:608
#3 0x08132732 in do_fetch (stmt=0x88b3bcc, do_bind=1,
return_value=0x88b39e4, how=PDO_FETCH_NUM, ori=PDO_FETCH_ORI_NEXT,
offset=0, return_all=0x0,
tsrm_ls=0x8767070) at
/home/felipe/dev/php5/ext/pdo/pdo_stmt.c:1123
#4 0x081338c6 in zim_PDOStatement_fetch (ht=1, return_value=0x88b39e4,
return_value_ptr=0x0, this_ptr=0x88b2318, return_value_used=1,
tsrm_ls=0x8767070)
at /home/felipe/dev/php5/ext/pdo/pdo_stmt.c:1401
#5 0x0843efbd in zend_do_fcall_common_helper_SPEC
(execute_data=0x88e1674, tsrm_ls=0x8767070) at
/home/felipe/dev/php5/Zend/zend_vm_execute.h:315
#6 0x0844017b in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x88e1674, tsrm_ls=0x8767070) at
/home/felipe/dev/php5/Zend/zend_vm_execute.h:428
#7 0x0843dd6c in execute (op_array=0x88b2ad0, tsrm_ls=0x8767070) at
/home/felipe/dev/php5/Zend/zend_vm_execute.h:104
#8 0x0840e59b in zend_execute_scripts (type=8, tsrm_ls=0x8767070,
retval=0x0, file_count=3) at /home/felipe/dev/php5/Zend/zend.c:1197
#9 0x0837ecbe in php_execute_script (primary_file=0xbfac48b8,
tsrm_ls=0x8767070) at /home/felipe/dev/php5/main/main.c:2080
#10 0x084add03 in main (argc=2, argv=0xbfac4a14) at
/home/felipe/dev/php5/sapi/cli/php_cli.c:1130
--
Edit this bug report at http://bugs.php.net/?id=46274&edit=1
#48060 [Asn->Csd]: pdo_pgsql - large objects are returned as empty
ID: 48060 Updated by: mbecc...@php.net Reported By: mbecc...@php.net -Status: Assigned +Status: Closed Bug Type: PDO related Operating System: * PHP Version: 5.3CVS-2009-04-23 (CVS) Assigned To: mbeccati New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2009-04-23 13:17:59] mbecc...@php.net Description: Bug isn't always reproducible. It might depend on various factors like e.g. memory addresses in use (to me it happens when pdo_oci support is compiled in). Explanation: the fix for bug #46274 is not properly working under some circumstances. The get_col function might be returning a (php_stream *) which is treated like a string by the empty string check, leading to inconsistent result (empty LOB) and a memory leak. -- Edit this bug report at http://bugs.php.net/?id=48060&edit=1
#48060 [Opn->Asn]: pdo_pgsql - large objects are returned as empty
ID: 48060 Updated by: mbecc...@php.net Reported By: mbecc...@php.net -Status: Open +Status: Assigned Bug Type: PDO related Operating System: * PHP Version: 5.3CVS-2009-04-23 (CVS) -Assigned To: +Assigned To: mbeccati Previous Comments: [2009-04-23 13:17:59] mbecc...@php.net Description: Bug isn't always reproducible. It might depend on various factors like e.g. memory addresses in use (to me it happens when pdo_oci support is compiled in). Explanation: the fix for bug #46274 is not properly working under some circumstances. The get_col function might be returning a (php_stream *) which is treated like a string by the empty string check, leading to inconsistent result (empty LOB) and a memory leak. -- Edit this bug report at http://bugs.php.net/?id=48060&edit=1
#48060 [NEW]: pdo_pgsql - large objects are returned as empty
From: mbecc...@php.net Operating system: * PHP version: 5.3CVS-2009-04-23 (CVS) PHP Bug Type: PDO related Bug description: pdo_pgsql - large objects are returned as empty Description: Bug isn't always reproducible. It might depend on various factors like e.g. memory addresses in use (to me it happens when pdo_oci support is compiled in). Explanation: the fix for bug #46274 is not properly working under some circumstances. The get_col function might be returning a (php_stream *) which is treated like a string by the empty string check, leading to inconsistent result (empty LOB) and a memory leak. -- Edit bug report at http://bugs.php.net/?id=48060&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48060&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48060&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48060&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48060&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48060&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48060&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48060&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48060&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48060&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48060&r=support Expected behavior: http://bugs.php.net/fix.php?id=48060&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48060&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48060&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48060&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48060&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48060&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48060&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48060&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48060&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48060&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48060&r=mysqlcfg
#15841 [Com]: CRLF to separate mail headers is incorrect
ID: 15841
Comment by: bernardo at tsolucio dot com
Reported By: rha at juggernaut dot com dot au
Status: No Feedback
Bug Type: Mail related
Operating System: Linux
PHP Version: 4.1.2
Assigned To: yohgaki
New Comment:
I agree totally with Philipp, the current documentation note is
ridiculous.Can't developers understand that they're not dealing with a
STMP server on Linux? If you don't want to fix it, at least document the
flaw correctly.
Previous Comments:
[2009-02-28 12:48:51] philipp dot kempgen at amooma dot de
Ok guys, if it's not mail() which is wrong then
it's a documentation problem.
---cut---
Note: If messages are not received, try using a LF (\n) only. Some poor
quality Unix mail transfer agents replace LF by CRLF automatically
(which leads to doubling CR if CRLF is used). This should be a last
resort, as it does not comply with » RFC 2822.
---cut---
This is _not_ about "poor quality" MTAs or a "last resort".
The note should read:
Note: mail() talks to the sendmail command on Unix/Linux which
expects line endings to be the platform's native line endings
which is LF (\n) only on Unix/Linux and CRLF (\r\n) on Windows.
The sendmail will replace LF (\n) by CRLF (\r\n) automatically
to comply with RFC 2822. Thus you should use the special PHP_EOL
constant to separate mail headers.
[2008-10-16 13:12:44] devnull at div dot org
I just had a little run-in with the postfix developers over at
postfix-users about this issue.
http://tech.groups.yahoo.com/group/postfix-users/message/244799
Quote:Wietse Venema:
>> Specifically, Postfix accepts local submissions in UNIX format
>> (LF) or MSDOS format (CRLF) format BUT YOU MIST NOT MIX FORMATS.
>
> So how does postfix determine what format you are using?
> Is there a way to explicitly tell it what to expect?
>
Postfix looks at the first input line. There currently is no
way to override this, so your best bet is to use the same line
terminator consistently (having a first line with CRLF might
work "best" for hybrid mail, but that behavior is not promised).
The current behavior originates from the time when binary transparency
was considered a good thing.
--
There seemed to me to be a marked hostility towards the idea of trying
to be helpful about this, but on the other hand I got the impression
they might not be hostile if someone offered a patch for a
SENDMAIL_EOF_COMPAT_MODE or similar.
Personally I am not much good at C, but the challenge is hereby issued
:)
[2007-02-21 09:16:42] m_alpka at tlen dot pl
I discovered another temporary solution. It's similar to @guy's but it
is not using additional scripts that have to be installed
(unix2dos,dos2unix). Also php didn't allow me to use piped sendmail in
sendmail_path (php.ini)
I'm using qmail.
---
cd /var/qmail/bin
cat > sendmailfix
#!/bin/sh
sed 's/^M$//' | /var/qmail/bin/sendmail ${1+"$@"}
[Ctrl+D]
chmod 555 sendmailfix
chgrp popuser sendmailfix
---
^M is a combination of [Ctrl+V, Ctrl+M]
Finally set the value of sendmail_path in php.ini to our script
---
sendmail_path = /var/qmail/bin/sendmailfix -t -i
[2007-02-07 10:05:27] tony2...@php.net
http://www.php.net/manual/en/reserved.constants.php
PHP_EOL (string)
Available since PHP 4.3.10 and PHP 5.0.2
[2007-02-07 09:55:43] bigtree at donotspam dot 29a dot nl
Might I suggest to add a platform-dependant PHP constant (for example
MAIL_HEADER_SEPARATOR) so we can use the mail() function with
platform-independent code?
The constant value would be '\n' on unix and '\r\n' on windows.
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/15841
--
Edit this bug report at http://bugs.php.net/?id=15841&edit=1
#48058 [Opn->Asn]: DateTimeZone::getTransitions output different on 64 bit
ID: 48058
Updated by: der...@php.net
Reported By: wharmby at uk dot ibm dot com
-Status: Open
+Status: Assigned
Bug Type: Date/time related
Operating System: Linux 64 bit
PHP Version: 5.3CVS-2009-04-23 (snap)
-Assigned To:
+Assigned To: derick
New Comment:
It looks bogus, but it is (sortof) correct. If you go
-9223372036854775808 seconds back from 1970-01-01 you end up at a date
219 billion years in the past. Not sure why it formats wrong though.
Previous Comments:
[2009-04-23 08:57:58] wharmby at uk dot ibm dot com
Description:
First entry in array returned by DateTimeZone method getTransitions
(and function timezone_transitions_get()looks bogus on 64 bit systems. I
expected same result when running this command on 32 and 64 bit
systems.
Problem affects current levels of PHP 5.3 and 6.0 (snapshot timestamp
== Wed 22-04-2009 6:30:00 ) only.
Looks like problem caused by use of constant LONG_MIN at around line
3218 in current src of ext/dates/date.c introduced by the following
change:
=
Revision 1.43.2.45.2.51.2.28 - (view) (download) (as text) (annotate) -
[select for diffs]
Thu Mar 20 19:43:36 2008 UTC (13 months ago) by derick
Branch: PHP_5_3
Changes since 1.43.2.45.2.51.2.27: +57 -24 lines
Diff to previous 1.43.2.45.2.51.2.27 , to branch point 1.43.2.45.2.51
- MFH: Fix the DateTimeZone::getTransitions() algorithm.
==
Reproduce code:
---
getTransitions();
var_dump( $tran );
?>
Expected result:
(as produced by same code running on Linux 32 bits system)
array(243) {
[0]=>
array(5) {
["ts"]=>
int(-2147483648)
["time"]=>
string(24) "1901-12-13T20:45:52+"
["offset"]=>
int(3600)
["isdst"]=>
bool(true)
["abbr"]=>
string(3) "BST"
}
Actual result:
--
array(243) {
[0]=>
array(5) {
["ts"]=>
int(-9223372036854775808) <- == LONG_MIN
["time"]=>
string(30) "-219246529-01-27T08:29:52+" <- Bogus looking entry
["offset"]=>
int(3600)
["isdst"]=>
bool(true)
["abbr"]=>
string(3) "BST"
}
--
Edit this bug report at http://bugs.php.net/?id=48058&edit=1
#48046 [Bgs]: memory does not free with unset?
ID: 48046 User updated by: nikitin at freshframes dot com Reported By: nikitin at freshframes dot com Status: Bogus Bug Type: Performance problem Operating System: linux suse 10.3 PHP Version: 5.2.9 New Comment: well today the import on the suse system worked like a charm... no idea why, i am not the admin of the system, dunno if it was updated or not, scripts haven't changed... if i experience the problem again, i will let you know... Previous Comments: [2009-04-22 15:56:14] nikitin at freshframes dot com this is the output of a magento-shop item import script. it requires csv data and db usage, i am afraid i cannot break it into pieces right now. but i like to give some more support about the error i get: - whether i use unset or not, php5.2.8 on debian works, php5.2.9 on suse not - i have a private server with debian php5.2.9-0.dotdeb.1 where it works, too the debug says: debian: php has a memory usage increase of 0.03-0.1mb per loop suse: php has a memory usage increase of 2-3mb per loop debian was my testserver, and suse is what our customer has. beside that, scripts and data are totally equal there is a warning whenever i use suse php5.2.9: PHP Warning: Call-time pass-by-reference has been deprecated in ... -> but this does not occur in php5.2.9-0.dotdeb.1 so probably a php configuration problem? i dont know... [2009-04-22 15:03:51] scott...@php.net When you pass in true to memory_get_usage() and memory_get_peak_usage() you get the memory allocated from the system not the memory allocated for the script. If you remove the values of true from both of these you'll see you should get. With Unset Current REAL Usage: 0.12MB -- Peak: 198.01MB [2009-04-22 14:41:54] boettcher at freshframes dot com You need 250MB memory_limit to execute. - This script uses ~200MB at the end of script and got a peak of ~200MB. If you uncomment the unsets you'll have less memory (current) usage and a slight less memory peak - --- statistics of my server (debian 4.0) [4 tests] -- W/O Unset Current REAL Usage: 207.75MB -- Peak: 212.75MB - W/O Unset Current REAL Usage: 208.25MB -- Peak: 213MB - W/O Unset Current REAL Usage: 208MB -- Peak: 212.75MB - W/O Unset Current REAL Usage: 208MB -- Peak: 212.75MB -- and now with unset uncommented [4 tests] -- With Unset Current REAL Usage: 40.25MB -- Peak: 209.75MB - With Unset Current REAL Usage: 40MB -- Peak: 209.75MB - With Unset Current REAL Usage: 38.75MB -- Peak: 209.75MB - With Unset Current REAL Usage: 37.75MB -- Peak: 209.75MB [2009-04-22 13:54:28] scott...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. Memory is never freed back to the system until the request ends, PHP will however re-use the memory assuming that a block the right size can be found. [2009-04-22 13:51:07] crrodriguez at opensuse dot org unset has never freed memory, memory is freed at script shutdown. 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/48046 -- Edit this bug report at http://bugs.php.net/?id=48046&edit=1
#46274 [Csd->Asn]: pdo_pgsql - Segfault when using PDO::ATTR_STRINGIFY_FETCHES and blob
ID: 46274
Updated by: mbecc...@php.net
Reported By: fel...@php.net
-Status: Closed
+Status: Assigned
Bug Type: PDO related
Operating System: Linux
PHP Version: 5.3CVS-2008-10-11 (CVS)
-Assigned To: felipe
+Assigned To: mbeccati
New Comment:
The fix is not properly working under some circumstances: the get_col
function might be returning a (php_stream *) which is treated like a
string by the empty string check, leading to inconsistent result (empty
LOB) and a memory leak.
I have a fix almost ready, reopening the bug to keep trace of it.
Previous Comments:
[2008-10-12 13:04:01] fel...@php.net
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2008-10-12 01:23:39] fel...@php.net
Oh, that isn't fixed yet.
[2008-10-11 19:05:50] fel...@php.net
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2008-10-11 00:52:24] fel...@php.net
Description:
See below.
Reproduce code:
---
TRUE));
$res = $db->prepare("SELECT blob1 from test_one_blob");
$res->execute();
var_dump($res->fetch(PDO::FETCH_NUM));
Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb77e26d0 (LWP 18255)]
0x0839a800 in _php_stream_stat (stream=0x88b4500, ssb=0xbfac2124,
tsrm_ls=0x8767070) at /home/felipe/dev/php5/main/streams/streams.c:693
693 if (stream->wrapper && stream->wrapper->wops->stream_stat !=
NULL)
{
(gdb) bt
#0 0x0839a800 in _php_stream_stat (stream=0x88b4500, ssb=0xbfac2124,
tsrm_ls=0x8767070) at /home/felipe/dev/php5/main/streams/streams.c:693
#1 0x0839b9f0 in _php_stream_copy_to_mem (src=0x88b4500,
buf=0xbfac21f0, maxlen=0, persistent=0, __php_stream_call_depth=0,
__zend_filename=0x86bbd58
"/home/felipe/dev/php5/ext/pdo/pdo_stmt.c", __zend_lineno=608,
__zend_orig_filename=0x0, __zend_orig_lineno=0, tsrm_ls=0x8767070)
at /home/felipe/dev/php5/main/streams/streams.c:1254
#2 0x08130c5d in fetch_value (stmt=0x88b3bcc, dest=0x88b394c, colno=0,
type_override=0x0, tsrm_ls=0x8767070) at
/home/felipe/dev/php5/ext/pdo/pdo_stmt.c:608
#3 0x08132732 in do_fetch (stmt=0x88b3bcc, do_bind=1,
return_value=0x88b39e4, how=PDO_FETCH_NUM, ori=PDO_FETCH_ORI_NEXT,
offset=0, return_all=0x0,
tsrm_ls=0x8767070) at
/home/felipe/dev/php5/ext/pdo/pdo_stmt.c:1123
#4 0x081338c6 in zim_PDOStatement_fetch (ht=1, return_value=0x88b39e4,
return_value_ptr=0x0, this_ptr=0x88b2318, return_value_used=1,
tsrm_ls=0x8767070)
at /home/felipe/dev/php5/ext/pdo/pdo_stmt.c:1401
#5 0x0843efbd in zend_do_fcall_common_helper_SPEC
(execute_data=0x88e1674, tsrm_ls=0x8767070) at
/home/felipe/dev/php5/Zend/zend_vm_execute.h:315
#6 0x0844017b in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=0x88e1674, tsrm_ls=0x8767070) at
/home/felipe/dev/php5/Zend/zend_vm_execute.h:428
#7 0x0843dd6c in execute (op_array=0x88b2ad0, tsrm_ls=0x8767070) at
/home/felipe/dev/php5/Zend/zend_vm_execute.h:104
#8 0x0840e59b in zend_execute_scripts (type=8, tsrm_ls=0x8767070,
retval=0x0, file_count=3) at /home/felipe/dev/php5/Zend/zend.c:1197
#9 0x0837ecbe in php_execute_script (primary_file=0xbfac48b8,
tsrm_ls=0x8767070) at /home/felipe/dev/php5/main/main.c:2080
#10 0x084add03 in main (argc=2, argv=0xbfac4a14) at
/home/felipe/dev/php5/sapi/cli/php_cli.c:1130
--
Edit this bug report at http://bugs.php.net/?id=46274&edit=1
#48059 [NEW]: SimpleXmlElement __toString() not called on (string) cast
From: doctorrock83 at gmail dot com
Operating system: Win32
PHP version: 5.2.9
PHP Bug Type: SimpleXML related
Bug description: SimpleXmlElement __toString() not called on (string) cast
Description:
If I extend SimpleXmlElement and add a __toString() method to it, that
method is not called when I cast my object using (string)$obj.
It is used however on implicit casts (e.g echo $sxmlObj)
Reproduce code:
---
class MyXml extends SimpleXMLElement
{
public function __toString()
{
return $this->asXML();
}
public function export()
{
return (string)$this;
}
}
$xml = new MyXml("xml");
echo $xml; // 1
$a = (string)$xml;
echo $a; // 2
echo $xml->export(); // 3
Expected result:
1 :
xml returned
2 :
xml returned
3:
xml returned
Actual result:
--
1 :
OK
2:
nothing is returned
3:
nothing is returned
--
Edit bug report at http://bugs.php.net/?id=48059&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48059&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48059&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48059&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48059&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48059&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48059&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48059&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48059&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48059&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48059&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48059&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48059&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48059&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48059&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48059&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48059&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48059&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48059&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48059&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48059&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48059&r=mysqlcfg
#48058 [NEW]: DateTimeZone::getTransitions output different on 64 bit
From: wharmby at uk dot ibm dot com
Operating system: Linux 64 bit
PHP version: 5.3CVS-2009-04-23 (snap)
PHP Bug Type: Date/time related
Bug description: DateTimeZone::getTransitions output different on 64 bit
Description:
First entry in array returned by DateTimeZone method getTransitions (and
function timezone_transitions_get()looks bogus on 64 bit systems. I
expected same result when running this command on 32 and 64 bit systems.
Problem affects current levels of PHP 5.3 and 6.0 (snapshot timestamp ==
Wed 22-04-2009 6:30:00 ) only.
Looks like problem caused by use of constant LONG_MIN at around line 3218
in current src of ext/dates/date.c introduced by the following change:
=
Revision 1.43.2.45.2.51.2.28 - (view) (download) (as text) (annotate) -
[select for diffs]
Thu Mar 20 19:43:36 2008 UTC (13 months ago) by derick
Branch: PHP_5_3
Changes since 1.43.2.45.2.51.2.27: +57 -24 lines
Diff to previous 1.43.2.45.2.51.2.27 , to branch point 1.43.2.45.2.51
- MFH: Fix the DateTimeZone::getTransitions() algorithm.
==
Reproduce code:
---
getTransitions();
var_dump( $tran );
?>
Expected result:
(as produced by same code running on Linux 32 bits system)
array(243) {
[0]=>
array(5) {
["ts"]=>
int(-2147483648)
["time"]=>
string(24) "1901-12-13T20:45:52+"
["offset"]=>
int(3600)
["isdst"]=>
bool(true)
["abbr"]=>
string(3) "BST"
}
Actual result:
--
array(243) {
[0]=>
array(5) {
["ts"]=>
int(-9223372036854775808) <- == LONG_MIN
["time"]=>
string(30) "-219246529-01-27T08:29:52+" <- Bogus looking entry
["offset"]=>
int(3600)
["isdst"]=>
bool(true)
["abbr"]=>
string(3) "BST"
}
--
Edit bug report at http://bugs.php.net/?id=48058&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48058&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48058&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48058&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48058&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48058&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48058&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48058&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48058&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48058&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48058&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48058&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48058&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48058&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48058&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48058&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48058&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48058&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48058&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48058&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48058&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48058&r=mysqlcfg
#48057 [NEW]: Only the date fields of the first row are fetched, others are empty
From: info at programmiernutte dot net
Operating system: no matter
PHP version: 5.3.0RC1
PHP Bug Type: PDO related
Bug description: Only the date fields of the first row are fetched, others are
empty
Description:
PDO::fetch() only returns date fields on the first call.
subsequent calls return empty strings instead of dates.
Configure Command => './configure' '--
prefix=/usr/local/php' '--with-apxs2' '--without-pdo-sqlite'
'--without-mysql'
php.ini-settings don't seem to matter, I only have these:
date.timezone = "Europe/Berlin"
include_path = "/Library/WebServer/php-includes/"
allow_call_time_pass_reference = Off
expose_php = Off
magic_quotes_gpc = Off
register_argc_argv = Off
output_buffering = On
plus settings for xdebug, apc and memcache, I already tried
disabling them, no difference.
PDO_FIREBIRD is loaded as an
extension:extension=pdo_firebird.so
Reproduce code:
---
isql:
SQL> create database 'test.fdb';
SQL> CREATE TABLE FOO (ID INTEGER, BAR DATE);
SQL> INSERT INTO FOO (ID, BAR) VALUES ('1', '11.04.2009');
SQL> INSERT INTO FOO (ID, BAR) VALUES ('2', '12.04.2009');
SQL> INSERT INTO FOO (ID, BAR) VALUES ('3', '13.04.2009');
php:
true,
PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_OBJ
)
);
$oStmt = $oPDO->query('select id, bar from foo');
foreach($oStmt as $oRow)
{
var_dump($oRow);
}
?>
Expected result:
object(stdClass)#3 (2) {
["ID"]=>
string(1) "1"
["BAR"]=>
string(10) "2009-04-11"
}
object(stdClass)#4 (2) {
["ID"]=>
string(1) "2"
["BAR"]=>
string(10) "2009-04-12"
}
object(stdClass)#3 (2) {
["ID"]=>
string(1) "3"
["BAR"]=>
string(10) "2009-04-13"
}
Actual result:
--
object(stdClass)#3 (2) {
["ID"]=>
string(1) "1"
["BAR"]=>
string(10) "2009-04-11"
}
object(stdClass)#4 (2) {
["ID"]=>
string(1) "2"
["BAR"]=>
string(0) ""
}
object(stdClass)#3 (2) {
["ID"]=>
string(1) "3"
["BAR"]=>
string(0) ""
}
--
Edit bug report at http://bugs.php.net/?id=48057&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48057&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48057&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48057&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48057&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48057&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48057&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48057&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48057&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48057&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48057&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48057&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48057&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48057&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48057&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48057&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48057&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48057&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48057&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48057&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48057&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48057&r=mysqlcfg
