#48134 [NEW]: php crash after a few days (backtrace attached)
From: jimbobpalmer at gmail dot com Operating system: Gentoo PHP version: 5.2.9 PHP Bug Type: Reproducible crash Bug description: php crash after a few days (backtrace attached) Description: 5.2.8-pl2-gentoo, I can't upgrade atm. No crashes for a few days, then logs, like this one: Backtrace: pid 19488 mod_backtrace main() is at 8066050 /usr/lib/apache2/modules/mod_backtrace.so[0xb7b7aa9a] /usr/sbin/apache2(ap_run_fatal_exception+0x3f)[0x80827ef] /usr/sbin/apache2[0x8082be8] [0xb7f67400] /usr/lib/apache2/modules/libphp5.so[0xb78407cf] /usr/sbin/apache2(ap_run_handler+0x57)[0x807a127] /usr/sbin/apache2(ap_invoke_handler+0x91)[0x807d4b1] /usr/sbin/apache2(ap_process_request+0x196)[0x80887e6] /usr/sbin/apache2[0x80857d8] /usr/sbin/apache2(ap_run_process_connection+0x57)[0x80814b7] /usr/sbin/apache2[0x808e6ac] /usr/lib/libapr-1.so.0[0xb7d77e8e] /lib/libpthread.so.0[0xb7d0419b] /lib/libc.so.6(clone+0x5e)[0xb7c8886e] I have to restart Apache. -- Edit bug report at http://bugs.php.net/?id=48134&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48134&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48134&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48134&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48134&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48134&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48134&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48134&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48134&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48134&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48134&r=support Expected behavior: http://bugs.php.net/fix.php?id=48134&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48134&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48134&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48134&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48134&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48134&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48134&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48134&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48134&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48134&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48134&r=mysqlcfg
#47640 [Bgs]: Session does not close file in /tmp/
ID: 47640 User updated by: manuel dot schmitt at manitu dot de Reported By: manuel dot schmitt at manitu dot de Status: Bogus Bug Type: Session related Operating System: Linux PHP Version: 5.2.9 New Comment: ACK, but as server administrator there *must* be a way to prevent this. Admins do not have influence on the scripts that are used by webmasters. So I think it's a PHP thing. Likely one should automatically close all sessions that were opened by scripts aborting / running into limits sets by php (e.g. exec time) etc. This should solve it. Previous Comments: [2009-05-02 18:42:02] j...@php.net Endless loops tend to cause such problems. One should always use http://www.php.net/session_write_close as early as possible to prevent race conditions and this kind of "bugs". [2009-03-17 06:32:36] manuel dot schmitt at manitu dot de ARGH! It is so simple! Execute it for the first time and ensure, that it runs into any of the php limits, e.g. maxmimum execution time. Call the script a second time while not running into the limit. When tracing the PHP process you will see an unlimited flock() syscall! [2009-03-16 23:46:42] j...@php.net You need to come up with a script / set of scripts which can be used to _reliably_ reproduce the issue. [2009-03-16 16:29:03] manuel dot schmitt at manitu dot de But how should I trace this anymore? I can strace apache/php processes seeing that there is a PHP script doing flock() on a file, the process never returns. What should I do? [2009-03-16 16:25:10] j...@php.net I'm actually running also s9y installation in the high traffic server. Never had any hanging PHP processes. And many times scripts have run to limits due to database being too slow. Still, no hangups with sessions. As this is quite impossible to reproduce, please try and figure out what really causes it. I know it's hard but otherwise we can keep on guessing and that's pretty useless. 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/47640 -- Edit this bug report at http://bugs.php.net/?id=47640&edit=1
#48135 [NEW]: Isset doesn't function as expected
From: wizanda at yahoo dot co dot uk
Operating system: all
PHP version: 5.2.9
PHP Bug Type: Feature/Change Request
Bug description: Isset doesn't function as expected
Description:
Since PHP 5 most PHP systems will be storing masses of data, due to isset
and empty no longer assessing the full variable, yet running code once for
each item within it.
Reproduce code:
---
---
>From manual page: function.isset
---
function &loadHandler($name){static $handler;
if(!isset($handler[$name])){$FileName = "core/core.".$name.".php";
require_once $FileName;
$ClassName = "SmartyCore_".$name;
$handler[$name] = new $ClassName();}
$classes = $handler[$name];
return $classes;}
Expected result:
This should check $handler, see if it's empty the first time; check $name
and see this is an empty array, attempt to fill it and thus setting the
$handler as being a container for the array and then check for each $name
as a separate array within it.
Actual result:
--
What this appears to be doing is checking $handler and running it, then
checking $name and running it... So when you var_dump the $handler it has
multiple copies of the variable set.
This can be slightly resolved by making the array set the original
$handler variable, which reduces the copies made.
$handler = array($name => new $ClassName());}
...Yet there should be only one copy set.
--
Edit bug report at http://bugs.php.net/?id=48135&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48135&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48135&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48135&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48135&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48135&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48135&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48135&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48135&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48135&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48135&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48135&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48135&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48135&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48135&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48135&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48135&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48135&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48135&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48135&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48135&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48135&r=mysqlcfg
#48134 [Opn->Bgs]: php crash after a few days (backtrace attached)
ID: 48134 Updated by: j...@php.net Reported By: jimbobpalmer at gmail dot com -Status: Open +Status: Bogus Bug Type: Reproducible crash Operating System: Gentoo PHP Version: 5.2.9 New Comment: Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PHP. Previous Comments: [2009-05-03 11:03:52] jimbobpalmer at gmail dot com Description: 5.2.8-pl2-gentoo, I can't upgrade atm. No crashes for a few days, then logs, like this one: Backtrace: pid 19488 mod_backtrace main() is at 8066050 /usr/lib/apache2/modules/mod_backtrace.so[0xb7b7aa9a] /usr/sbin/apache2(ap_run_fatal_exception+0x3f)[0x80827ef] /usr/sbin/apache2[0x8082be8] [0xb7f67400] /usr/lib/apache2/modules/libphp5.so[0xb78407cf] /usr/sbin/apache2(ap_run_handler+0x57)[0x807a127] /usr/sbin/apache2(ap_invoke_handler+0x91)[0x807d4b1] /usr/sbin/apache2(ap_process_request+0x196)[0x80887e6] /usr/sbin/apache2[0x80857d8] /usr/sbin/apache2(ap_run_process_connection+0x57)[0x80814b7] /usr/sbin/apache2[0x808e6ac] /usr/lib/libapr-1.so.0[0xb7d77e8e] /lib/libpthread.so.0[0xb7d0419b] /lib/libc.so.6(clone+0x5e)[0xb7c8886e] I have to restart Apache. -- Edit this bug report at http://bugs.php.net/?id=48134&edit=1
#44872 [Com]: canary mismatch on efree() - heap overflow detected
ID: 44872
Comment by: ewilded at gmail dot com
Reported By: mattr at shoplet dot com
Status: No Feedback
Bug Type: MySQLi related
Operating System: FreeBSD 6.2
PHP Version: 5.2.5
New Comment:
Same situation on PHP 5.2.9 with Suhosin-Patch 0.9.7 (cli) (built: May
2 2009 14:51:38), OS: Slackware 12, i'm connecting to Oracle DB on
remote machine using PDO, script gets killed while trying to execute
simple SELECT statement without any params (same code works fine with
MySQL).
Previous Comments:
[2009-04-21 14:39:12] fr33z at inmail dot cz
I have the same issue with PHP Version 5.2.9-pl2-gentoo
'./configure' '--prefix=/usr/lib64/php5' '--host=x86_64-pc-linux-gnu'
'--mandir=/usr/lib64/php5/man' '--infodir=/usr/lib64/php5/info'
'--sysconfdir=/etc' '--cache-file=./config.cache' '--with-libdir=lib64'
'--with-pcre-regex=/usr' '--enable-maintainer-zts' '--disable-cli'
'--with-apxs2=/usr/sbin/apxs2'
'--with-config-file-path=/etc/php/apache2-php5'
'--with-config-file-scan-dir=/etc/php/apache2-php5/ext-active'
'--without-pear' '--disable-bcmath' '--with-bz2' '--disable-calendar'
'--with-curl' '--with-curlwrappers' '--disable-dbase' '--enable-exif'
'--without-fbsql' '--without-fdftk' '--enable-ftp' '--with-gettext'
'--without-gmp' '--disable-ipv6' '--disable-json' '--without-kerberos'
'--enable-mbstring' '--with-mcrypt' '--with-mhash' '--without-msql'
'--without-mssql' '--with-ncurses' '--with-openssl'
'--with-openssl-dir=/usr' '--disable-pcntl' '--without-pgsql'
'--without-pspell' '--without-recode' '--disable-shmop' '--without-snmp'
'--disable-soap' '--enable-sockets' '--without-sybase'
'--without-sybase-ct' '--disable-sysvmsg' '--disable-sysvsem'
'--disable-sysvshm' '--without-tidy' '--disable-wddx' '--without-xmlrpc'
'--with-xsl' '--enable-zip' '--with-zlib' '--disable-debug'
'--enable-dba' '--without-cdb' '--with-db4' '--disable-flatfile'
'--with-gdbm' '--without-qdbm' '--with-freetype-dir=/usr'
'--with-t1lib=/usr' '--disable-gd-jis-conv' '--with-jpeg-dir=/usr'
'--with-png-dir=/usr' '--without-xpm-dir' '--with-gd'
'--with-mysql=/usr' '--with-mysql-sock=/var/run/mysqld/mysqld.sock'
'--without-mysqli' '--without-pdo-dblib' '--with-pdo-mysql=/usr'
'--without-pdo-odbc' '--without-pdo-pgsql' '--without-pdo-sqlite'
'--with-readline' '--without-libedit' '--without-mm' '--without-sqlite'
'--with-pic'
[2009-03-22 19:38:40] mr dot jony at gmail dot com
i have this same problem in a fresh install of ubuntu 8.04 lts
and i dont have the suhosin patch
please help
[2009-03-11 09:17:40] dballance at roydshall dot org
I have the same error when running certain queries with mssql_query().
There seems to be no way to predict which queries will run and which
fail - although if a query fails it always fails and if it runs then it
alway runs. The more complex the query, the more likely to fail.
I am running PHP Version 5.2.4-2ubuntu5.5 with Suhosin Patch 0.9.6.2.
Example code that trips the switch:
$dbhandle = mssql_connect($myServer, $myUser, $myPass);
$selected = mssql_select_db($myDB, $dbhandle);
$query = "SELECT * FROM sims.curr_group INNER JOIN
sims.curr_class_period ON sims.curr_group.base_group_id =
sims.curr_class_period.base_group_id INNER JOIN sims.sims_person ON
sims.sims_person.person_id = sims.curr_class_period.person_id
WHERE (sims.curr_group.short_name = '9b/It1')";
$result = mssql_query($query);
while($row = mssql_fetch_array($result)) {
print_r($row);
}
//close the connection
mssql_close($dbhandle);
[2008-10-10 09:50:38] krister dot karlstrom at arcada dot fi
I'm experiencing the same bug using PHP 5.2.4-2ubuntu5.3 with
Suhosin-Patch 0.9.6.2 (cli) on a Ubuntu Hardy 8.0.4 server.
The following simplified example shows the problem, the last echo row
is not executed because of mssql_free_result() fails:
up_nr."\n";
mssql_free_result($result);
}
}
}
echo "Here I am - NOT!";
?>
OUTPUT
==
201000
ALERT - canary mismatch on efree() - heap overflow detected (attacker
'REMOTE_ADDR not set', file '/var/www//TestMsSQL.php', line 16)
[2008-09-30 11:39:29] donald at designknights dot com
php version = 5.2.4-2ubuntu5.3
I am getting this same problem with the following bit of code
//class I wrote to make doing things on a remote machine easier
$ssh->init($server, $port, $username, $password);
$command = "if [ -d '$path' ]; then echo \"true\"; else echo \"false\";
fi 2> /dev/null";
//this executes the command above on the remote and gather
#42489 [Asn->Opn]: Quirk in strtotime using 'next' relative keyword
ID: 42489 Updated by: der...@php.net Reported By: chet at somedec dot com -Status: Assigned +Status: Open Bug Type: Date/time related Operating System: * PHP Version: 5.2CVS-2008-10-24 Assigned To: derick 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. This is fixed for PHP 5.3, I get the correct output: Today is Sunday Next Sunday is 2009-05-10T00:00:00+02:00 PASSNext Sunday + 0 weeks is 2009-05-10T00:00:00+02:00 PASSNext Sunday + 1 week is 2009-05-17T00:00:00+02:00 PASSNext Sunday + 0 minutes is 2009-05-10T00:00:00+02:00 PASSNext Sunday + 1 minute is 2009-05-10T00:01:00+02:00 Previous Comments: [2008-10-24 16:15:15] j...@php.net Still fails. [2008-05-13 03:38:34] toby dot matejovsky at gmail dot com The same problem occurs on PHP 5.2.5 on Mac OS 10.5. [2007-09-03 10:50:31] j...@php.net Assigned to the ext/date maintainer. :) [2007-08-30 15:50:24] chet at somedec dot com Description: Adding time (even zero) to a relative date using the "next" keyword fails. Reproduce code: --- Expected result: The four tests should pass; none do. Actual result: -- Using the current day (according to your computer clock) in conjunction with the next keyword (i.e. "Next Thursday" when run on Thursday) correctly returns one week from the current date. However, adding or subtracting any amount of time results in an erroneous result of the /current date/ plus or minus the offset. -- Edit this bug report at http://bugs.php.net/?id=42489&edit=1
#42489 [Opn->Csd]: Quirk in strtotime using 'next' relative keyword
ID: 42489 Updated by: der...@php.net Reported By: chet at somedec dot com -Status: Open +Status: Closed Bug Type: Date/time related Operating System: * PHP Version: 5.2CVS-2008-10-24 Assigned To: derick Previous Comments: [2009-05-03 14:08:23] der...@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. This is fixed for PHP 5.3, I get the correct output: Today is Sunday Next Sunday is 2009-05-10T00:00:00+02:00 PASSNext Sunday + 0 weeks is 2009-05-10T00:00:00+02:00 PASSNext Sunday + 1 week is 2009-05-17T00:00:00+02:00 PASSNext Sunday + 0 minutes is 2009-05-10T00:00:00+02:00 PASSNext Sunday + 1 minute is 2009-05-10T00:01:00+02:00 [2008-10-24 16:15:15] j...@php.net Still fails. [2008-05-13 03:38:34] toby dot matejovsky at gmail dot com The same problem occurs on PHP 5.2.5 on Mac OS 10.5. [2007-09-03 10:50:31] j...@php.net Assigned to the ext/date maintainer. :) [2007-08-30 15:50:24] chet at somedec dot com Description: Adding time (even zero) to a relative date using the "next" keyword fails. Reproduce code: --- Expected result: The four tests should pass; none do. Actual result: -- Using the current day (according to your computer clock) in conjunction with the next keyword (i.e. "Next Thursday" when run on Thursday) correctly returns one week from the current date. However, adding or subtracting any amount of time results in an erroneous result of the /current date/ plus or minus the offset. -- Edit this bug report at http://bugs.php.net/?id=42489&edit=1
#48136 [NEW]: session id = empty string produces warning
From: dont dot want at spam dot no Operating system: Win XP SP2 PHP version: 5.2.9 PHP Bug Type: Session related Bug description: session id = empty string produces warning Description: If session cookie is an empty string, PHP gives the following warning: "Warning: session_start() [function.session-start]: The session id contains illegal characters, valid characters are a-z, A-Z, 0-9 and '-,'". Worst case scenario: If the user sets the session id to an empty string manually in their browser and php errors are displayed, the page will break (could not start session, headers already sent by warning message, etc.). Normal scenario: display_errors is disabled, so this will only clutter the error log with an unnecessary warning. In my case I have session.use_only_cookies enabled and I work around the issue with the following code: Reproduce code: --- I used jQuery with a cookie addon to set the cookie to an empty string (was actually trying to delete the cookie), but the same could be simulated with the following 2 lines of PHP: You also get the same using GET (eg. "localhost/index.php?PHPSESSID=", remember to delete any old cookies before trying this or it won't work) Expected result: No warning since session ID is empty and PHP should be smart enough to realise that this means that the session id has not been generated yet. Actual result: -- Warning: session_start() [function.session-start]: The session id contains illegal characters, valid characters are a-z, A-Z, 0-9 and '-,' in F:\htdocs\index.php on line 9 -- Edit bug report at http://bugs.php.net/?id=48136&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48136&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48136&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48136&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48136&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48136&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48136&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48136&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48136&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48136&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48136&r=support Expected behavior: http://bugs.php.net/fix.php?id=48136&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48136&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48136&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48136&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48136&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48136&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48136&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48136&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48136&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48136&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48136&r=mysqlcfg
#48097 [Asn->Bgs]: date_timezone_set function produces wrong datetime result
ID: 48097
Updated by: der...@php.net
Reported By: energie at eox dot hu
-Status: Assigned
+Status: Bogus
Bug Type: Date/time related
Operating System: *
PHP Version: 5.2.9
Assigned To: derick
New Comment:
This is not a bug, the following happens:
date_create() creates a timezone agnostic date (only with a UTC
offset). Once you set the timezone to Europe/Budapest, it uses the Unix
timestamp contained in the DateTIme object (-461124000) and converts
that to a date/time representation for the Europe/Budapest timezone.
However, at this timestamp (1955-05-22T22:00:00 UTC) the UTC offset in
Budapest is only +1 (as it only becomes +2 an hour later at
1955-05-22T23:00:00 UTC). Because the UTC-offset is only 1, and not 2,
the correct offset is indeed UTC+1 which makes the time "23:00:00" in
Budapest.
The differences that you are seeing for those 3 years is because in
those 3 years, the DST switch from UTC+1 to UTC+2 makes 00:00:00 not
exist for those days, as the time goes from 23:59:59 directly to
01:00:00.
Previous Comments:
[2009-04-28 09:02:24] energie at eox dot hu
Description:
Result of "date_create" with timezon given:
"Mon, 23 May 1955 00:00:00 +0200"
After calling "date_timezone_set" for this date the expected result
would be the same but instead the result is:
"Mon, 23 May 1955 01:00:00 +0200"
In case of "Europe/Budapest" timezone 3 dates are affected between
1900.01.01 and 1999.12.31:
[0] => Sun, 23 May 1954 00:00:00 +0200
[0] => Mon, 23 May 1955 00:00:00 +0200
[0] => Sun, 03 Jun 1956 00:00:00 +0200
There are timezones where everything works fine, and many ohters that
have date inputs that cause this mis-calculation. Thers is no relation
between the dates in different timezones but the wrong dates are always
the same in a given timezone, so there are no "random" errors.
Reproduce code:
---
$errors = array();
$timezones = array('Europe/Budapest');
// Uncomment the following line to run on all timezones
// $timezones = timezone_identifiers_list();
function generate_dates($timezone) {
$dates = array();
for($y = 1900; $y <= 1999; $y++) {
for($m = 1; $m <= 12; $m++) {
for($d = 1; $d <= 31; $d++) {
$date = date_create(sprintf('%s-%s-%s 00:00:00', $y, $m, $d),
timezone_open($timezone));
if ($date) {
$dates[] = $date;
}
}
}
}
return $dates;
}
foreach($timezones as $timezone) {
$dates = generate_dates($timezone);
foreach($dates as $date) {
$test = date_format($date, 'r');
date_timezone_set($date, timezone_open($timezone));
if ($test != date_format($date, 'r')) {
$errors[$timezone][] = array($test, date_format($date, 'r'));
}
}
print('Timezone: '. $timezone . ', errors: '.
count($errors[$timezone]) . "\n");
// Uncomment the following line to display all dates that calculated
"wrong"
// print_r($errors[$timezone]);
// print "\n";
}
Expected result:
Timezone: Europe/Budapest, errors: 0
Actual result:
--
Timezone: Europe/Budapest, errors: 3
--
Edit this bug report at http://bugs.php.net/?id=48097&edit=1
#46417 [Asn->Fbk]: getdate returns "unknown" for higher negative values
ID: 46417
Updated by: der...@php.net
Reported By: sanjay dot mantoor at gmail dot com
-Status: Assigned
+Status: Feedback
Bug Type: Date/time related
Operating System: * (64bit)
PHP Version: 5CVS-2008-10-29 (snap)
Assigned To: derick
New Comment:
I found the bug, and have a fix... but was wondering why you think it
should be a Monday. I calculate it as a Wednesday.
Previous Comments:
[2008-10-30 07:26:13] sanjay dot mantoor at gmail dot com
Please download tests from
http://www.4shared.com/file/68976901/6ce81c88/getdate.html
To recreate this bug, run following tests
PHP53/getdate_variation7.phpt
PHP6/getdate_variation7.phpt
[2008-10-29 10:18:01] sanjay dot mantoor at gmail dot com
Description:
getdate function returns wrong "weekday" for higher negative timestamps
like -12.3456789000e10. This is observed on linux 64 bit with both
php5.2 and php5.3 release.
As per documentation "weekday" should be "Sunday through Saturday".
But in this case it returns "Unknown" value.
Checked with php version
PHP 5.3.0alpha3-dev (cli) (built: Oct 29 2008 15:20:01)
Reproduce code:
---
Expected result:
array(11) {
["seconds"]=>
int(20)
["minutes"]=>
int(23)
["hours"]=>
int(5)
["mday"]=>
int(23)
["wday"]=>
int(-4)
["mon"]=>
int(10)
["year"]=>
int(-1943)
["yday"]=>
int(295)
["weekday"]=>
string(7) "Monday"
["month"]=>
string(7) "October"
[0]=>
int(-123456789000)
}
Actual result:
--
array(11) {
["seconds"]=>
int(20)
["minutes"]=>
int(23)
["hours"]=>
int(5)
["mday"]=>
int(23)
["wday"]=>
int(-4)
["mon"]=>
int(10)
["year"]=>
int(-1943)
["yday"]=>
int(295)
["weekday"]=>
string(7) "Unknown"
["month"]=>
string(7) "October"
[0]=>
int(-123456789000)
}
--
Edit this bug report at http://bugs.php.net/?id=46417&edit=1
#41712 [Asn->Csd]: [PATCH] Add CURL Progress Function Callback
ID: 41712 Updated by: paj...@php.net Reported By: sdteffen at gmail dot com -Status: Assigned +Status: Closed Bug Type: Feature/Change Request Operating System: SuSE Linux 10.2 PHP Version: 5CVS-2007-06-16 (CVS) Assigned To: pajoye 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. Applied with a leak fix to 5.3 and 6.0 Previous Comments: [2009-04-28 20:23:47] paj...@php.net Thanks for the update. The PHP part looks and the curl as well (thx to cURL's Daniel for the quick review). I will test and apply it this week. [2009-04-28 20:05:49] sdteffen at gmail dot com Thanks for responding to this issue. I've updated and tested the patch once more with the PHP_5_3 sources from CVS today: http://sdteffen.de/php/php_curl_progress_callback.patch The test script is the same as mentioned under "Reproduce code", but I've added an explanatory comment to the version on my website: http://sdteffen.de/php/index_en.html [2009-04-28 18:10:56] paj...@php.net Did you test your with 5.3? If not can you post a URL to an updated patch with a test script please? It can still make it this week for 5.3+. [2009-04-28 15:09:26] frase at cs dot wisc dot edu What happened here? A patch was offered for this feature almost two years ago, and was assigned to the maintainer a week later. The next six months saw some tweaks and corrections, and yet here we are two years later with this still languishing in "assigned" limbo, neither accepted and merged nor rejected and closed. Ilia? Tony? Bueller? [2009-02-20 09:27:43] php41712 at brainpower dot no-ip dot org can somewone submit this to the php code as this will help a lot of users 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/41712 -- Edit this bug report at http://bugs.php.net/?id=41712&edit=1
#47717 [Opn->Bgs]: Curl error: malformed
ID: 47717 Updated by: paj...@php.net Reported By: ray_kimsey at ncsu dot edu -Status: Open +Status: Bogus Bug Type: cURL related Operating System: RHEL 5.3 PHP Version: 5.2CVS-2009-03-18 -Assigned To: +Assigned To: pajoye New Comment: Cannot reproduce, in php or in c using cURL directly. Sounds like a network issue not a php one > bogus. Previous Comments: [2009-04-01 13:05:41] ray_kimsey at ncsu dot edu I tested on two separate servers with the same results. Both machines were are on the same network. Thank you for your assistance. [2009-04-01 12:34:19] paj...@php.net It works here. Maybe some invalid redirect from one of your box? Did you try this script from the same machine or network? 5.3.0-cvs, 5.2.9-1 and 5.2-cvs with curl 7.19.4: * About to connect() to www.google.com port 80 (#0) * Trying 74.125.39.99... * connected * Connected to www.google.com (74.125.39.99) port 80 (#0) > GET / HTTP/1.1 Host: www.google.com Accept: */* < HTTP/1.1 302 Found < Location: http://www.google.de/ < Cache-Control: private < Content-Type: text/html; charset=UTF-8 < Server: GoogleOS 1.0 < Set-Cookie: PREF=ID=4a339d976374a632:TM=1238589105:LM=1238589105:S=7pLUEtWGxnkHF5G4; expires=Fri, 01-Apr-2011 12:31:45 GMT; path=/; domain=.google.com < Date: Wed, 01 Apr 2009 12:31:45 GMT < Content-Length: 218 < * Connection #0 to host www.google.com left intact * Closing connection #0 [2009-04-01 12:03:20] ray_kimsey at ncsu dot edu Yes, that is correct. [2009-04-01 12:00:22] paj...@php.net Summary: 5.2.9 + 7.19.4, x64, fails. 5.2.6 + 7.19.4, x64, works. snaps 5.2-20090318153 + 7.19.4 x64, fails. snaps 5.2-20090318153 + 7.15.5 x64, works. Do I get it right? [2009-04-01 11:58:34] ray_kimsey at ncsu dot edu Well PHP 5.2.6 works with older and newer versions of Curl. (see orignal description of problem). There appears to be something that was implemented in newer versions of PHP (later than 5.2.6) that is causing a problem. My guess would be something new (such as COPYPOSTFIELDS) implemented in recent versions of Curl that newer versions of PHP are trying to use. 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/47717 -- Edit this bug report at http://bugs.php.net/?id=47717&edit=1
#48137 [NEW]: assigning array element reference appears to modify array
From: mike at clove dot com
Operating system: Mac OS X 10.5.6
PHP version: 5.2.9
PHP Bug Type: Arrays related
Bug description: assigning array element reference appears to modify array
Description:
Assigning reference to an array element appears to modify the
array element rather than simply creating a reference to it.
This is surprising, to say the least.
At least I think this is a bug and couldn't find anything with the same
behavior and such minimal code.
Reproduce code:
---
$a = array(1,2);
$r =& $a[0];
var_dump($a);
Expected result:
array(2) {
[0]=>
int(1)
[1]=>
int(2)
}
Actual result:
--
array(2) {
[0]=>
&int(1)
[1]=>
int(2)
}
--
Edit bug report at http://bugs.php.net/?id=48137&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48137&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48137&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48137&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48137&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48137&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48137&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48137&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48137&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48137&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48137&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48137&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48137&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48137&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48137&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48137&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48137&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48137&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48137&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48137&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48137&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48137&r=mysqlcfg
#48137 [Opn->Bgs]: assigning array element reference appears to modify array
ID: 48137
Updated by: der...@php.net
Reported By: mike at clove dot com
-Status: Open
+Status: Bogus
Bug Type: Arrays related
Operating System: Mac OS X 10.5.6
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
Nah, this is fine. It doesn't modify the array. The & just shows that
the is_ref bit on the zval container that contains the int(1) value is
set.
Previous Comments:
[2009-05-03 17:01:04] mike at clove dot com
Description:
Assigning reference to an array element appears to modify the
array element rather than simply creating a reference to it.
This is surprising, to say the least.
At least I think this is a bug and couldn't find anything with the same
behavior and such minimal code.
Reproduce code:
---
$a = array(1,2);
$r =& $a[0];
var_dump($a);
Expected result:
array(2) {
[0]=>
int(1)
[1]=>
int(2)
}
Actual result:
--
array(2) {
[0]=>
&int(1)
[1]=>
int(2)
}
--
Edit this bug report at http://bugs.php.net/?id=48137&edit=1
#46289 [Com]: PDO execute causes apache.exe to crash
ID: 46289
Comment by: oddvibes at gmail dot com
Reported By: asylow at free dot fr
Status: Open
Bug Type: PDO related
Operating System: Windows XP SP3
PHP Version: 5.2.9
New Comment:
I'm having the same issue on Windows Vista. The following Windows crash
information might be useful:
Windows error-reporting creates the following error-messages:
Faulting application apache.exe, version 2.2.11.0, time stamp
0x493f5d44, faulting module php_pdo_mysql.dll, version 5.2.8.8, time
stamp 0x493d7650, exception code 0xc005, fault offset 0x250a,
process id 0xf10, application start time 0x01c9c677df857f87.
And:
Faulting application apache.exe, version 2.2.11.0, time stamp
0x493f5d44, faulting module ntdll.dll, version 6.0.6001.18000, time
stamp 0x4791a7a6, exception code 0xc005, fault offset 0x0006814c,
process id 0x10d8, application start time 0x01c9c677ded2aa47.
And after that, the following information:
Fault bucket 1062083465, type 1
Event Name: APPCRASH
Response: None
Cab Id: 0
Problem signature:
P1: apache.exe
P2: 2.2.11.0
P3: 493f5d44
P4: php_pdo_mysql.dll
P5: 5.2.8.8
P6: 493d7650
P7: c005
P8: 250a
P9:
P10:
Attached files:
C:\ProgramData\Microsoft\Windows\WER\ReportQueue\Report09c3bd88\WERAF65.tmp.version.txt
C:\ProgramData\Microsoft\Windows\WER\ReportQueue\Report09c3bd88\WERAF66.tmp.appcompat.txt
C:\ProgramData\Microsoft\Windows\WER\ReportQueue\Report09c3bd88\WERAFC4.tmp.hdmp
C:\ProgramData\Microsoft\Windows\WER\ReportQueue\Report09c3bd88\WERBC91.tmp.mdmp
These files may be available here:
C:\ProgramData\Microsoft\Windows\WER\ReportArchive\Report0cdbcec7
Specs:
* Windows Vista Home Edition
* Apache 2.2
* MySQL 5.1.30
* PHP 5.2.8
Previous Comments:
[2009-02-20 03:23:12] michael dot cordover+php at gmail dot com
I also get this issue on WinXP SP2 (5.1 build 2600) running Apache
2.2.11.0 (from xampplite 1.7.0).
Interestingly this occurs with executing a PDO::prepare()d SELECT
statement but not on UPDATE or INSERT. This happens even when
PDOStatement::bindValue / bindParam is not used.
I cannot reproduce the "subtle change makes it work" described by
asylow.
I am unable to provide a backtrace.
--Code--
$dbConn = new PDO(DBDSN, DBUSER, DBPASS);
// Connection is definitely valid
$q = $dbConn->prepare('SELECT * FROM people');
$q->execute();
--Crash report--
AppName: apache.exe
AppVer: 2.2.11.0
ModName: php_pdo_mysql.dll
ModVer: 5.2.9.9
Offset: 249a
--PHP Version-- [per phpinfo()]
Was occurring on 5.2.8 and also on snapshot:
PHP Version 5.2.9RC3-dev
System Windows NT 18315XP 5.1 build 2600
Build Date Feb 18 2009 23:39:16
Configure Command cscript /nologo configure.js
"--enable-snapshot-build" "--enable-debug-pack"
"--with-snapshot-template=d:\php-sdk\bin\\..\snap_5_2\vc6\x86\template"
"--with-php-build=d:\php-sdk\bin\\..\snap_5_2\vc6\x86\php_build"
"--with-pdo-oci=D:\php-sdk\oracle\instantclient10\sdk,shared"
"--with-oci8=D:\php-sdk\oracle\instantclient10\sdk,shared"
--PDO Version-- [per phpinfo()]
pdo_mysql PDO Driver for MySQL, client library version 5.1.30
--MySQL Version--
C:\xampplite\mysql\bin>mysqld.exe --version
mysqld.exe Ver 5.1.30-community for Win32 on ia32 (MySQL Community
Server (GPL))
[2008-10-14 13:13:30] asylow at free dot fr
The same happens with PHP Version 5.2.7RC2-dev - Oct 14 2008 01:38:31
The Call Stack debug is :
PHP5TS! 0096c9a3()
PHP5TS! 0096d28b()
free_statement(_pdo_stmt_t * 0x062d21d0, void * * * 0x01ec7d58) line
2396 + 19 bytes
php_pdo_stmt_delref(_pdo_stmt_t * 0x062d21d0, void * * * 0x01ec7d58)
line 2426 + 13 bytes
pdo_dbstmt_free_storage(_pdo_stmt_t * 0x062d21d0, void * * *
0x01ec7d58) line 2432 + 13 bytes
PHP5TS! 009f3253()
PHP5TS! 009f3061()
PHP5TS! 009ff42d()
PHP5TS! 009d75df()
PHP5TS! 009d6d59()
PHP5TS! 009dc53c()
PHP5TS! 00982176()
PHP5TS! 00981a4f()
PHP5TS! 009819a0()
PHP5TS! 00963651()
PHP5TS! 00a06b2d()
PHP5APACHE2! 003e34fd()
LIBHTTPD! 6ff0268e()
LIBHTTPD! 6ff02b6e()
LIBHTTPD! 6ff138a0()
LIBHTTPD! 6ff0e317()
LIBHTTPD! 6ff060fe()
LIBHTTPD! 6ff064ec()
LIBHTTPD! 6ff27e4c()
MSVCR71! 7c349565()
KERNEL32! 7c80b713()
[2008-10-14 09:39:38] asylow at free dot fr
Description:
Hi,
I get an apache crash when executing the "execute" on a prepared
query.
"L'instruction à "0x0096ac76" emploie l'adresse mémoire "0X07a0a410".
La mémoire ne peut pas être "read"
PHP 5.2.6
Apache 2.2.9
The problem also happened using Aug 06, 2008 04:30 UTC Snapshot.
Reproduce code:
---
The minimal code that causes the crash is :
db = new PDO
("mssql:host=localhost\SQLEXPRESS;dbname=test","sa","toto");
}
function foo() {
#45822 [Asn->Csd]: Invalid value passed to strtotime() causes endless loop
ID: 45822
Updated by: der...@php.net
Reported By: matt at neimeyer dot org
-Status: Assigned
+Status: Closed
Bug Type: Date/time related
Operating System: *
PHP Version: 5.2CVS, 5.3CVS, 6CVS (2008-08-14)
Assigned To: derick
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:
[2008-12-22 14:18:21] for-bugs at hnw dot jp
As well as other comments, php -r 'strtotime("2008010100 Sunday");'
never ends on PHP 5.2.8 and 5.3.0alpha3.
[2008-08-20 19:24:53] krimpet at toolserver dot org
I can confirm this bug, and it's not limited to Windows platforms. 'php
-r "strtotime('+1 days');"' crashes my Linux laptop, for
example.
This bug is particularly dire where user input is fed to directly to
strtotime(), as it poses a DoS risk - for example, we use strtotime() in
MediaWiki to format times specified by the user. (See
.)
[2008-08-14 17:50:50] j...@php.net
It hangs in this loop:
#1 0x004a7f5b in do_normalize (time=0x7bf1ed0) at
/home/jani/php-5.3CVS/ext/date/lib/tm2unixtime.c:166
166 do {} while (do_range_limit_days(&time->y, &time->m,
&time->d));
[2008-08-14 17:41:19] amelek32 at gmail dot com
http://bugs.php.net/?id=45822&edit=1
#48058 [Asn->Opn]: DateTimeZone::getTransitions output different on 64 bit
ID: 48058
Updated by: der...@php.net
Reported By: wharmby at uk dot ibm dot com
-Status: Assigned
+Status: Open
Bug Type: Date/time related
Operating System: Linux 64 bit
PHP Version: 5.3, 6CVS (2009-04-30)
Assigned To: derick
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.
Well, there is a possibility that transitions from before 1901 might be
added to the database, so I don't just want to stop that from working.
Also, I fixed the formatting bug for the year value in CVS now.
Previous Comments:
[2009-04-24 08:25:33] wharmby at uk dot ibm dot com
Hi Derick
Thanks for atking a look at this. I can see why we end up with the
bogus looking entry given that "timestamp_begin" is initialized to
LONG_MIN its just that the output is not what I expected to see and I
believe it will confuse other users who are perhaps not aware of how the
results array is being built. Also given that the remaining entries in
the array are the same and we don't produce more transitions (going
further into past) on 64 bit would it not make more sense to initialize
timestamp_begin to -2147483648 regardless of platform rather than using
LON_MIN ? I realize this is a minor issue and there are probably more
important issues that need your attention but I do believe the current
output will confuse someone some day
Regards
Andy
[2009-04-23 12:35:30] der...@php.net
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.
[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
#48058 [Opn->Csd]: 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: Closed
Bug Type: Date/time related
Operating System: Linux 64 bit
PHP Version: 5.3, 6CVS (2009-04-30)
Assigned To: derick
Previous Comments:
[2009-05-03 18:24:35] der...@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.
Well, there is a possibility that transitions from before 1901 might be
added to the database, so I don't just want to stop that from working.
Also, I fixed the formatting bug for the year value in CVS now.
[2009-04-24 08:25:33] wharmby at uk dot ibm dot com
Hi Derick
Thanks for atking a look at this. I can see why we end up with the
bogus looking entry given that "timestamp_begin" is initialized to
LONG_MIN its just that the output is not what I expected to see and I
believe it will confuse other users who are perhaps not aware of how the
results array is being built. Also given that the remaining entries in
the array are the same and we don't produce more transitions (going
further into past) on 64 bit would it not make more sense to initialize
timestamp_begin to -2147483648 regardless of platform rather than using
LON_MIN ? I realize this is a minor issue and there are probably more
important issues that need your attention but I do believe the current
output will confuse someone some day
Regards
Andy
[2009-04-23 12:35:30] der...@php.net
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.
[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
#45682 [Asn->Csd]: Unable to var_dump(DateInterval)
ID: 45682 Updated by: der...@php.net Reported By: hannes dot magnusson at gmail dot com -Status: Assigned +Status: Closed Bug Type: Date/time related Operating System: * PHP Version: 5.3CVS-2008-11-11 Assigned To: derick 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: [2008-08-01 19:15:35] hannes dot magnusson at gmail dot com Description: The DateInterval does not seem to expose its properties to var_dump().. Reproduce code: --- bj...@lohan:~$ cat test.php http://bugs.php.net/?id=45682&edit=1
#45409 [Asn->Csd]: strtotime() very slow when operating on timestamp
ID: 45409
Updated by: der...@php.net
Reported By: jerico dot dev at gmail dot com
-Status: Assigned
+Status: Closed
Bug Type: Date/time related
Operating System: *
PHP Version: 5.*, 6CVS (2008-12-09)
Assigned To: derick
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.
This seems to be a duplicate of bug #48522, which is now fixed in CVS.
I now get the following result with your original code.
0.47
0.79
Previous Comments:
[2009-02-04 13:47:36] php at wallbash dot com
Hi,
i hope i don't bug you but do you know when this might get fixed or is
there a patch available ? We (finally) moved to 5.2 and this is a
showstopper for us and would (sadly) require lots of refactoring.
Thanks
[2008-07-01 21:30:28] der...@php.net
I'll have a look at this, but there is even a MUCH faster way:
modify( '+1 year' );
$mt1 = microtime(true);
$d->modify( '+1 year' );
$mt2 = microtime(true);
printf("%.6f\r\n%.6f\r\n", $mt1-$mt0, $mt2-$mt1);
?>
0.013312/0.696215 for your code, vs 0.65/0.28 for my approach.
[2008-07-01 20:55:08] jerico dot dev at gmail dot com
Description:
strtotime() performs 3 orders of magnitude slower when operating on a
timestamp.
Reproduce code:
---
$string = '1902-03-25 18:25:25';
$timestamp = strtotime($string);
$mt0 = microtime(true);
$result1 = strtotime("$string +1 year");
$mt1 = microtime(true);
$result2 = strtotime("+1 year", $timestamp);
$mt2 = microtime(true);
printf("%.6f\r\n%.6f\r\n", $mt1-$mt0, $mt2-$mt1);
// This will output
// 0.000171
// 0.721877
// on my machine
Actual result:
--
see reproduce code
--
Edit this bug report at http://bugs.php.net/?id=45409&edit=1
#46289 [Com]: PDO execute causes apache.exe to crash
ID: 46289
Comment by: oddvibes at gmail dot com
Reported By: asylow at free dot fr
Status: Open
Bug Type: PDO related
Operating System: Windows XP SP3
PHP Version: 5.2.9
New Comment:
I fixed this problem on my computer. In my case it seems to have to do
something with the Xammp installation. It probably would be interesting
to know if the other people who were experiencing this problem were also
running on xammp.
I found this sollution by searching the web and found it on the
Magento-forum:
http://www.magentocommerce.com/boards/viewthread/31789/
The solution is simple:
- Download:
http://windows.php.net/downloads/snaps/php-5.2-win32-VC6-x86-latest.zip
- Unzip & copy libmysql.dll into xampp\apache\bin & xampp\php.
- Restart apache.
Previous Comments:
[2009-05-03 17:43:26] oddvibes at gmail dot com
I'm having the same issue on Windows Vista. The following Windows crash
information might be useful:
Windows error-reporting creates the following error-messages:
Faulting application apache.exe, version 2.2.11.0, time stamp
0x493f5d44, faulting module php_pdo_mysql.dll, version 5.2.8.8, time
stamp 0x493d7650, exception code 0xc005, fault offset 0x250a,
process id 0xf10, application start time 0x01c9c677df857f87.
And:
Faulting application apache.exe, version 2.2.11.0, time stamp
0x493f5d44, faulting module ntdll.dll, version 6.0.6001.18000, time
stamp 0x4791a7a6, exception code 0xc005, fault offset 0x0006814c,
process id 0x10d8, application start time 0x01c9c677ded2aa47.
And after that, the following information:
Fault bucket 1062083465, type 1
Event Name: APPCRASH
Response: None
Cab Id: 0
Problem signature:
P1: apache.exe
P2: 2.2.11.0
P3: 493f5d44
P4: php_pdo_mysql.dll
P5: 5.2.8.8
P6: 493d7650
P7: c005
P8: 250a
P9:
P10:
Attached files:
C:\ProgramData\Microsoft\Windows\WER\ReportQueue\Report09c3bd88\WERAF65.tmp.version.txt
C:\ProgramData\Microsoft\Windows\WER\ReportQueue\Report09c3bd88\WERAF66.tmp.appcompat.txt
C:\ProgramData\Microsoft\Windows\WER\ReportQueue\Report09c3bd88\WERAFC4.tmp.hdmp
C:\ProgramData\Microsoft\Windows\WER\ReportQueue\Report09c3bd88\WERBC91.tmp.mdmp
These files may be available here:
C:\ProgramData\Microsoft\Windows\WER\ReportArchive\Report0cdbcec7
Specs:
* Windows Vista Home Edition
* Apache 2.2
* MySQL 5.1.30
* PHP 5.2.8
[2009-02-20 03:23:12] michael dot cordover+php at gmail dot com
I also get this issue on WinXP SP2 (5.1 build 2600) running Apache
2.2.11.0 (from xampplite 1.7.0).
Interestingly this occurs with executing a PDO::prepare()d SELECT
statement but not on UPDATE or INSERT. This happens even when
PDOStatement::bindValue / bindParam is not used.
I cannot reproduce the "subtle change makes it work" described by
asylow.
I am unable to provide a backtrace.
--Code--
$dbConn = new PDO(DBDSN, DBUSER, DBPASS);
// Connection is definitely valid
$q = $dbConn->prepare('SELECT * FROM people');
$q->execute();
--Crash report--
AppName: apache.exe
AppVer: 2.2.11.0
ModName: php_pdo_mysql.dll
ModVer: 5.2.9.9
Offset: 249a
--PHP Version-- [per phpinfo()]
Was occurring on 5.2.8 and also on snapshot:
PHP Version 5.2.9RC3-dev
System Windows NT 18315XP 5.1 build 2600
Build Date Feb 18 2009 23:39:16
Configure Command cscript /nologo configure.js
"--enable-snapshot-build" "--enable-debug-pack"
"--with-snapshot-template=d:\php-sdk\bin\\..\snap_5_2\vc6\x86\template"
"--with-php-build=d:\php-sdk\bin\\..\snap_5_2\vc6\x86\php_build"
"--with-pdo-oci=D:\php-sdk\oracle\instantclient10\sdk,shared"
"--with-oci8=D:\php-sdk\oracle\instantclient10\sdk,shared"
--PDO Version-- [per phpinfo()]
pdo_mysql PDO Driver for MySQL, client library version 5.1.30
--MySQL Version--
C:\xampplite\mysql\bin>mysqld.exe --version
mysqld.exe Ver 5.1.30-community for Win32 on ia32 (MySQL Community
Server (GPL))
[2008-10-14 13:13:30] asylow at free dot fr
The same happens with PHP Version 5.2.7RC2-dev - Oct 14 2008 01:38:31
The Call Stack debug is :
PHP5TS! 0096c9a3()
PHP5TS! 0096d28b()
free_statement(_pdo_stmt_t * 0x062d21d0, void * * * 0x01ec7d58) line
2396 + 19 bytes
php_pdo_stmt_delref(_pdo_stmt_t * 0x062d21d0, void * * * 0x01ec7d58)
line 2426 + 13 bytes
pdo_dbstmt_free_storage(_pdo_stmt_t * 0x062d21d0, void * * *
0x01ec7d58) line 2432 + 13 bytes
PHP5TS! 009f3253()
PHP5TS! 009f3061()
PHP5TS! 009ff42d()
PHP5TS! 009d75df()
PHP5TS! 009d6d59()
PHP5TS! 009dc53c()
PHP5TS! 00982176()
PHP5TS! 00981a4f()
PHP5TS! 009819a0()
PHP5TS! 00963651()
PHP5TS! 00a06b2d()
PHP5APACHE2! 003e34fd()
LIBHTTPD! 6ff0268e()
LIBHTTPD! 6ff02b6e()
LIBHTTPD! 6ff138a0()
LIBHTTPD! 6ff0e317()
LIBHTTPD! 6ff060fe()
#45191 [Asn->Csd]: error_log ignores date.timezone php.ini val when setting logging timestamps
ID: 45191 Updated by: der...@php.net Reported By: info at organicdata dot co dot za -Status: Assigned +Status: Closed Bug Type: Date/time related Operating System: Centos el5 PHP Version: 5.2CVS-2008-06-05 (snap) Assigned To: derick 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: [2008-07-29 06:46:39] der...@php.net It should be switched from strftime() to php_format_date(). This is not an issue with the Date/Time functionality though, but with the syslog one. [2008-07-28 22:47:26] j...@php.net Derick, any comments? [2008-07-28 22:46:30] j...@php.net Actually error_log="somefile.log" does not use any syslog stuff to write the entries in it. This is the line from main.c:490 which gets executed if error_log != syslog: strftime(error_time_str, sizeof(error_time_str), "%d-%b-%Y %H:%M:%S", php_localtime_r(&error_time, &tmbuf)); There are 2 problems here: [a] it's using locale sensitive %b modifier [b] It doesn't care about date.timezone. Solutions: [a] IMO it should use this pattern instead: "%Y-%m-%d %H:%M:%S" (f.e. lighttpd uses this for it's error_log entries :) [b] I don't know how to safely achieve the above mentioned issues with date.timezone vs. system timezone. Might be better leave this as is.. [2008-07-15 17:05:49] info at organicdata dot co dot za Thanks very much for the feedback - I understand that my "bug" interpretation may have been wrong. My concern is really a result of a combination of the following: 1. the PHP recommendations I've seen is that you don't rely on system time zone and set the time zone explicitly in PHP 2. I want to have a single central logging file containing all system errors 3. The custom error handling routine I use does not catch all errors that PHP can throw, some are only captured by the internal error handler used by setting log_errors=On Because of 3, the only way I can achieve 2 that I can see is to set the output file in my custom error handler to be the same as the value set in the inifile parameter error_log. This means that the errors I trap are then inserted into the same file as the ones I am unable to trap due to the limitation of 3 and they occur in a sensible sequence. As per your reply however, the only way for me to ensure that the errors written to the file by my custom error handler have meaningful timestamps relative to the ones written as a result of the log_errors=On parameter means that i have to set my PHP explicit timezone to the same as that of the server. ...which means that I'm setting the value on the server and again in PHP and that if there is some change in the server timezone for whatever reason at a later stage, my log file will become "a mess" of inconsistent timestamps (depending on whether the error written to the file was as a result of my custom error handling routine or whether handled by the internal error logging. ...which in turn from my perspective means that it is in fact dangerous to explicitly set the PHP internal timezone and actually safer to allow everything to rely only on the system timezone - at least this way I can guarantee consistency in the timestamps of the errors written to the log file well that's the way I see it anyway - not sure whether I'm missing something big here thanks again for the feedback [2008-07-14 10:06:39] der...@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 This is normal. The error log is not *written* by PHP, but by syslog. Syslog doesn't care about PHP's internal timezone, and thus formats the log message according to the system timezone. Just change the system timezone if it's incorrect. 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/45191 -- Edit this bug report at http://bugs.php.net/?id=45191&edit=1
#47966 [Opn->Ver]: array Notice: Undefined index:
ID: 47966 Updated by: paj...@php.net Reported By: dba at csis dot dk -Status: Open +Status: Verified Bug Type: cURL related -Operating System: Windows XP SP3 +Operating System: * PHP Version: 6CVS-2009-04-14 (snap) New Comment: All OSes. Note that b"url" works, but even using add_assoc_string or add_assoc_utf8_string does not help. See the CAAS macro in interface.c Previous Comments: [2009-04-14 11:25:41] dba at csis dot dk correction on commented line 14: // Notice: Undefined index: url in D:\home\main\tools\test\index.php on line 14 [2009-04-14 11:23:20] dba at csis dot dk Description: can't call array from $curl_getinfo['xxx'] but will output on var_dump() and var_export() --- phpinfo() System Windows NT DBA-XP-UK 5.1 build 2600 (Windows XP Professional Service Pack 3) i586 Build Date Apr 14 2009 00:27:29 CompilerMSVC6 (Visual C++ 6.0) Server API Apache 2.0 Handler Apache Version Apache/2.2.11 (Win32) PHP/6.0.0-dev Reproduce code: --- http://www.php.net/";); curl_setopt($ch, CURLOPT_HEADER, true); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); $curl_data = curl_exec($ch); $curl_getinfo = curl_getinfo($ch); print "".var_export($curl_getinfo, true).""; print "curl_getinfo['url']: ".$curl_getinfo['url'].""; // Notice: Undefined index: url in D:\home\main\tools\test\index.php on line 19 curl_close($ch); ?> Expected result: output from var_export($curl_getinfo) AND output from print $curl_getinfo['url'] Actual result: -- only gets output from var_export($curl_getinfo)... -- Edit this bug report at http://bugs.php.net/?id=47966&edit=1
#47773 [Asn->Ver]: cURL multi crashes
ID: 47773
Updated by: paj...@php.net
Reported By: entpman at gmail dot com
-Status: Assigned
+Status: Verified
Bug Type: cURL related
Operating System: win32 only - WIN XP SP2
PHP Version: 5.2.9
Assigned To: pajoye
Previous Comments:
[2009-04-06 20:45:05] daniel at haxx dot se
I'm convinced this is a bug in libcurl, see this analysis by
Sergii Volchkov:
http://curl.haxx.se/mail/lib-2009-04/0028.html
(AFAIK, there is nobody working on a fix for this.)
[2009-03-25 15:29:52] entpman at gmail dot com
I tried version 5.3.0RC2-dev same results.
[2009-03-25 14:08:06] entpman at gmail dot com
Description:
The program will work fine for hundreds of downloads then suddenly
crashes.
Reproduce code:
---
'http://www.google.com'
),
array(
'url' => 'http://www.yahoo.com'
)
)
);
// of course more urls are needs
function downloadurls($downloads,$cookie = null){
$timeout = 30;
$mcurl = curl_multi_init();
$agent = "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12)
Gecko/2009201 Firefox/3.0.0.1";
foreach($downloads as $key=>$download){
$url = $download['url'];
$ch = curl_init();
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1);
curl_setopt($ch, CURLOPT_TIMEOUT, $timeout);
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER,0);
curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 15);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST,0);
curl_setopt($ch, CURLOPT_USERAGENT, $agent);
if(!empty($download['postdata'])){
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS,$download['postdata']);
}
if(!empty($cookie)){
@unlink($cookie);
//echo "added cookie\n";
curl_setopt($ch, CURLOPT_COOKIEFILE, $cookie);
curl_setopt($ch, CURLOPT_COOKIEJAR, $cookie);
}
if(!empty($download['proxy'])){
curl_setopt($ch, CURLOPT_PROXY, $download['proxy']);
}
curl_multi_add_handle($mcurl, $ch);
$downloads[$key]['handle'] = $ch;
}
do {
$n=curl_multi_exec($mcurl,$active);
usleep(100);
}
while ($active);
foreach($downloads as $key=>$download){
$ch = $download['handle'];
$done_content = curl_multi_getcontent($ch);
if(curl_errno($ch) == 0) {
$downloads[$key]['picture'] = $done_content;
} else {
exit('error');
}
curl_multi_remove_handle($mcurl, $ch);
curl_close($ch);
}
curl_multi_close($mcurl);
return $downloads;
}
?>
Actual result:
--
backtrace:
php_curl.dll!_Curl_llist_insert_next() + 0x48 bytes
php_curl.dll!_Curl_hash_add() + 0x74 bytes
php_curl.dll!_Curl_cache_addr() + 0x6d bytes
php_curl.dll!_Curl_addrinfo4_callback() + 0x82 bytes
php_curl.dll!_Curl_addrinfo4_callback() + 0x14 bytes
php_curl.dll!_Curl_getaddrinfo() + 0x317 bytes
msvcrt.dll!77c3a3b0()
[Frames below may be incorrect and/or missing, no symbols loaded for
msvcrt.dll]
kernel32.dll!7c80b683()
--
Edit this bug report at http://bugs.php.net/?id=47773&edit=1
#46439 [Opn->Tbd]: file upload implementation is flawed
ID: 46439
Updated by: paj...@php.net
Reported By: tom at punkave dot com
-Status: Open
+Status: To be documented
Bug Type: cURL related
Operating System: *
PHP Version: 5.*, 6CVS (2009-01-21)
New Comment:
tbd
Previous Comments:
[2009-01-21 20:08:07] tom at punkave dot com
htmlencode() won't escape @. Neither will htmlentities(). it's a
security bug that no amount of reasonable prudence on the part of
programmers who haven't read this particular bug report will address.
And there is no reason why programmers would expect that filtering input
would be necessary when they are passing individual fields to a function
that ought to be ready to escape them (and in fact does, apart from the
leading @ thing).
The documentation needs to be fixed at a minimum. It would be a much
better idea to get rid of the broken behavior. The @ prefix is a bad
idea (what if I want to pass @?) and with the current lack of
documentation it's a security hole.
This needs to be patched or at least documented.
[2009-01-21 19:56:56] j...@php.net
It's security hole only if you don't filter the input..
[2008-10-31 19:18:36] tom at punkave dot com
Description:
PHP's cURL wrapper implements HTTP POST file uploads as follows:
curl_setopt($curl_handle, CURLOPT_POST, 1);
$args['file'] = '@/path/to/file';
curl_setopt($curl_handle, CURLOPT_POSTFIELDS, $args);
When ext/curl/interface.c sees that $args is an array and not a
query-encoded string, it switches to a branch that uses CURLOPT_HTTPPOST
rather than CURLOPT_POST. The code then checks for an '@' prefix in the
value of every field. When an '@' is spotted, that particular field is
treated as a file to be uploaded rather than a value to be sent as-is.
This implementation and the associated documentation have the following
problems which are best described together for clarity's sake:
1. The fact that passing an array of arguments will trigger
multipart/form-data is not documented. The documentation implies that
you can use a query-encoded string or an array interchangeably. While
most servers do accept multipart/form-data this is not a given. Also it
is frequently the less efficient of the two encodings when files are not
being uploaded.
2. When passing an array it is impossible to submit a form field value
that does start with @. This is a bug in the implementation.
3. The documentation makes no mention of the '@ prefix means the rest
of the value is a filename to be uploaded' issue. This is a serious
security problem. PHP pages that transship form submissions from one
site to another are being coded in ignorance of the fact that the '@'
prefix could be used by end users to send any readable file on the first
host to the second host. At a minimum, coders must check for and remove
any @ prefix from user-submitted fields.
A recommended solution:
1. The '@ prefix for files, arrays trigger multipart/form-data'
behavior should be controlled by a php.ini backwards compatibility
option, hopefully defaulting off in the future.
2. CURLOPT_HTTPPOST and CURLOPT_HTTPPOSTFIELDS should be explicitly
supported and documented as the correct way to do multipart/form_data,
and
3. Instead of an @ prefix in the values of fields,
CURLOPT_HTTPPOSTFILEFIELDS should be implemented to expressly pass an
hash of keys => filenames.
It would work like this:
// I want a file upload with cURL
curl_setopt($curl_handle, CURLOPT_HTTPPOST, 1);
// Pass the non-file fields
curl_setopt($curl_handle, CURLOPT_HTTPPOSTFIELDS,
array("name" => "Joe Smith"));
// Pass the file fields
curl_setopt($curl_handle, CURLOPT_HTTPPOSTFILEFIELDS,
array("file" => "/path/to/file"));
HTTPPOST is a terrible, confusing name for multipart/form_data, but
that's a cURL problem, not a PHP problem. (: With the above
implementation at the PHP level we would at least have a correct wrapper
for cURL on which friendlier classes could be correctly built.
--
Edit this bug report at http://bugs.php.net/?id=46439&edit=1
#48139 [NEW]: MySQL Integration
From: Beowulve at gmail dot com Operating system: Win XP Pro PHP version: 5.3.0RC1 PHP Bug Type: MySQL related Bug description: MySQL Integration Description: Yeah, I would firstly like to mention how absolutely pissed off at PHP I am. Your program must be the absolute worst programmed piece of software in all of the net. You compete with Bill Gates in that regard. Now that I have that off my chest, let me explain why your program sucks. I have spent over 12 hours researching, reinstalling, etc etc etc etc etc etc ETCETERA... All trying to get mysql into php. It won't load the goddamn dll. Nothing in Event Log. Nothing anywhere, regardless of errors=E_ALL, or "REPORT_STARTUP_ERRORS". I have fucking done it all. ITS IMPOSSIBLE TO INTEGRATE PHP WITH MYSQL. THIS IS BECAUSE YOUR PROGRAM SUCKS, AND YOU SHOULD ADD SOME GODDAMN ERROR REPORTING SO WE CAN AT LEAST FIGURE OUT WHAT THE FUCK YOUR___ PROGRAM IS DOING WRONG. FIX YOUR SHIT. just fucking fix it. Thanks. And fuck you sincerely, for making my life, and everyone else's life, an utter atrocity. I'm going to Cold Fusion 8; Fuck you. Expected result: Nothing. Your blasted PHP program doesn't even report error messages like it should. Actual result: -- Yay! PHP Works. Oh wait... no it doesn't. It isn't loading .dll's, and it isn't reporting why not - maybe this is because PHP sucks? yup, i think so. -- Edit bug report at http://bugs.php.net/?id=48139&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48139&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48139&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48139&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48139&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48139&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48139&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48139&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48139&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48139&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48139&r=support Expected behavior: http://bugs.php.net/fix.php?id=48139&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48139&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48139&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48139&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48139&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48139&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48139&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48139&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48139&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48139&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48139&r=mysqlcfg
#48139 [Opn->Bgs]: MySQL Integration
ID: 48139 Updated by: der...@php.net Reported By: Beowulve at gmail dot com -Status: Open +Status: Bogus Bug Type: MySQL related Operating System: Win XP Pro PHP Version: 5.3.0RC1 New Comment: . Previous Comments: [2009-05-03 21:23:48] Beowulve at gmail dot com Description: Yeah, I would firstly like to mention how absolutely pissed off at PHP I am. Your program must be the absolute worst programmed piece of software in all of the net. You compete with Bill Gates in that regard. Now that I have that off my chest, let me explain why your program sucks. I have spent over 12 hours researching, reinstalling, etc etc etc etc etc etc ETCETERA... All trying to get mysql into php. It won't load the goddamn dll. Nothing in Event Log. Nothing anywhere, regardless of errors=E_ALL, or "REPORT_STARTUP_ERRORS". I have fucking done it all. ITS IMPOSSIBLE TO INTEGRATE PHP WITH MYSQL. THIS IS BECAUSE YOUR PROGRAM SUCKS, AND YOU SHOULD ADD SOME GODDAMN ERROR REPORTING SO WE CAN AT LEAST FIGURE OUT WHAT THE FUCK YOUR___ PROGRAM IS DOING WRONG. FIX YOUR SHIT. just fucking fix it. Thanks. And fuck you sincerely, for making my life, and everyone else's life, an utter atrocity. I'm going to Cold Fusion 8; Fuck you. Expected result: Nothing. Your blasted PHP program doesn't even report error messages like it should. Actual result: -- Yay! PHP Works. Oh wait... no it doesn't. It isn't loading .dll's, and it isn't reporting why not - maybe this is because PHP sucks? yup, i think so. -- Edit this bug report at http://bugs.php.net/?id=48139&edit=1
#47966 [Ver->Csd]: array Notice: Undefined index:
ID: 47966 Updated by: paj...@php.net Reported By: dba at csis dot dk -Status: Verified +Status: Closed Bug Type: cURL related Operating System: * PHP Version: 6CVS-2009-04-14 (snap) -Assigned To: +Assigned To: pajoye 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-05-03 21:01:18] paj...@php.net All OSes. Note that b"url" works, but even using add_assoc_string or add_assoc_utf8_string does not help. See the CAAS macro in interface.c [2009-04-14 11:25:41] dba at csis dot dk correction on commented line 14: // Notice: Undefined index: url in D:\home\main\tools\test\index.php on line 14 [2009-04-14 11:23:20] dba at csis dot dk Description: can't call array from $curl_getinfo['xxx'] but will output on var_dump() and var_export() --- phpinfo() System Windows NT DBA-XP-UK 5.1 build 2600 (Windows XP Professional Service Pack 3) i586 Build Date Apr 14 2009 00:27:29 CompilerMSVC6 (Visual C++ 6.0) Server API Apache 2.0 Handler Apache Version Apache/2.2.11 (Win32) PHP/6.0.0-dev Reproduce code: --- http://www.php.net/";); curl_setopt($ch, CURLOPT_HEADER, true); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); $curl_data = curl_exec($ch); $curl_getinfo = curl_getinfo($ch); print "".var_export($curl_getinfo, true).""; print "curl_getinfo['url']: ".$curl_getinfo['url'].""; // Notice: Undefined index: url in D:\home\main\tools\test\index.php on line 19 curl_close($ch); ?> Expected result: output from var_export($curl_getinfo) AND output from print $curl_getinfo['url'] Actual result: -- only gets output from var_export($curl_getinfo)... -- Edit this bug report at http://bugs.php.net/?id=47966&edit=1
#47773 [Ver]: cURL multi crashes
ID: 47773
Updated by: paj...@php.net
Reported By: entpman at gmail dot com
Status: Verified
Bug Type: cURL related
-Operating System: win32 only - WIN XP SP2
+Operating System: *
PHP Version: 5.2.9
Assigned To: pajoye
New Comment:
not only windows
Previous Comments:
[2009-04-06 20:45:05] daniel at haxx dot se
I'm convinced this is a bug in libcurl, see this analysis by
Sergii Volchkov:
http://curl.haxx.se/mail/lib-2009-04/0028.html
(AFAIK, there is nobody working on a fix for this.)
[2009-03-25 15:29:52] entpman at gmail dot com
I tried version 5.3.0RC2-dev same results.
[2009-03-25 14:08:06] entpman at gmail dot com
Description:
The program will work fine for hundreds of downloads then suddenly
crashes.
Reproduce code:
---
'http://www.google.com'
),
array(
'url' => 'http://www.yahoo.com'
)
)
);
// of course more urls are needs
function downloadurls($downloads,$cookie = null){
$timeout = 30;
$mcurl = curl_multi_init();
$agent = "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12)
Gecko/2009201 Firefox/3.0.0.1";
foreach($downloads as $key=>$download){
$url = $download['url'];
$ch = curl_init();
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1);
curl_setopt($ch, CURLOPT_TIMEOUT, $timeout);
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER,0);
curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 15);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST,0);
curl_setopt($ch, CURLOPT_USERAGENT, $agent);
if(!empty($download['postdata'])){
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS,$download['postdata']);
}
if(!empty($cookie)){
@unlink($cookie);
//echo "added cookie\n";
curl_setopt($ch, CURLOPT_COOKIEFILE, $cookie);
curl_setopt($ch, CURLOPT_COOKIEJAR, $cookie);
}
if(!empty($download['proxy'])){
curl_setopt($ch, CURLOPT_PROXY, $download['proxy']);
}
curl_multi_add_handle($mcurl, $ch);
$downloads[$key]['handle'] = $ch;
}
do {
$n=curl_multi_exec($mcurl,$active);
usleep(100);
}
while ($active);
foreach($downloads as $key=>$download){
$ch = $download['handle'];
$done_content = curl_multi_getcontent($ch);
if(curl_errno($ch) == 0) {
$downloads[$key]['picture'] = $done_content;
} else {
exit('error');
}
curl_multi_remove_handle($mcurl, $ch);
curl_close($ch);
}
curl_multi_close($mcurl);
return $downloads;
}
?>
Actual result:
--
backtrace:
php_curl.dll!_Curl_llist_insert_next() + 0x48 bytes
php_curl.dll!_Curl_hash_add() + 0x74 bytes
php_curl.dll!_Curl_cache_addr() + 0x6d bytes
php_curl.dll!_Curl_addrinfo4_callback() + 0x82 bytes
php_curl.dll!_Curl_addrinfo4_callback() + 0x14 bytes
php_curl.dll!_Curl_getaddrinfo() + 0x317 bytes
msvcrt.dll!77c3a3b0()
[Frames below may be incorrect and/or missing, no symbols loaded for
msvcrt.dll]
kernel32.dll!7c80b683()
--
Edit this bug report at http://bugs.php.net/?id=47773&edit=1
#45533 [NoF->Bgs]: cURL output includes content from redirects when CURLOPT_FOLLOWLOCATION set
ID: 45533 Updated by: paj...@php.net Reported By: signe at cothlamadh dot net -Status: No Feedback +Status: Bogus Bug Type: cURL related Operating System: FreeBSD 7.0 PHP Version: 5.2.6 -Assigned To: fb-req-jani +Assigned To: pajoye New Comment: If you ask to include the header in the output, you will get them. Suppress this line: curl_setopt($cUrl, CURLOPT_HEADER, true); The same applies to the cmd line: curl -i -L http://www.crn.com/rss/cisco/index.xml vs curl -L http://www.crn.com/rss/cisco/index.xml No bug > bogus. Previous Comments: [2009-02-03 05:09:01] satishpalasa at hotmail dot com I am facing the same problem the header content is not recorded. will there be any problem with this. [2008-08-07 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2008-07-30 18:57:33] j...@php.net When you can provide a script that reproduces this problem every time, give us feedback. [2008-07-17 00:17:50] signe at cothlamadh dot net I didn't try before reporting, and since they've made a modification, my one known verification site is lost. I saw this bug in a previous version of php (5.1.2, I believe) and at that point in time, I couldn't replicate it with curl commandline. I upgraded to 5.2.3 (along with a newer libcurl) on that particular server and wasn't able to reproduce it after the upgrade so I didn't report it at the time. I need to try to create a redirect script that can cause the behavior - until I do, no, I can't reproduce it in either PHP or curl. [2008-07-16 22:29:29] j...@php.net Can you reproduce this using curl on command line? ie. without PHP? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/45533 -- Edit this bug report at http://bugs.php.net/?id=45533&edit=1
#47812 [Asn]: undefined symbol: gdJpegGetVersionInt
ID: 47812 Updated by: paj...@php.net Reported By: oeriksson at mandriva dot com Status: Assigned Bug Type: GD related Operating System: Mandriva Linux PHP Version: 5.3.0RC1 Assigned To: pajoye New Comment: For your information, the gdJpegGetVersionInt error is fixed in CVS, I keep this bug open as it reflects what I'm working on: allows to use either the bundled library or a decent external version without loosing features. Previous Comments: [2009-04-15 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2009-04-07 09:27:23] paj...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-03-30 17:45:13] paj...@php.net "The private changes in the bundled libmagic library (file-5.x) is also quite annoying." It will end like mod_mime, to only use the DB. [2009-03-30 17:38:58] oeriksson at mandriva dot com Thanks Pierre, I'm looking forward to a gd with all the bling-bling that's in the bundled gd in php, as well as with libzip. The private changes in the bundled libmagic library (file-5.x) is also quite annoying. [2009-03-27 21:29:40] paj...@php.net Please do not use this report to discuss other topics. But to answer your questions, yes, they are provided as patch upstream as well and we try to keep everything synced as much as possible. But they tend to stay behind for some fixes, especially edge cases for crashes or windows support. You can follow the libzip mailing list if you are interested. 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/47812 -- Edit this bug report at http://bugs.php.net/?id=47812&edit=1
#45533 [Bgs]: cURL output includes content from redirects when CURLOPT_FOLLOWLOCATION set
ID: 45533 User updated by: signe at cothlamadh dot net Reported By: signe at cothlamadh dot net Status: Bogus Bug Type: cURL related Operating System: FreeBSD 7.0 PHP Version: 5.2.6 Assigned To: pajoye New Comment: You don't understand the issue at all. The issue is not the headers, it's that CONTENT from the redirect is included in the output, and shouldn't be. Please fully read the original description. Output sent from the server during the 3xx response should not be included in the output given to the user. A server response like this: " HTTP/1.1 302 Found Location: http://www.example.com/ This document has moved to http://www.example.com HTTP/1.1 200 Found This is the output from the new document. " Should not yield output from PHP that says: " This document has moved to http://www.example.com This is the output from the new document. " The 302 content is supposed to be ignored. CURL does this properly, but in some circumstances, PHP does NOT. As I detail in the original issue report, the issue is WORSE when headers are turned on, because the content is included between the headers, and is impossible to parse out using the header and body length values returned from curl_getinfo() Previous Comments: [2009-05-03 22:06:29] paj...@php.net If you ask to include the header in the output, you will get them. Suppress this line: curl_setopt($cUrl, CURLOPT_HEADER, true); The same applies to the cmd line: curl -i -L http://www.crn.com/rss/cisco/index.xml vs curl -L http://www.crn.com/rss/cisco/index.xml No bug > bogus. [2009-02-03 05:09:01] satishpalasa at hotmail dot com I am facing the same problem the header content is not recorded. will there be any problem with this. [2008-08-07 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2008-07-30 18:57:33] j...@php.net When you can provide a script that reproduces this problem every time, give us feedback. [2008-07-17 00:17:50] signe at cothlamadh dot net I didn't try before reporting, and since they've made a modification, my one known verification site is lost. I saw this bug in a previous version of php (5.1.2, I believe) and at that point in time, I couldn't replicate it with curl commandline. I upgraded to 5.2.3 (along with a newer libcurl) on that particular server and wasn't able to reproduce it after the upgrade so I didn't report it at the time. I need to try to create a redirect script that can cause the behavior - until I do, no, I can't reproduce it in either PHP or curl. 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/45533 -- Edit this bug report at http://bugs.php.net/?id=45533&edit=1
#45533 [Bgs]: cURL output includes content from redirects when CURLOPT_FOLLOWLOCATION set
ID: 45533 Updated by: paj...@php.net Reported By: signe at cothlamadh dot net Status: Bogus Bug Type: cURL related Operating System: FreeBSD 7.0 PHP Version: 5.2.6 Assigned To: pajoye New Comment: It seems that you are back and finally provide feedback. > The issue is not the headers, > it's that CONTENT from the redirect is included > in the output, and shouldn't be. Cannot reproduce it with curl 7.15.5 or 7.19.4. PHP does not alter the contents but get it from cURL. Please check with the command line (using the same version than php). Previous Comments: [2009-05-03 22:31:50] signe at cothlamadh dot net You don't understand the issue at all. The issue is not the headers, it's that CONTENT from the redirect is included in the output, and shouldn't be. Please fully read the original description. Output sent from the server during the 3xx response should not be included in the output given to the user. A server response like this: " HTTP/1.1 302 Found Location: http://www.example.com/ This document has moved to http://www.example.com HTTP/1.1 200 Found This is the output from the new document. " Should not yield output from PHP that says: " This document has moved to http://www.example.com This is the output from the new document. " The 302 content is supposed to be ignored. CURL does this properly, but in some circumstances, PHP does NOT. As I detail in the original issue report, the issue is WORSE when headers are turned on, because the content is included between the headers, and is impossible to parse out using the header and body length values returned from curl_getinfo() [2009-05-03 22:06:29] paj...@php.net If you ask to include the header in the output, you will get them. Suppress this line: curl_setopt($cUrl, CURLOPT_HEADER, true); The same applies to the cmd line: curl -i -L http://www.crn.com/rss/cisco/index.xml vs curl -L http://www.crn.com/rss/cisco/index.xml No bug > bogus. [2009-02-03 05:09:01] satishpalasa at hotmail dot com I am facing the same problem the header content is not recorded. will there be any problem with this. [2008-08-07 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2008-07-30 18:57:33] j...@php.net When you can provide a script that reproduces this problem every time, give us feedback. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/45533 -- Edit this bug report at http://bugs.php.net/?id=45533&edit=1
#45533 [Bgs]: cURL output includes content from redirects when CURLOPT_FOLLOWLOCATION set
ID: 45533 Updated by: paj...@php.net Reported By: signe at cothlamadh dot net Status: Bogus Bug Type: cURL related Operating System: FreeBSD 7.0 PHP Version: 5.2.6 Assigned To: pajoye New Comment: > Cannot reproduce it with curl 7.15.5 or 7.19.4. Cannot reproduce with php or curl with these versions. Previous Comments: [2009-05-03 22:48:08] paj...@php.net It seems that you are back and finally provide feedback. > The issue is not the headers, > it's that CONTENT from the redirect is included > in the output, and shouldn't be. Cannot reproduce it with curl 7.15.5 or 7.19.4. PHP does not alter the contents but get it from cURL. Please check with the command line (using the same version than php). [2009-05-03 22:31:50] signe at cothlamadh dot net You don't understand the issue at all. The issue is not the headers, it's that CONTENT from the redirect is included in the output, and shouldn't be. Please fully read the original description. Output sent from the server during the 3xx response should not be included in the output given to the user. A server response like this: " HTTP/1.1 302 Found Location: http://www.example.com/ This document has moved to http://www.example.com HTTP/1.1 200 Found This is the output from the new document. " Should not yield output from PHP that says: " This document has moved to http://www.example.com This is the output from the new document. " The 302 content is supposed to be ignored. CURL does this properly, but in some circumstances, PHP does NOT. As I detail in the original issue report, the issue is WORSE when headers are turned on, because the content is included between the headers, and is impossible to parse out using the header and body length values returned from curl_getinfo() [2009-05-03 22:06:29] paj...@php.net If you ask to include the header in the output, you will get them. Suppress this line: curl_setopt($cUrl, CURLOPT_HEADER, true); The same applies to the cmd line: curl -i -L http://www.crn.com/rss/cisco/index.xml vs curl -L http://www.crn.com/rss/cisco/index.xml No bug > bogus. [2009-02-03 05:09:01] satishpalasa at hotmail dot com I am facing the same problem the header content is not recorded. will there be any problem with this. [2008-08-07 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". 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/45533 -- Edit this bug report at http://bugs.php.net/?id=45533&edit=1
#48139 [Bgs]: MySQL Integration
ID: 48139 Updated by: and...@php.net Reported By: Beowulve at gmail dot com Status: Bogus Bug Type: MySQL related Operating System: Win XP Pro PHP Version: 5.3.0RC1 New Comment: I wanted to send you a unicorn and a rainbow by way of apology, but realized you wouldn't be able to sign for it since your head is stuck so far up inside your ass. Previous Comments: [2009-05-03 21:26:59] der...@php.net . [2009-05-03 21:23:48] Beowulve at gmail dot com Description: Yeah, I would firstly like to mention how absolutely pissed off at PHP I am. Your program must be the absolute worst programmed piece of software in all of the net. You compete with Bill Gates in that regard. Now that I have that off my chest, let me explain why your program sucks. I have spent over 12 hours researching, reinstalling, etc etc etc etc etc etc ETCETERA... All trying to get mysql into php. It won't load the goddamn dll. Nothing in Event Log. Nothing anywhere, regardless of errors=E_ALL, or "REPORT_STARTUP_ERRORS". I have fucking done it all. ITS IMPOSSIBLE TO INTEGRATE PHP WITH MYSQL. THIS IS BECAUSE YOUR PROGRAM SUCKS, AND YOU SHOULD ADD SOME GODDAMN ERROR REPORTING SO WE CAN AT LEAST FIGURE OUT WHAT THE FUCK YOUR___ PROGRAM IS DOING WRONG. FIX YOUR SHIT. just fucking fix it. Thanks. And fuck you sincerely, for making my life, and everyone else's life, an utter atrocity. I'm going to Cold Fusion 8; Fuck you. Expected result: Nothing. Your blasted PHP program doesn't even report error messages like it should. Actual result: -- Yay! PHP Works. Oh wait... no it doesn't. It isn't loading .dll's, and it isn't reporting why not - maybe this is because PHP sucks? yup, i think so. -- Edit this bug report at http://bugs.php.net/?id=48139&edit=1
#45533 [Bgs]: cURL output includes content from redirects when CURLOPT_FOLLOWLOCATION set
ID: 45533
User updated by: signe at cothlamadh dot net
Reported By: signe at cothlamadh dot net
Status: Bogus
Bug Type: cURL related
Operating System: FreeBSD 7.0
PHP Version: 5.2.6
Assigned To: pajoye
New Comment:
I'm not "finally back" - I was asked for a script that can produce this
problem 100% of the time. ("When you can provide a script that
reproduces this problem every time, give us feedback.") There is no such
thing. It's sporadic - it will happen with one URL for a while, and
then something about the test changes and it stops reproducing.
There is no discernible pattern to reproduction.
The servers are not in my control so I have no insight into what the
original settings were or what changed when the issue disappears.
I have reproduced it with every PHP up to 5.2.9, and libcurl versions:
7.16.4 (Ubuntu Gutsy)
7.18.2 (Ubuntu Jaunty)
as well as several revisions on FreeBSD that I no longer have
available.
Previous Comments:
[2009-05-03 22:48:53] paj...@php.net
> Cannot reproduce it with curl 7.15.5 or 7.19.4.
Cannot reproduce with php or curl with these versions.
[2009-05-03 22:48:08] paj...@php.net
It seems that you are back and finally provide feedback.
> The issue is not the headers,
> it's that CONTENT from the redirect is included
> in the output, and shouldn't be.
Cannot reproduce it with curl 7.15.5 or 7.19.4.
PHP does not alter the contents but get it from cURL. Please check with
the command line (using the same version than php).
[2009-05-03 22:31:50] signe at cothlamadh dot net
You don't understand the issue at all. The issue is not the headers,
it's that CONTENT from the redirect is included in the output, and
shouldn't be.
Please fully read the original description.
Output sent from the server during the 3xx response should not be
included in the output given to the user. A server response like this:
"
HTTP/1.1 302 Found
Location: http://www.example.com/
This document has moved to http://www.example.com
HTTP/1.1 200 Found
This is the output from the new document.
"
Should not yield output from PHP that says:
"
This document has moved to http://www.example.com
This is the output from the new document.
"
The 302 content is supposed to be ignored. CURL does this properly,
but in some circumstances, PHP does NOT. As I detail in the original
issue report, the issue is WORSE when headers are turned on, because the
content is included between the headers, and is impossible to parse out
using the header and body length values returned from curl_getinfo()
[2009-05-03 22:06:29] paj...@php.net
If you ask to include the header in the output, you will get them.
Suppress this line:
curl_setopt($cUrl, CURLOPT_HEADER, true);
The same applies to the cmd line:
curl -i -L http://www.crn.com/rss/cisco/index.xml
vs
curl -L http://www.crn.com/rss/cisco/index.xml
No bug > bogus.
[2009-02-03 05:09:01] satishpalasa at hotmail dot com
I am facing the same problem the header content is not recorded. will
there be any problem with this.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/45533
--
Edit this bug report at http://bugs.php.net/?id=45533&edit=1
#48137 [Bgs]: assigning array element reference appears to modify array
ID: 48137
Updated by: scott...@php.net
Reported By: mike at clove dot com
Status: Bogus
Bug Type: Arrays related
Operating System: Mac OS X 10.5.6
PHP Version: 5.2.9
New Comment:
References aren't pointers, all they say is that the two values should
point to the same content. This is still the case even if the array was
changed.
http://www.php.net/manual/en/language.references.whatare.php
Previous Comments:
[2009-05-03 17:04:57] der...@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
Nah, this is fine. It doesn\'t modify the array. The & just shows that
the is_ref bit on the zval container that contains the int(1) value is
set.
[2009-05-03 17:01:04] mike at clove dot com
Description:
Assigning reference to an array element appears to modify the
array element rather than simply creating a reference to it.
This is surprising, to say the least.
At least I think this is a bug and couldn't find anything with the same
behavior and such minimal code.
Reproduce code:
---
$a = array(1,2);
$r =& $a[0];
var_dump($a);
Expected result:
array(2) {
[0]=>
int(1)
[1]=>
int(2)
}
Actual result:
--
array(2) {
[0]=>
&int(1)
[1]=>
int(2)
}
--
Edit this bug report at http://bugs.php.net/?id=48137&edit=1
#48135 [Opn->Fbk]: Isset doesn't function as expected
ID: 48135
Updated by: scott...@php.net
Reported By: wizanda at yahoo dot co dot uk
-Status: Open
+Status: Feedback
Bug Type: Feature/Change Request
Operating System: all
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.
We need a self contained script that we can run, though it sounds like
you just need.
!isset($handler, $handler[$name])
To check both the array and the key.
Previous Comments:
[2009-05-03 12:33:15] wizanda at yahoo dot co dot uk
Description:
Since PHP 5 most PHP systems will be storing masses of data, due to
isset and empty no longer assessing the full variable, yet running code
once for each item within it.
Reproduce code:
---
---
>From manual page: function.isset
---
function &loadHandler($name){static $handler;
if(!isset($handler[$name])){$FileName = "core/core.".$name.".php";
require_once $FileName;
$ClassName = "SmartyCore_".$name;
$handler[$name] = new $ClassName();}
$classes = $handler[$name];
return $classes;}
Expected result:
This should check $handler, see if it's empty the first time; check
$name and see this is an empty array, attempt to fill it and thus
setting the $handler as being a container for the array and then check
for each $name as a separate array within it.
Actual result:
--
What this appears to be doing is checking $handler and running it, then
checking $name and running it... So when you var_dump the $handler it
has multiple copies of the variable set.
This can be slightly resolved by making the array set the original
$handler variable, which reduces the copies made.
$handler = array($name => new $ClassName());}
...Yet there should be only one copy set.
--
Edit this bug report at http://bugs.php.net/?id=48135&edit=1
#48137 [Bgs]: assigning array element reference appears to modify array
ID: 48137
User updated by: mike at clove dot com
Reported By: mike at clove dot com
Status: Bogus
Bug Type: Arrays related
Operating System: Mac OS X 10.5.6
PHP Version: 5.2.9
New Comment:
Thanks derick at php dot net.
It's confusing to have var_dump() tell me that the assignment has
changed element 0 from a value to a reference. That seems to me to be a
bug in var_dump(): in the code, $r is the reference, not $a[0] - which
should still be a value. I think this means var_dump() is displaying
unreliable information.
to scottmac at php dot net: the issue isn't what a reference is, it's
that the a := b appears to be changing the value of 'b', which is just
plain wrong for any assignment in any programming language I know
[unless $a =& $b; $a = $b; which would be specifically asking to do
this].
Previous Comments:
[2009-05-04 00:34:29] scott...@php.net
References aren't pointers, all they say is that the two values should
point to the same content. This is still the case even if the array was
changed.
http://www.php.net/manual/en/language.references.whatare.php
[2009-05-03 17:04:57] der...@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
Nah, this is fine. It doesn\'t modify the array. The & just shows that
the is_ref bit on the zval container that contains the int(1) value is
set.
[2009-05-03 17:01:04] mike at clove dot com
Description:
Assigning reference to an array element appears to modify the
array element rather than simply creating a reference to it.
This is surprising, to say the least.
At least I think this is a bug and couldn't find anything with the same
behavior and such minimal code.
Reproduce code:
---
$a = array(1,2);
$r =& $a[0];
var_dump($a);
Expected result:
array(2) {
[0]=>
int(1)
[1]=>
int(2)
}
Actual result:
--
array(2) {
[0]=>
&int(1)
[1]=>
int(2)
}
--
Edit this bug report at http://bugs.php.net/?id=48137&edit=1
#48141 [NEW]: memory leak in zend_execute.c and zend_operators.c
From: greg at chiaraquartet dot net
Operating system: ubuntu linux
PHP version: 5.3CVS-2009-05-04 (CVS)
PHP Bug Type: Scripting Engine problem
Bug description: memory leak in zend_execute.c and zend_operators.c
Description:
When running a simple file that only instantiates objects using autoload,
there is a memory leak.
The leak appears to be caused by some combination of string concatenation
and exception throwing. The line that causes the leak is in
Pyrus/src/Pyrus/Registry/Sqlite3.php in the constructor:
if ($path && $path != ':memory:') {
if (dirname($path) . DIRECTORY_SEPARATOR . '.pear2registry' !=
$path) {
$path = $path . DIRECTORY_SEPARATOR . '.pear2registry';
}
}
The line "$path = $path . DIRECTORY_SEPARATOR . '.pear2registry';"
leaks the value "/usr/local/lib/php/.pear2registry" on my machine, and the
zval allocated for $path.
Reproduce code:
---
http://svn.pear.php.net/PEAR2/all
function __autoload($class)
{
if ($class == 'PEAR2_Exception') {
include __DIR__ . '/Exception/src/Exception.php';
return;
}
$class = str_replace('PEAR2_', '', $class);
$class = str_replace('_', '/', $class);
include __DIR__ . '/Pyrus/src/' . $class . '.php';
}
$a = PEAR2_Pyrus_Config::current();
Expected result:
no output
Actual result:
--
u...@ubuntu8041:~/workspace/all/Pyrus/tests/AtomicFileTransaction/rmrf$
php -n test.phpt
[Sun May 3 22:58:31 2009] Script: 'test.phpt'
/home/user/workspace/php5/Zend/zend_execute.c(723) : Freeing 0xB7B52AE4
(20 bytes), script=test.phpt
[Sun May 3 22:58:31 2009] Script: 'test.phpt'
/home/user/workspace/php5/Zend/zend_operators.c(1231) : Freeing
0x088CE1EC (34 bytes), script=test.phpt
=== Total 2 memory leaks detected ===
--
Edit bug report at http://bugs.php.net/?id=48141&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48141&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48141&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48141&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48141&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48141&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48141&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48141&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48141&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48141&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48141&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48141&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48141&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48141&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48141&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48141&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48141&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48141&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48141&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48141&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48141&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48141&r=mysqlcfg
