Bug #33957 [Com]: gmdate('W')/date('W') sometimes returns wrong week number.
Edit report at http://bugs.php.net/bug.php?id=33957&edit=1
ID: 33957
Comment by: paul at stunning-stuff dot com
Reported by: paul at stunning-stuff dot com
Summary: gmdate('W')/date('W') sometimes returns wrong week
number.
Status: Closed
Type: Bug
Package: Date/time related
Operating System: *
PHP Version: 5CVS-2005-08-02
Assigned To: derick
New Comment:
23 is the correct week number according to timeanddate.com. Remember the
week
number is determined using ISO8601 rules!!
Btw, a snapshot release is an 'overnight' release of the latest version
of a
software package. Google will tell you more.
-Paul
Previous Comments:
[2010-06-13 13:07:20] cgullz at gmail dot com
Hi,
I have the same problem using date('W') to show week number of
13/June/2010 which should be 25, but it displays 23.
I use php 5.2.6 through WAMP2.
This is the first time I hear about snapshot so not sure what am I
suppose to do to fix this problem.
Can someone please explain to me what should I do?
Thank you,
Sigal
[2010-05-19 20:56:04] paul at stunning-stuff dot com
Hi Warwick,
The 1st week of a year does not necessarily start on the first of
January
under the rules of ISO8601. I checked your examples and they seemed
fine.
Please read up on ISO8601.
-Paul
[2010-05-19 04:06:11] wps at wwe dot com
date('W', $timestamp) fails to return "01" for some January 1st years on
PHP version 5.3.2 and 5.2.8 on CentOS and Windows.
$year = 1970;
$month = 1;
$day = 1;
while ($year <= 2028) {
$timestamp = mktime(12, 0, 0, $month, $day, $year);
print $year . " :: " . date('W', $timestamp). " :: " . date('D',
$timestamp) . "\n";
$year++;
}
Expect 01 for every year
but instead get
1970 :: 01 :: Thu
1971 :: 53 :: Fri
1972 :: 52 :: Sat
1973 :: 01 :: Mon
1974 :: 01 :: Tue
1975 :: 01 :: Wed
1976 :: 01 :: Thu
1977 :: 53 :: Sat
1978 :: 52 :: Sun
...
2020 :: 01 :: Wed
2021 :: 53 :: Fri
2022 :: 52 :: Sat
2023 :: 52 :: Sun
2024 :: 01 :: Mon
2025 :: 01 :: Wed
2026 :: 01 :: Thu
2027 :: 53 :: Fri
2028 :: 52 :: Sat
1st falling on Friday returns 53
1st falling on Saturday/Sunday return 52
Checked dates using
http://www.tuxgraphics.org/toolbox/cal_year.html
Warwick Shaw
[2005-08-31 16:31:52] 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.
[2005-08-02 16:45:08] paul at stunning-stuff dot com
Thanks for your quick reply and thanks for doing such a great job on
PHP. You dev's really make this the best open source language today.
I hope you are able to solve this problem (I'm sure you will). One more
note though: This problem should reoccur every 28 years before and after
1992. This might help you in your testing.
Thanks,
Paul van der Maas
---
www.stunning-stuff.com
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=33957
--
Edit this bug report at http://bugs.php.net/bug.php?id=33957&edit=1
Bug #50578 [Com]: incorrect shebang in phar.phar
Edit report at http://bugs.php.net/bug.php?id=50578&edit=1 ID: 50578 Comment by: gerwin at uber1337 dot nl Reported by: Fedora at FamilleCollet dot com Summary: incorrect shebang in phar.phar Status: Assigned Type: Bug Package: PHAR related Operating System: Linux (Fedora 12) PHP Version: 5.3.2RC1 Assigned To: cellog New Comment: Thanks for the patch Remi, it works just fine. It's an annoying bug though when you need to build rpm packages too and it would be nice to see it fixed. Previous Comments: [2010-03-05 01:16:17] paj...@php.net Greg, can you valid and apply the patch please? Or simply valid it and I can apply it if it looks fine for you. [2010-03-05 01:04:57] paj...@php.net Please take a look at this patch and let us know if it works. It would rock if it can make it in the next release. [2010-03-04 22:30:55] Fedora at famillecollet dot com Same issue with 5.3.2 finale. [2010-02-12 14:19:44] Fedora at famillecollet dot com Same issue with PHP 5.3.2RC2 [2009-12-26 12:28:34] Fedora at FamilleCollet dot com Trivial which fix the issue : http://remi.fedorapeople.org/php-5.3.2-phar.patch The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=50578 -- Edit this bug report at http://bugs.php.net/bug.php?id=50578&edit=1
Bug #52043 [Asn->Csd]: GD doesn't recognize latest libJPEG version (8b)
Edit report at http://bugs.php.net/bug.php?id=52043&edit=1 ID: 52043 Updated by: paj...@php.net Reported by: php at group dot apple dot com Summary: GD doesn't recognize latest libJPEG version (8b) -Status: Assigned +Status: Closed Type: Bug Package: GD related Operating System: all PHP Version: 5.3.2 Assigned To: pajoye New Comment: Fixed in SVN, thanks for your feedback and patch! Previous Comments: [2010-06-14 10:12:12] paj...@php.net Automatic comment from SVN on behalf of pajoye Revision: http://svn.php.net/viewvc/?view=revision&revision=300425 Log: - #52043,GD doesn't recognize latest libJPEG version [2010-06-11 03:16:23] php at group dot apple dot com Description: Building php-5.3.2 against libJPEGv8b (NOT 6b!) appears to be functional, but php reports the wrong version number. The patch below adds an additional cast to the switch statement. Test script: --- php -info | grep -i jpeg Expected result: libJPEG Version => 8b Actual result: -- libJPEG Version => unknown -- Edit this bug report at http://bugs.php.net/bug.php?id=52043&edit=1
Bug #47304 [Com]: typecast of numeric string to float produces strange result
Edit report at http://bugs.php.net/bug.php?id=47304&edit=1
ID: 47304
Comment by: xiaobo dot bob at gmail dot com
Reported by: lennartvdd at mailordersolutions dot nl
Summary: typecast of numeric string to float produces strange
result
Status: Assigned
Type: Bug
Package: Scripting Engine problem
Operating System: win32 only
PHP Version: 5.2.9
Assigned To: pajoye
New Comment:
2010-06-14 09:30:45 BST
I have reproduced this bug, but after changed some setting: change the
"precision" and "serialize_precision" setting in php.ini, and even
changed back, or maybe after i added the printf("%.2f\n",$v2), the echo
$v2 is correctted, but the printf result is always 16.:
finally, i wrote such a script:
for ($i=0; $i<400; $i++)
{
echo $i."-";
printf("%f\n",$i);
}
and found there're 8 number have this bug, they are:
17
19
29
39
170
190
290
390
I'm using windows xp in a virtualbox virtual machine, and a delphi
component named php4delphi, the php version is 5.2.13
Previous Comments:
[2009-12-23 07:22:24] p dot klein at letsmakesense dot de
I experienced this issue using the number_format() and round()-function.
My example page displays items in a price list and prices like '17' or
'19' (only even numbers) were converted to '16.:' and '18.:'. The weird
thing was that every fourth reload the prices were converted correctly
to '17,00' and '19,00'. The situation improved after I calculated the
floats with BCMath functions. Now three out of four conversions were
correct.
Next thing I tried was to play with the precision setting of php. After
changing the value to '13' the conversion problem disappeared. But even
after changing it back to the default setting the issue hasn't occurred
anymore.
I don't trust the situation. The bug probably still exists, but it's
very hard to reproduce. We didn't have the bug while we used version
5.2.0, but it happened with 5.2.12 and 5.3.1.
Our system:
Windows Server 2003 R2, Standard Edition, Service Pack 2
Intel Core 2 CPU 6600 @ 2.40 GHz, 3,99 GB RAM
PHP Version 5.2.12
[2009-09-28 09:58:07] egorich at junik dot lv
Seems that it fixed with rolling back to php 5.2.5 to me.
[2009-06-22 16:21:28] ciudadsatan at hotmail dot com
The bug in Linux happens with
echo 0.15-0.05;
[2009-06-22 03:47:55] ang dot chin dot han at gmail dot com
Originally from:
http://www.reddit.com/r/programming/comments/8tqpj/phpwtf_an_annoyance_
will_be_posted_each_day/c0aeg66
In short, in a Ubuntu Hardy 32 bit (64bit unaffected), 5.2.4 (with
Ubuntu patches) a simple
echo 1.0-0.5;
produces "0.0:" instead of "0.1" like in other platforms.
Not sure if it's the same bug as this is casting from float to string.
[2009-06-08 09:47:15] egorich at junik dot lv
So, any solutions to this?
The problem also arises when i try to convert string to double, like:
$amount = double($amount);
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=47304
--
Edit this bug report at http://bugs.php.net/bug.php?id=47304&edit=1
Bug #47304 [Asn->Fbk]: typecast of numeric string to float produces strange result
Edit report at http://bugs.php.net/bug.php?id=47304&edit=1
ID: 47304
Updated by: paj...@php.net
Reported by: lennartvdd at mailordersolutions dot nl
Summary: typecast of numeric string to float produces strange
result
-Status: Assigned
+Status: Feedback
Type: Bug
Package: Scripting Engine problem
Operating System: win32 only
PHP Version: 5.2.9
Assigned To: pajoye
New Comment:
xiaobo dot bob at gmail dot com:
Which setting do you use for "precision" and "serialize_precision"?
Previous Comments:
[2010-06-14 10:37:04] xiaobo dot bob at gmail dot com
2010-06-14 09:30:45 BST
I have reproduced this bug, but after changed some setting: change the
"precision" and "serialize_precision" setting in php.ini, and even
changed back, or maybe after i added the printf("%.2f\n",$v2), the echo
$v2 is correctted, but the printf result is always 16.:
finally, i wrote such a script:
for ($i=0; $i<400; $i++)
{
echo $i."-";
printf("%f\n",$i);
}
and found there're 8 number have this bug, they are:
17
19
29
39
170
190
290
390
I'm using windows xp in a virtualbox virtual machine, and a delphi
component named php4delphi, the php version is 5.2.13
[2009-12-23 07:22:24] p dot klein at letsmakesense dot de
I experienced this issue using the number_format() and round()-function.
My example page displays items in a price list and prices like '17' or
'19' (only even numbers) were converted to '16.:' and '18.:'. The weird
thing was that every fourth reload the prices were converted correctly
to '17,00' and '19,00'. The situation improved after I calculated the
floats with BCMath functions. Now three out of four conversions were
correct.
Next thing I tried was to play with the precision setting of php. After
changing the value to '13' the conversion problem disappeared. But even
after changing it back to the default setting the issue hasn't occurred
anymore.
I don't trust the situation. The bug probably still exists, but it's
very hard to reproduce. We didn't have the bug while we used version
5.2.0, but it happened with 5.2.12 and 5.3.1.
Our system:
Windows Server 2003 R2, Standard Edition, Service Pack 2
Intel Core 2 CPU 6600 @ 2.40 GHz, 3,99 GB RAM
PHP Version 5.2.12
[2009-09-28 09:58:07] egorich at junik dot lv
Seems that it fixed with rolling back to php 5.2.5 to me.
[2009-06-22 16:21:28] ciudadsatan at hotmail dot com
The bug in Linux happens with
echo 0.15-0.05;
[2009-06-22 03:47:55] ang dot chin dot han at gmail dot com
Originally from:
http://www.reddit.com/r/programming/comments/8tqpj/phpwtf_an_annoyance_
will_be_posted_each_day/c0aeg66
In short, in a Ubuntu Hardy 32 bit (64bit unaffected), 5.2.4 (with
Ubuntu patches) a simple
echo 1.0-0.5;
produces "0.0:" instead of "0.1" like in other platforms.
Not sure if it's the same bug as this is casting from float to string.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=47304
--
Edit this bug report at http://bugs.php.net/bug.php?id=47304&edit=1
Bug #52064 [Fbk->Bgs]: while loop does not meet conditions
Edit report at http://bugs.php.net/bug.php?id=52064&edit=1
ID: 52064
Updated by: f...@php.net
Reported by: developers at proneticas dot net
Summary: while loop does not meet conditions
-Status: Feedback
+Status: Bogus
Type: Bug
Package: *General Issues
Operating System: FreeBSD
PHP Version: 5.3.2
New Comment:
$ /opt/src/php-5.2.13/sapi/cli/php b52064.php
string(52) "ProNeticas has released a visual rapid database desi"
$ /opt/src/php-5.3.1/sapi/cli/php b52064.php
string(52) "ProNeticas has released a visual rapid database desi"
$ /usr/bin/php -v
PHP 5.2.6-1+lenny8 with Suhosin-Patch 0.9.6.2 (cli)[...]
$ /usr/bin/php b52064.php
string(52) "ProNeticas has released a visual rapid database desi"
Previous Comments:
[2010-06-13 00:57:51] developers at proneticas dot net
Well really any version of 5.2 was working correctly, but for the sake
of debugging, the last version of 5.2 installed was 5.2.12.
[2010-06-12 18:36:10] fel...@php.net
Which 5.2 release are you refering to?
[2010-06-12 12:51:58] developers at proneticas dot net
Description:
I am seeing a bug in PHP 5.3 where the WHILE LOOP is not meeting all of
the conditions. The same code was working great in PHP 5.2 but broke
after a PHP upgrade. I reviewed the PHP 5.3 change-log and nothing is
mentioned for changes in WHILE LOOP conditions.
Test script:
---
0)) {
$rlength--;
}
if ($rlength== 0) {
return substr($string, 0, $setlength);
} else {
return substr($string, 0, $rlength).'.';
}
}else {
return $string;
}
}
$mstr = 'ProNeticas has released a visual rapid database design tool.
This allows you to generate online programs in rapid time, without any
programming.';
print cutTextPer( (String)$mstr, 52);
?>
[OUTPUT IN PHP 5.2]
ProNeticas has released a visual rapid database design tool.
[OUTPUT IN PHP 5.3]
ProNeticas has released a visual rapid database de
Expected result:
ProNeticas has released a visual rapid database design tool.
Actual result:
--
ProNeticas has released a visual rapid database de
--
Edit this bug report at http://bugs.php.net/bug.php?id=52064&edit=1
Bug #51705 [Com]: Insecure function without any kind of authentication
Edit report at http://bugs.php.net/bug.php?id=51705&edit=1 ID: 51705 Comment by: anon at anon dot com Reported by: fireburn17 at gmail dot com Summary: Insecure function without any kind of authentication Status: Bogus Type: Bug Package: Mail related Operating System: ANY PHP Version: 5.3.2 New Comment: Congratulations, you discovered how email works. It's not a bug. (You can do exactly the same thing with phone numbers and SMS messages using the right services.) Previous Comments: [2010-04-30 16:18:18] paj...@php.net Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. [2010-04-30 15:42:30] fireburn17 at gmail dot com Description: One can mail anyone using someone else's email address without authentication. No password is required. $to = 'anyb...@example.com' 'From: someonee...@example.com' "SERIOUS SECURITY ISSUE" Bug detected By: DEVESH GOYAL Expected result: Must ask for password for the email address which is used in 'From: someonee...@example.com' "SERIOUS SECURITY ISSUE" Bug detected By: DEVESH GOYAL -- Edit this bug report at http://bugs.php.net/bug.php?id=51705&edit=1
Bug #47630 [Com]: Unknown error using fsockopen() when with php-cgi through php cli
Edit report at http://bugs.php.net/bug.php?id=47630&edit=1
ID: 47630
Comment by: webmaster at gleitgeb dot at
Reported by: metala at metala dot org
Summary: Unknown error using fsockopen() when with php-cgi
through php cli
Status: Closed
Type: Bug
Package: Network related
Operating System: Windows XP SP2
PHP Version: 5.2.9
New Comment:
Is it possible just to add a check if the environment variables are
correct/existing paths?
Otherwise the process should not start or it should add a comment in
some logfile ..
That stupid problem caused me hours of unnecessary work because I could
not find the connection between a wrong environment variable and a not
working socket connection (in my case imap_open didn't work as it always
said "Host not found")
Previous Comments:
[2009-03-18 12:58:11] metala at metala dot org
I don't think "bug" need a fix.
A note in the PHP manual, in proc_open() function or elsewhere, would be
OK.
[2009-03-18 12:50:34] metala at metala dot org
OK, problem solved.
The problem is in the Environment variables of the new process:
$env = array (
'SCRIPT_FILENAME' => dirname(__FILE__).'\\child.php',
);
The missing variable is SystemRoot, which in my case is "C:\WINDOWS".
So with the final settings:
$env = array (
'SCRIPT_FILENAME' => dirname(__FILE__).'\\child.php',
'SystemRoot' => $_ENV['SystemRoot'],
);
Network functionality is working perfectly.
[2009-03-16 21:04:30] metala at metala dot org
It failed again.
As I wrote in the description "any network function fails".
What I did was:
$fp = fsockopen('google.com', 80, $errno, $errstr);
And the result was:
H:\test\php>php parent.php
X-Powered-By: PHP/5.2.9-1
Content-type: text/html
Warning: fsockopen() [function.fsockopen]: php_network_getaddresses: getaddrinfo failed: No such host is known.
in
H:\test\php\child.php on line 2
Warning: fsockopen() [function.fsockopen]: unable to connect to google.com:80 (php_network_getaddresses:
getaddrinfo fa
iled: No such host is known. ) in H:\test\php\child.php on line
2<
br />
int(0)
string(69) "php_network_getaddresses: getaddrinfo failed: No such host
is known.
"
When I run it in DOS:
>SET SCRIPT_FILENAME=child.php
>php-cgi
There appears to be no error.
[2009-03-16 20:37:06] metala at metala dot org
I disabled it before testing.
I have another Windows XP machine I can test on. Results coming soon.
[2009-03-16 19:53:11] johan...@php.net
Are you sure there is no firewall blocking?
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=47630
--
Edit this bug report at http://bugs.php.net/bug.php?id=47630&edit=1
Bug #51184 [ReO->Csd]: DateInterval has incorrect days property on windows
Edit report at http://bugs.php.net/bug.php?id=51184&edit=1
ID: 51184
Updated by: paj...@php.net
Reported by: s...@php.net
Summary: DateInterval has incorrect days property on windows
-Status: Re-Opened
+Status: Closed
Type: Bug
Package: Date/time related
Operating System: Windows
PHP Version: 5.3.2
Assigned To: pajoye
Previous Comments:
[2010-06-05 04:14:23] ric dot lombardi at gmail dot com
randy, this is not a bug. the format %d just shows the difference
between the two
day numbers.
If you want the absolute days difference between the dates, you have to
use "%a"
as format.
[2010-06-04 22:40:51] randy dot larson at veracitynetworks dot com
I have with PHP 5.3.2 on Cent OS 5.4 running the following code from the
CLI:
$datetime1 = new DateTime('2009-10-11');
$datetime2 = new DateTime('2009-11-13');
$interval = $datetime1->sub($datetime2);
echo $interval->format('%R%d days');
This prints "+2 days" where it should print "+33 days". It appears that
it doesn't add the month.
[2010-05-19 16:20:08] s...@php.net
VC6 NTS fails as well here. VC9 NTS works.
[2010-05-19 15:45:07] pluk77 at gmail dot com
Done so. Tested the VC6 and VC9 builds. The VC6 build still has this bug
while the VC9 does not.
[2010-05-19 15:22:51] s...@php.net
Can you try with VC9? Works here on latest VC9 Non Thread Safe
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=51184
--
Edit this bug report at http://bugs.php.net/bug.php?id=51184&edit=1
Bug #51184 [Com]: DateInterval has incorrect days property on windows
Edit report at http://bugs.php.net/bug.php?id=51184&edit=1
ID: 51184
Comment by: pluk77 at gmail dot com
Reported by: s...@php.net
Summary: DateInterval has incorrect days property on windows
Status: Closed
Type: Bug
Package: Date/time related
Operating System: Windows
PHP Version: 5.3.2
Assigned To: pajoye
New Comment:
Is this bug closed because it is now fixed in VC6 as well, or because it
is seen as not a bug?
Previous Comments:
[2010-06-05 04:14:23] ric dot lombardi at gmail dot com
randy, this is not a bug. the format %d just shows the difference
between the two
day numbers.
If you want the absolute days difference between the dates, you have to
use "%a"
as format.
[2010-06-04 22:40:51] randy dot larson at veracitynetworks dot com
I have with PHP 5.3.2 on Cent OS 5.4 running the following code from the
CLI:
$datetime1 = new DateTime('2009-10-11');
$datetime2 = new DateTime('2009-11-13');
$interval = $datetime1->sub($datetime2);
echo $interval->format('%R%d days');
This prints "+2 days" where it should print "+33 days". It appears that
it doesn't add the month.
[2010-05-19 16:20:08] s...@php.net
VC6 NTS fails as well here. VC9 NTS works.
[2010-05-19 15:45:07] pluk77 at gmail dot com
Done so. Tested the VC6 and VC9 builds. The VC6 build still has this bug
while the VC9 does not.
[2010-05-19 15:22:51] s...@php.net
Can you try with VC9? Works here on latest VC9 Non Thread Safe
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=51184
--
Edit this bug report at http://bugs.php.net/bug.php?id=51184&edit=1
Bug #47304 [Com]: typecast of numeric string to float produces strange result
Edit report at http://bugs.php.net/bug.php?id=47304&edit=1
ID: 47304
Comment by: xiaobo dot bob at gmail dot com
Reported by: lennartvdd at mailordersolutions dot nl
Summary: typecast of numeric string to float produces strange
result
Status: Feedback
Type: Bug
Package: Scripting Engine problem
Operating System: win32 only
PHP Version: 5.2.9
Assigned To: pajoye
New Comment:
i just changed the number several time, larger or zero, but i don't know
which takes the effects.
i think the problem is in the function "number_format".
now in my envirentment,
"echo number_format(17.0,0)" is correct, result: 17
"echo number_format(17.0,1)" is wrong, result: 16.:
"echo number_format(17.0,3)" is wrong, result: 16.:00
Previous Comments:
[2010-06-14 10:39:00] paj...@php.net
xiaobo dot bob at gmail dot com:
Which setting do you use for "precision" and "serialize_precision"?
[2010-06-14 10:37:04] xiaobo dot bob at gmail dot com
2010-06-14 09:30:45 BST
I have reproduced this bug, but after changed some setting: change the
"precision" and "serialize_precision" setting in php.ini, and even
changed back, or maybe after i added the printf("%.2f\n",$v2), the echo
$v2 is correctted, but the printf result is always 16.:
finally, i wrote such a script:
for ($i=0; $i<400; $i++)
{
echo $i."-";
printf("%f\n",$i);
}
and found there're 8 number have this bug, they are:
17
19
29
39
170
190
290
390
I'm using windows xp in a virtualbox virtual machine, and a delphi
component named php4delphi, the php version is 5.2.13
[2009-12-23 07:22:24] p dot klein at letsmakesense dot de
I experienced this issue using the number_format() and round()-function.
My example page displays items in a price list and prices like '17' or
'19' (only even numbers) were converted to '16.:' and '18.:'. The weird
thing was that every fourth reload the prices were converted correctly
to '17,00' and '19,00'. The situation improved after I calculated the
floats with BCMath functions. Now three out of four conversions were
correct.
Next thing I tried was to play with the precision setting of php. After
changing the value to '13' the conversion problem disappeared. But even
after changing it back to the default setting the issue hasn't occurred
anymore.
I don't trust the situation. The bug probably still exists, but it's
very hard to reproduce. We didn't have the bug while we used version
5.2.0, but it happened with 5.2.12 and 5.3.1.
Our system:
Windows Server 2003 R2, Standard Edition, Service Pack 2
Intel Core 2 CPU 6600 @ 2.40 GHz, 3,99 GB RAM
PHP Version 5.2.12
[2009-09-28 09:58:07] egorich at junik dot lv
Seems that it fixed with rolling back to php 5.2.5 to me.
[2009-06-22 16:21:28] ciudadsatan at hotmail dot com
The bug in Linux happens with
echo 0.15-0.05;
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=47304
--
Edit this bug report at http://bugs.php.net/bug.php?id=47304&edit=1
Bug #51184 [Csd->Wfx]: DateInterval has incorrect days property on windows
Edit report at http://bugs.php.net/bug.php?id=51184&edit=1
ID: 51184
Updated by: paj...@php.net
Reported by: s...@php.net
Summary: DateInterval has incorrect days property on windows
-Status: Closed
+Status: Wont fix
Type: Bug
Package: Date/time related
Operating System: Windows
PHP Version: 5.3.2
Assigned To: pajoye
New Comment:
Sorry, I meant won't fix. It is not something we can easily fix, use the
VC9 versions instead (apachelounge.com for the VC9 versions of apache).
Previous Comments:
[2010-06-14 12:43:28] pluk77 at gmail dot com
Is this bug closed because it is now fixed in VC6 as well, or because it
is seen as not a bug?
[2010-06-05 04:14:23] ric dot lombardi at gmail dot com
randy, this is not a bug. the format %d just shows the difference
between the two
day numbers.
If you want the absolute days difference between the dates, you have to
use "%a"
as format.
[2010-06-04 22:40:51] randy dot larson at veracitynetworks dot com
I have with PHP 5.3.2 on Cent OS 5.4 running the following code from the
CLI:
$datetime1 = new DateTime('2009-10-11');
$datetime2 = new DateTime('2009-11-13');
$interval = $datetime1->sub($datetime2);
echo $interval->format('%R%d days');
This prints "+2 days" where it should print "+33 days". It appears that
it doesn't add the month.
[2010-05-19 16:20:08] s...@php.net
VC6 NTS fails as well here. VC9 NTS works.
[2010-05-19 15:45:07] pluk77 at gmail dot com
Done so. Tested the VC6 and VC9 builds. The VC6 build still has this bug
while the VC9 does not.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=51184
--
Edit this bug report at http://bugs.php.net/bug.php?id=51184&edit=1
Bug #47304 [Fbk]: typecast of numeric string to float produces strange result
Edit report at http://bugs.php.net/bug.php?id=47304&edit=1
ID: 47304
Updated by: paj...@php.net
Reported by: lennartvdd at mailordersolutions dot nl
Summary: typecast of numeric string to float produces strange
result
Status: Feedback
Type: Bug
Package: Scripting Engine problem
Operating System: win32 only
PHP Version: 5.2.9
Assigned To: pajoye
New Comment:
Which settings were used when you get these results? simply use ini_set
to fetch them.
Previous Comments:
[2010-06-14 12:48:02] xiaobo dot bob at gmail dot com
i just changed the number several time, larger or zero, but i don't know
which takes the effects.
i think the problem is in the function "number_format".
now in my envirentment,
"echo number_format(17.0,0)" is correct, result: 17
"echo number_format(17.0,1)" is wrong, result: 16.:
"echo number_format(17.0,3)" is wrong, result: 16.:00
[2010-06-14 10:39:00] paj...@php.net
xiaobo dot bob at gmail dot com:
Which setting do you use for "precision" and "serialize_precision"?
[2010-06-14 10:37:04] xiaobo dot bob at gmail dot com
2010-06-14 09:30:45 BST
I have reproduced this bug, but after changed some setting: change the
"precision" and "serialize_precision" setting in php.ini, and even
changed back, or maybe after i added the printf("%.2f\n",$v2), the echo
$v2 is correctted, but the printf result is always 16.:
finally, i wrote such a script:
for ($i=0; $i<400; $i++)
{
echo $i."-";
printf("%f\n",$i);
}
and found there're 8 number have this bug, they are:
17
19
29
39
170
190
290
390
I'm using windows xp in a virtualbox virtual machine, and a delphi
component named php4delphi, the php version is 5.2.13
[2009-12-23 07:22:24] p dot klein at letsmakesense dot de
I experienced this issue using the number_format() and round()-function.
My example page displays items in a price list and prices like '17' or
'19' (only even numbers) were converted to '16.:' and '18.:'. The weird
thing was that every fourth reload the prices were converted correctly
to '17,00' and '19,00'. The situation improved after I calculated the
floats with BCMath functions. Now three out of four conversions were
correct.
Next thing I tried was to play with the precision setting of php. After
changing the value to '13' the conversion problem disappeared. But even
after changing it back to the default setting the issue hasn't occurred
anymore.
I don't trust the situation. The bug probably still exists, but it's
very hard to reproduce. We didn't have the bug while we used version
5.2.0, but it happened with 5.2.12 and 5.3.1.
Our system:
Windows Server 2003 R2, Standard Edition, Service Pack 2
Intel Core 2 CPU 6600 @ 2.40 GHz, 3,99 GB RAM
PHP Version 5.2.12
[2009-09-28 09:58:07] egorich at junik dot lv
Seems that it fixed with rolling back to php 5.2.5 to me.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=47304
--
Edit this bug report at http://bugs.php.net/bug.php?id=47304&edit=1
Bug #47304 [Com]: typecast of numeric string to float produces strange result
Edit report at http://bugs.php.net/bug.php?id=47304&edit=1
ID: 47304
Comment by: xiaobo dot bob at gmail dot com
Reported by: lennartvdd at mailordersolutions dot nl
Summary: typecast of numeric string to float produces strange
result
Status: Feedback
Type: Bug
Package: Scripting Engine problem
Operating System: win32 only
PHP Version: 5.2.9
Assigned To: pajoye
New Comment:
wrong result for the following number is like:
17 - 16.:00
19 - 18.:00
29 - 28.:00
39 - 38.:00
170 - 16:.00
190 - 18:.00
290 - 28:.00
390 - 38:.00
1700 - 1,6:0.00
1900 - 1,8:0.00
Previous Comments:
[2010-06-14 12:53:17] paj...@php.net
Which settings were used when you get these results? simply use ini_set
to fetch them.
[2010-06-14 12:48:02] xiaobo dot bob at gmail dot com
i just changed the number several time, larger or zero, but i don't know
which takes the effects.
i think the problem is in the function "number_format".
now in my envirentment,
"echo number_format(17.0,0)" is correct, result: 17
"echo number_format(17.0,1)" is wrong, result: 16.:
"echo number_format(17.0,3)" is wrong, result: 16.:00
[2010-06-14 10:39:00] paj...@php.net
xiaobo dot bob at gmail dot com:
Which setting do you use for "precision" and "serialize_precision"?
[2010-06-14 10:37:04] xiaobo dot bob at gmail dot com
2010-06-14 09:30:45 BST
I have reproduced this bug, but after changed some setting: change the
"precision" and "serialize_precision" setting in php.ini, and even
changed back, or maybe after i added the printf("%.2f\n",$v2), the echo
$v2 is correctted, but the printf result is always 16.:
finally, i wrote such a script:
for ($i=0; $i<400; $i++)
{
echo $i."-";
printf("%f\n",$i);
}
and found there're 8 number have this bug, they are:
17
19
29
39
170
190
290
390
I'm using windows xp in a virtualbox virtual machine, and a delphi
component named php4delphi, the php version is 5.2.13
[2009-12-23 07:22:24] p dot klein at letsmakesense dot de
I experienced this issue using the number_format() and round()-function.
My example page displays items in a price list and prices like '17' or
'19' (only even numbers) were converted to '16.:' and '18.:'. The weird
thing was that every fourth reload the prices were converted correctly
to '17,00' and '19,00'. The situation improved after I calculated the
floats with BCMath functions. Now three out of four conversions were
correct.
Next thing I tried was to play with the precision setting of php. After
changing the value to '13' the conversion problem disappeared. But even
after changing it back to the default setting the issue hasn't occurred
anymore.
I don't trust the situation. The bug probably still exists, but it's
very hard to reproduce. We didn't have the bug while we used version
5.2.0, but it happened with 5.2.12 and 5.3.1.
Our system:
Windows Server 2003 R2, Standard Edition, Service Pack 2
Intel Core 2 CPU 6600 @ 2.40 GHz, 3,99 GB RAM
PHP Version 5.2.12
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=47304
--
Edit this bug report at http://bugs.php.net/bug.php?id=47304&edit=1
Bug #47494 [Com]: htmlspecialchars does not throw E_WARNING on multibyte problems
Edit report at http://bugs.php.net/bug.php?id=47494&edit=1
ID: 47494
Comment by: trueleader at gmx dot de
Reported by: philipp dot feigl at gmail dot com
Summary: htmlspecialchars does not throw E_WARNING on multibyte
problems
Status: Bogus
Type: Bug
Package: Strings related
Operating System: CentOS5
PHP Version: 5.2.8
New Comment:
Why the developer of the language create a workaround for bad configured
servers and/or applications?
If a configuration variable tells that errors are shown on screen then I
think all errors (dependent on reporting level) are shown - and not that
they can be only logged if the configuration variable is turned off.
I think/hope this is not only my opinion.
We just lost some data, because we fill a JS confirm message on a HTML
click event with a string from a PHP language variable. Nobody knows
that we missed to utf8_encode because all developers use display_errors
on and therefor no error is shown/logged for this problem
Previous Comments:
[2009-11-20 20:24:21] s...@php.net
The idea is to return an error but not display it (i.e. log it or allow
custom error handlers to process it).
The reason for it is that, unfortunately, people run servers in
production with display_errors=On, and php_escape_html_entities_ex can
be triggered from all kinds of code that usually doesn't produce errors,
which can reveal sensitive information on public sites. So we chose to
go after lesser of two evils and not generate the error in this
context.
For debugging, I would suggest always logging errors and checking the
error log, as some errors may be hard to spot in display anyway
(especially true if your script produces something like JSON).
[2009-02-25 13:48:11] j...@php.net
It's intentional. If you disagree, please ask s...@php.net why it is
like this (I once reverted that :)
[2009-02-24 13:57:32] philipp dot feigl at gmail dot com
Description:
When using htmlspecialchars with a invalid multibyte string and using
UTF-8 as encoding, there are two possible outcomes based on the
"display_errors" ini setting:
1. display_errors=1
=> empty string is returned
2. display_errors=0
=> E_WARNING is thrown
This is exactly what the code states. Can be viewed in
http://cvs.php.net/viewvc.cgi/php-src/ext/standard/html.c?view=markup
on line 1147
However this is VERY confusing as a developer point of view. As I have
display_errors always set to "1" for debugging purposes, I never
realized, one of our locale strings was corrupt, as it was just emptied
out.
Now in the production environment, our error handler terminates the
script because of the E_WARNING beeing thrown.
While both of the ways (empty string / error) are acceptable for me -
because ofcourse the input string is invalid, it is very confusing to
have different behaviors of PHP based on the display_errors setting.
Reproduce code:
---
echo 'a' . htmlspecialchars(substr(utf8_encode('aü'), 0, 2), ENT_QUOTES,
'UTF-8') . 'b';
Expected result:
Either 'ab'
Or PHP E_WARNING
However not both based on display_errors
Actual result:
--
display_errors=1 => 'ab'
display_errors=0 => E_WARNING
--
Edit this bug report at http://bugs.php.net/bug.php?id=47494&edit=1
Bug #31481 [Com]: curl isn't following redirects with a relative path
Edit report at http://bugs.php.net/bug.php?id=31481&edit=1 ID: 31481 Comment by: ktcox at rogers dot com Reported by: jason at merchant dot to Summary: curl isn't following redirects with a relative path Status: No Feedback Type: Bug Package: HTTP related Operating System: Windows XP Pro PHP Version: 4.3.10 New Comment: I guess that makes sence. But is there anyway to curl or any way to http post to a completely offline page? The following script might help those who would wish to use a relitive url. It takes the url of the current script and chops off the file name giving you the CWD from the server point of view. http://$_SERVER[SERVER_NAME]"; . strrev($backwards); ?> then you would use curl_init($dir/script.php); Previous Comments: [2010-06-14 01:48:59] ras...@php.net Those are not supposed to work. curl_init() takes a URL. None of the arguments in your example that don't work are URLs. [2010-06-14 00:15:42] ktcox at rogers dot com This Works http://localhost/updateindex.php'); $page = curl_exec($addpage); curl_close($addpage); echo "$page"; ?> The following don't work. [2005-01-31 22:34:22] sni...@php.net No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2005-01-11 04:54:37] sni...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try avoid embedding huge scripts into the report. [2005-01-11 00:07:59] jason at merchant dot to Description: I am grabbing an https:// page using curl and that page redirects using a relative path like "/page1.php". curl is failing to follow this path. I have tried replacing the relative path with an absolute path on the page I'm grabbing and that worked so I know the problem lies in the relative path redirection. -- Edit this bug report at http://bugs.php.net/bug.php?id=31481&edit=1
Bug #47304 [Com]: typecast of numeric string to float produces strange result
Edit report at http://bugs.php.net/bug.php?id=47304&edit=1
ID: 47304
Comment by: xiaobo dot bob at gmail dot com
Reported by: lennartvdd at mailordersolutions dot nl
Summary: typecast of numeric string to float produces strange
result
Status: Feedback
Type: Bug
Package: Scripting Engine problem
Operating System: win32 only
PHP Version: 5.2.9
Assigned To: pajoye
New Comment:
i tried set precision to 5/14/20, and keep the serialize_precision =
100.
"echo number_format(1900.0,2)" is always wrong.
here is my code:
echo ini_get("precision")."/".ini_get("serialize_precision")."";
echo number_format(1900.0,2)."---\n";
Previous Comments:
[2010-06-14 12:54:30] xiaobo dot bob at gmail dot com
wrong result for the following number is like:
17 - 16.:00
19 - 18.:00
29 - 28.:00
39 - 38.:00
170 - 16:.00
190 - 18:.00
290 - 28:.00
390 - 38:.00
1700 - 1,6:0.00
1900 - 1,8:0.00
[2010-06-14 12:53:17] paj...@php.net
Which settings were used when you get these results? simply use ini_set
to fetch them.
[2010-06-14 12:48:02] xiaobo dot bob at gmail dot com
i just changed the number several time, larger or zero, but i don't know
which takes the effects.
i think the problem is in the function "number_format".
now in my envirentment,
"echo number_format(17.0,0)" is correct, result: 17
"echo number_format(17.0,1)" is wrong, result: 16.:
"echo number_format(17.0,3)" is wrong, result: 16.:00
[2010-06-14 10:39:00] paj...@php.net
xiaobo dot bob at gmail dot com:
Which setting do you use for "precision" and "serialize_precision"?
[2010-06-14 10:37:04] xiaobo dot bob at gmail dot com
2010-06-14 09:30:45 BST
I have reproduced this bug, but after changed some setting: change the
"precision" and "serialize_precision" setting in php.ini, and even
changed back, or maybe after i added the printf("%.2f\n",$v2), the echo
$v2 is correctted, but the printf result is always 16.:
finally, i wrote such a script:
for ($i=0; $i<400; $i++)
{
echo $i."-";
printf("%f\n",$i);
}
and found there're 8 number have this bug, they are:
17
19
29
39
170
190
290
390
I'm using windows xp in a virtualbox virtual machine, and a delphi
component named php4delphi, the php version is 5.2.13
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=47304
--
Edit this bug report at http://bugs.php.net/bug.php?id=47304&edit=1
[PHP-BUG] Bug #52081 [NEW]: SOAPClient makes calls, throws weird Exception anyway
From: Operating system: Linux (Debian/Ubuntu) PHP version: 5.3.2 Package: SOAP related Bug Type: Bug Bug description:SOAPClient makes calls, throws weird Exception anyway Description: I'm trying to get a SOAPClient call to work which HAS worked (about half a year ago), but which now throws weird Exceptions, even though the call is made. Unzip http://jayvee.nl/soaptest.zip and open soaptest.php. (Note that the WSDL specifies a URL for the service which is on our development environment. You can use this URL if you want.) The script tries to call the same operation four times. The different scenarios are: a) WSDL specifies output, SOAPClient uses SOAP_WAIT_ONE_WAY_CALLS feature b) WSDL specifies output, SOAPClient does NOT use SOAP_WAIT_ONE_WAY_CALLS feature c) WSDL specifies NO output, SOAPClient uses SOAP_WAIT_ONE_WAY_CALLS feature d) WSDL specifies NO output, SOAPClient does NOT use SOAP_WAIT_ONE_WAY_CALLS feature In each case, a call IS MADE. However, in cases a-c, I get an Exception: "SoapFault exception: [WSDL] SOAP-ERROR: Parsing WSDL: Couldn't load from 'implementations/nsure/interface/WizBizzInterface.wsdl' : failed to load external entity "implementations/nsure/interface/WizBizzInterface.wsdl" I have no idea where this path comes from. I _have_ used this in the past, but the test case does not use it. It seems this fault description has gotten stuck somewhere. I have disabled APC, checked for cached WSDLs in /tmp and rebooted the (virtual) machine, to no avail. Case d returns NULL, which is correct (WSDL operation specifies NO output). Note that although the SOAPClient uses the same WSDL as in case c, now it is not complaining about an unfindable path. I have tested this on PHP 5.2.13 (Ubuntu) and 5.3.2 (Debian), both using Suhosin patch, on Apache 2.2.x. -- I really hope this gets fixed soon, because I need to take this into production in a month or two. However, since three other SOAP bug reports (49155, 49169, 49278) haven't been addressed for almost a year, I'm left wondering whether I should have spent time creating a fourth bug report instead of looking for an alternative (nuSOAP or something). Test script: --- Download http://jayvee.nl/soaptest.zip and run the php script. Expected result: Web service return parameter Actual result: -- SoapFault exception: [WSDL] SOAP-ERROR: Parsing WSDL: Couldn't load from 'implementations/nsure/interface/WizBizzInterface.wsdl' : failed to load external entity "implementations/nsure/interface/WizBizzInterface.wsdl -- Edit bug report at http://bugs.php.net/bug.php?id=52081&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52081&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52081&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52081&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52081&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52081&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52081&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52081&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52081&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52081&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52081&r=support Expected behavior: http://bugs.php.net/fix.php?id=52081&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52081&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52081&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52081&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52081&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52081&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52081&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52081&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52081&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52081&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52081&r=mysqlcfg
Bug #52081 [Opn->Csd]: SOAPClient makes calls, throws weird Exception anyway
Edit report at http://bugs.php.net/bug.php?id=52081&edit=1 ID: 52081 User updated by: jeroen at asystance dot nl Reported by: jeroen at asystance dot nl Summary: SOAPClient makes calls, throws weird Exception anyway -Status: Open +Status: Closed Type: Bug Package: SOAP related Operating System: Linux (Debian/Ubuntu) PHP Version: 5.3.2 New Comment: sorry, bogus bug report! Previous Comments: [2010-06-14 14:38:24] jeroen at asystance dot nl Description: I'm trying to get a SOAPClient call to work which HAS worked (about half a year ago), but which now throws weird Exceptions, even though the call is made. Unzip http://jayvee.nl/soaptest.zip and open soaptest.php. (Note that the WSDL specifies a URL for the service which is on our development environment. You can use this URL if you want.) The script tries to call the same operation four times. The different scenarios are: a) WSDL specifies output, SOAPClient uses SOAP_WAIT_ONE_WAY_CALLS feature b) WSDL specifies output, SOAPClient does NOT use SOAP_WAIT_ONE_WAY_CALLS feature c) WSDL specifies NO output, SOAPClient uses SOAP_WAIT_ONE_WAY_CALLS feature d) WSDL specifies NO output, SOAPClient does NOT use SOAP_WAIT_ONE_WAY_CALLS feature In each case, a call IS MADE. However, in cases a-c, I get an Exception: "SoapFault exception: [WSDL] SOAP-ERROR: Parsing WSDL: Couldn't load from 'implementations/nsure/interface/WizBizzInterface.wsdl' : failed to load external entity "implementations/nsure/interface/WizBizzInterface.wsdl" I have no idea where this path comes from. I _have_ used this in the past, but the test case does not use it. It seems this fault description has gotten stuck somewhere. I have disabled APC, checked for cached WSDLs in /tmp and rebooted the (virtual) machine, to no avail. Case d returns NULL, which is correct (WSDL operation specifies NO output). Note that although the SOAPClient uses the same WSDL as in case c, now it is not complaining about an unfindable path. I have tested this on PHP 5.2.13 (Ubuntu) and 5.3.2 (Debian), both using Suhosin patch, on Apache 2.2.x. -- I really hope this gets fixed soon, because I need to take this into production in a month or two. However, since three other SOAP bug reports (49155, 49169, 49278) haven't been addressed for almost a year, I'm left wondering whether I should have spent time creating a fourth bug report instead of looking for an alternative (nuSOAP or something). Test script: --- Download http://jayvee.nl/soaptest.zip and run the php script. Expected result: Web service return parameter Actual result: -- SoapFault exception: [WSDL] SOAP-ERROR: Parsing WSDL: Couldn't load from 'implementations/nsure/interface/WizBizzInterface.wsdl' : failed to load external entity "implementations/nsure/interface/WizBizzInterface.wsdl -- Edit this bug report at http://bugs.php.net/bug.php?id=52081&edit=1
Bug #52050 [Fbk->Opn]: PHP-FPM Dies after self-initiating reload
Edit report at http://bugs.php.net/bug.php?id=52050&edit=1 ID: 52050 User updated by: marcus at adolfsson dot com Reported by: marcus at adolfsson dot com Summary: PHP-FPM Dies after self-initiating reload -Status: Feedback +Status: Open Type: Bug Package: FPM related Operating System: fc7 PHP Version: 5.3.2 Assigned To: fat New Comment: Fedora Core 7, libevent-1.4.14-stable Previous Comments: [2010-06-13 13:02:12] f...@php.net Can you also provide the libevent version and the OS you're using. Thanks [2010-06-11 16:27:49] marcus at adolfsson dot com ldd /usr/sbin/php-fpm libcrypt.so.1 => /lib64/libcrypt.so.1 (0x003a8300) libaspell.so.15 => /usr/lib64/libaspell.so.15 (0x003a8600) libpspell.so.15 => /usr/lib64/libpspell.so.15 (0x003a8640) librt.so.1 => /lib64/librt.so.1 (0x003a8180) libmysqlclient.so.15 => /usr/lib64/mysql/libmysqlclient.so.15 (0x0036a360) libmcrypt.so.4 => /usr/lib64/libmcrypt.so.4 (0x00357ba0) libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x0036a320) libpng12.so.0 => /usr/lib64/libpng12.so.0 (0x0036a3e0) libz.so.1 => /usr/lib64/libz.so.1 (0x0035af40) libjpeg.so.62 => /usr/lib64/libjpeg.so.62 (0x003a8700) libcurl.so.3 => /usr/lib64/libcurl.so.3 (0x0035af80) libbz2.so.1 => /usr/lib64/libbz2.so.1 (0x003a8540) libpcre.so.0 => /lib64/libpcre.so.0 (0x0035b040) libm.so.6 => /lib64/libm.so.6 (0x003a80c0) libdl.so.2 => /lib64/libdl.so.2 (0x003a8080) libevent-1.4.so.1 => /usr/local/lib/libevent-1.4.so.1 (0x2aac3000) libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x0036a2e0) libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x003a8440) libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x003a8340) libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x003a83c0) libcom_err.so.2 => /lib64/libcom_err.so.2 (0x003a8280) libssl.so.6 => /lib64/libssl.so.6 (0x0035afc0) libcrypto.so.6 => /lib64/libcrypto.so.6 (0x0035b080) libresolv.so.2 => /lib64/libresolv.so.2 (0x003a82c0) libidn.so.11 => /usr/lib64/libidn.so.11 (0x003a8200) libc.so.6 => /lib64/libc.so.6 (0x003a8040) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x003a8400) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x003a84c0) libpthread.so.0 => /lib64/libpthread.so.0 (0x003a8100) /lib64/ld-linux-x86-64.so.2 (0x003a8000) libnsl.so.1 => /lib64/libnsl.so.1 (0x003a8240) libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x003a8480) [2010-06-11 16:10:16] tony2...@php.net Please also show the output of `ldd /path/to/php-fpm`. Thanks. [2010-06-11 15:36:27] marcus at adolfsson dot com This is my conf file: ; ; FPM Configuration ; ; ;include=/etc/fpm.d/*.conf ;; ; Global Options ; ;; [global] pid = /usr/logs/php-fpm.pid error_log = /usr/logs/php-fpm.log ; Log level ; Possible Values: alert, error, warning, notice, debug log_level = notice ; If this number of child processes exit with SIGSEGV or SIGBUS within the time ; interval set by emergency_restart_interval then FPM will restart. A value ; of '0' means 'Off'. ; Default Value: 0 emergency_restart_threshold = 10 ; Interval of time used by emergency_restart_interval to determine when ; a graceful restart will be initiated. This can be useful to work around ; accidental corruptions in an accelerator's shared memory. ; Available Units: s(econds), m(inutes), h(ours), or d(ays) ; Default Unit: seconds ; Default Value: 0 emergency_restart_interval = 1m ; Time limit for child processes to wait for a reaction on signals from master. ; Available units: s(econds), m(inutes), h(ours), or d(ays) ; Default Unit: seconds ; Default Value: 0 process_control_timeout = 5s ; Send FPM to background. Set to 'no' to keep FPM in foreground for debugging. ; Default Value: yes daemonize = yes ; Pool Definitions ; ; Multiple pools of child processes may be started with different listening ; ports and different management options. The name of the pool will be ; used in logs and stats. There is no limitation on the number of pools which ; FPM can handle. Y
[PHP-BUG] Bug #52082 [NEW]: character_set_client & character_set_connection reset after mysqli_change_user
From: Operating system: All PHP version: 5.3SVN-2010-06-14 (SVN) Package: MySQLi related Bug Type: Bug Bug description:character_set_client & character_set_connection reset after mysqli_change_user Description: After calling mysqli_change_user() character_set_client and character_set_result are reset to the server defaults. If the client has set a different one with mysqli_options() or mysqli_set_character_set() it will be lost. The MySQL server supports from version 5.1.23 setting of a charset during COM_CHANGE_USER, an extension in the protocol. Older versions doesn't support it and need explicit call to mysql_set_character_set(). Expected result: Keep the old character_set_client/connection. -- Edit bug report at http://bugs.php.net/bug.php?id=52082&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52082&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52082&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52082&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52082&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52082&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52082&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52082&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52082&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52082&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52082&r=support Expected behavior: http://bugs.php.net/fix.php?id=52082&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52082&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52082&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52082&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52082&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52082&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52082&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52082&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52082&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52082&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52082&r=mysqlcfg
Bug #52082 [Opn->Ver]: character_set_client & character_set_connection reset after mysqli_change_user
Edit report at http://bugs.php.net/bug.php?id=52082&edit=1 ID: 52082 Updated by: and...@php.net Reported by: and...@php.net Summary: character_set_client & character_set_connection reset after mysqli_change_user -Status: Open +Status: Verified Type: Bug Package: MySQLi related Operating System: All PHP Version: 5.3SVN-2010-06-14 (SVN) -Assigned To: +Assigned To: mysql Previous Comments: [2010-06-14 18:28:21] and...@php.net Description: After calling mysqli_change_user() character_set_client and character_set_result are reset to the server defaults. If the client has set a different one with mysqli_options() or mysqli_set_character_set() it will be lost. The MySQL server supports from version 5.1.23 setting of a charset during COM_CHANGE_USER, an extension in the protocol. Older versions doesn't support it and need explicit call to mysql_set_character_set(). Expected result: Keep the old character_set_client/connection. -- Edit this bug report at http://bugs.php.net/bug.php?id=52082&edit=1
Bug #52081 [Csd->Bgs]: SOAPClient makes calls, throws weird Exception anyway
Edit report at http://bugs.php.net/bug.php?id=52081&edit=1 ID: 52081 Updated by: srina...@php.net Reported by: jeroen at asystance dot nl Summary: SOAPClient makes calls, throws weird Exception anyway -Status: Closed +Status: Bogus Type: Bug Package: SOAP related Operating System: Linux (Debian/Ubuntu) PHP Version: 5.3.2 New Comment: mark the bug as bogus to make it appropriate. Previous Comments: [2010-06-14 15:31:36] jeroen at asystance dot nl sorry, bogus bug report! [2010-06-14 14:38:24] jeroen at asystance dot nl Description: I'm trying to get a SOAPClient call to work which HAS worked (about half a year ago), but which now throws weird Exceptions, even though the call is made. Unzip http://jayvee.nl/soaptest.zip and open soaptest.php. (Note that the WSDL specifies a URL for the service which is on our development environment. You can use this URL if you want.) The script tries to call the same operation four times. The different scenarios are: a) WSDL specifies output, SOAPClient uses SOAP_WAIT_ONE_WAY_CALLS feature b) WSDL specifies output, SOAPClient does NOT use SOAP_WAIT_ONE_WAY_CALLS feature c) WSDL specifies NO output, SOAPClient uses SOAP_WAIT_ONE_WAY_CALLS feature d) WSDL specifies NO output, SOAPClient does NOT use SOAP_WAIT_ONE_WAY_CALLS feature In each case, a call IS MADE. However, in cases a-c, I get an Exception: "SoapFault exception: [WSDL] SOAP-ERROR: Parsing WSDL: Couldn't load from 'implementations/nsure/interface/WizBizzInterface.wsdl' : failed to load external entity "implementations/nsure/interface/WizBizzInterface.wsdl" I have no idea where this path comes from. I _have_ used this in the past, but the test case does not use it. It seems this fault description has gotten stuck somewhere. I have disabled APC, checked for cached WSDLs in /tmp and rebooted the (virtual) machine, to no avail. Case d returns NULL, which is correct (WSDL operation specifies NO output). Note that although the SOAPClient uses the same WSDL as in case c, now it is not complaining about an unfindable path. I have tested this on PHP 5.2.13 (Ubuntu) and 5.3.2 (Debian), both using Suhosin patch, on Apache 2.2.x. -- I really hope this gets fixed soon, because I need to take this into production in a month or two. However, since three other SOAP bug reports (49155, 49169, 49278) haven't been addressed for almost a year, I'm left wondering whether I should have spent time creating a fourth bug report instead of looking for an alternative (nuSOAP or something). Test script: --- Download http://jayvee.nl/soaptest.zip and run the php script. Expected result: Web service return parameter Actual result: -- SoapFault exception: [WSDL] SOAP-ERROR: Parsing WSDL: Couldn't load from 'implementations/nsure/interface/WizBizzInterface.wsdl' : failed to load external entity "implementations/nsure/interface/WizBizzInterface.wsdl -- Edit this bug report at http://bugs.php.net/bug.php?id=52081&edit=1
Bug #51988 [Opn->Bgs]: No input file specfied when trying to exec any PHP script from Web Server
Edit report at http://bugs.php.net/bug.php?id=51988&edit=1
ID: 51988
Updated by: srina...@php.net
Reported by: pedro dot galan at cscamaras dot es
Summary: No input file specfied when trying to exec any PHP
script from Web Server
-Status: Open
+Status: Bogus
Type: Bug
Package: CGI related
Operating System: SunOS 5.8 sparc
PHP Version: 5.2.13
New Comment:
This is not a PHP bug but a configuration issue.
Please contact the ariate web server forum in this case
http://forums.sun.com/forum.jspa?forumID=759 and post your question
there.
Previous Comments:
[2010-06-10 21:47:15] pedro dot galan at cscamaras dot es
I've verfied that scripts using PHP Cli executable work fine with my Web
Server but the problem with PHP Cgi executable ramain the same.
So, PHP Cli allows to execute PHP scripts across Sun Java System Web
Server 6.1 but PHP Cgi products "no input file specified".
[2010-06-03 14:03:53] pedro dot galan at cscamaras dot es
Description:
When trying to run any PHP script from my Web Server (Sun Java System
Web Server 6.1) as CGI always get "No input file specified".
Configure options:
./configure --with-curl --with-mysql=/usr/local/mysql
--prefix=/usr/local/php5 --with-config-file-path=/usr/local/php5/lib
-enable-force-cgi-redirect
Changed PUTS("No input file specifiedd.\n"); by
PUTS(zend_printf("%s",file_handle.filename)); at line 1947 in cgi_main.c
and what i can see at the browser is (null) so the problem is with
path_translated for sure.
I've a lot of PHPP4.1 scripts running at the same Web server so the
configurantion is the same. It is not too probalbe that the problem is
at the Web Server.
Thanks a lot.
Test script:
---
matrix /data/web_html/publicado/empresafamiliar/php5 425 #more
phpinfo5.php
#!/usr/local/bin/php5
Expected result:
I expect an HTML page with the result of the phpinfo function.
Actual result:
--
No input file specified
--
Edit this bug report at http://bugs.php.net/bug.php?id=51988&edit=1
[PHP-BUG] Bug #52083 [NEW]: Fatal Error "Call to a member function * on a non-object" occurring randomly
From:
Operating system: CentOS 5.4
PHP version: 5.3.2
Package: *General Issues
Bug Type: Bug
Bug description:Fatal Error "Call to a member function * on a non-object"
occurring randomly
Description:
We have several servers running PHP 5.3.2 on CentOS 5.4 and a few on PHP
5.2.9
on FreeBSD. Reviewing our error logs, I have noticed a pattern of fatal
errors:
"Call to a member function * on a non-object". This occurs usually daily,
and
sometimes several times a day. When it occurs, it occurs on a single
server,
several times over a 2-3 minute span, and across different PHP sessions and
occurs in different functions in different classes. This issue does not
seem to
coincide with high traffic or with time of day. This issue has occurred on
each
of the webservers running CentOS, although I have noticed it occurring over
several releases of PHP. There are no other fatal PHP errors that occur
concurrently, nor are there any other external processes that are occurring
concurrently.
The only thing I can suspect is PHP garbage collection improperly deleting
objects, although debug_zval_dump() shows the object correctly constructed
and
never destructed prior to calling a member function.
After seeing this error occur on several functions in various classes, I
picked
one and added code to check is_object() and email me the results of
debug_zval_dump() when false. Although is_object() returns false, the dump
of
the object shows the following:
if (!is_object($this->flow_info))
{
debug_zval_dump($this);
}
output:
object(SEFlow)#13 (10) refcount(5){
...
["flow_info"]=>
object(FlowInfo)#14 (4) refcount(1){
...
Calling a function:
$this->flow_info->getElementsUnderBranch(__MAIN_BRANCH, false);
results in the fatal error:
Call to a member function getElementsUnderBranch() on a non-object in
/var/www/Qualtrics/Qualtrics/SurveyEngine/Flow/Flow.php on line 186
--
Edit bug report at http://bugs.php.net/bug.php?id=52083&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52083&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52083&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52083&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52083&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52083&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52083&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52083&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52083&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52083&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52083&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52083&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52083&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52083&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52083&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52083&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52083&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52083&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52083&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52083&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52083&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52083&r=mysqlcfg
Bug #47304 [Com]: typecast of numeric string to float produces strange result
Edit report at http://bugs.php.net/bug.php?id=47304&edit=1
ID: 47304
Comment by: xiaobo dot bob at gmail dot com
Reported by: lennartvdd at mailordersolutions dot nl
Summary: typecast of numeric string to float produces strange
result
Status: Feedback
Type: Bug
Package: Scripting Engine problem
Operating System: win32 only
PHP Version: 5.2.9
Assigned To: pajoye
New Comment:
I have a win32 program writing in delphi using the component php4delphi
that can reproduce this problem. if someone need it, i can email it to
you.
or if some one can help me to compile php under vc6 with the .dsp (I can
compile 5.3.2 using nmake of vc++9, with the step-by-step direction of
the manual, but failed to compile using .dsp project). i have tried to
use the windbg.exe with the downloaded debug pack to trace into the
code, it seems the problem happens in the function php_conv_fp in
snprintf.c, but as the local variables always "memory access error", i
can't make any progress.
Previous Comments:
[2010-06-14 14:29:27] xiaobo dot bob at gmail dot com
i tried set precision to 5/14/20, and keep the serialize_precision =
100.
"echo number_format(1900.0,2)" is always wrong.
here is my code:
echo ini_get("precision")."/".ini_get("serialize_precision")."";
echo number_format(1900.0,2)."---\n";
[2010-06-14 12:54:30] xiaobo dot bob at gmail dot com
wrong result for the following number is like:
17 - 16.:00
19 - 18.:00
29 - 28.:00
39 - 38.:00
170 - 16:.00
190 - 18:.00
290 - 28:.00
390 - 38:.00
1700 - 1,6:0.00
1900 - 1,8:0.00
[2010-06-14 12:53:17] paj...@php.net
Which settings were used when you get these results? simply use ini_set
to fetch them.
[2010-06-14 12:48:02] xiaobo dot bob at gmail dot com
i just changed the number several time, larger or zero, but i don't know
which takes the effects.
i think the problem is in the function "number_format".
now in my envirentment,
"echo number_format(17.0,0)" is correct, result: 17
"echo number_format(17.0,1)" is wrong, result: 16.:
"echo number_format(17.0,3)" is wrong, result: 16.:00
[2010-06-14 10:39:00] paj...@php.net
xiaobo dot bob at gmail dot com:
Which setting do you use for "precision" and "serialize_precision"?
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=47304
--
Edit this bug report at http://bugs.php.net/bug.php?id=47304&edit=1
Bug #51243 [Fbk->Opn]: syntax error in autoload causes segmentation fault
Edit report at http://bugs.php.net/bug.php?id=51243&edit=1
ID: 51243
User updated by: tsamukawa at maru dot jp
Reported by: tsamukawa at maru dot jp
Summary: syntax error in autoload causes segmentation fault
-Status: Feedback
+Status: Open
Type: Bug
Package: Scripting Engine problem
Operating System: CentOS5.*
PHP Version: 5.3.2
New Comment:
I think this segfault would be occured by these steps:
First, An apache`s process receives a http request. Correct output is
produced
like "syntax error, unexpected ...". It`s seems to be no problem.
Next, the identical apache`s child process receives a request, It
produces empty
responce ("SYSSEGV" error message is saved in error_log).
Apache server version is 2.2.14.
Previous Comments:
[2010-06-08 15:04:12] tony2...@php.net
Not reproducible.
The only result I'm able to get is this:
Parse error: syntax error, unexpected T_STRING, expecting T_FUNCTION in
/tmp/C.php on line 4
[2010-03-11 02:34:07] tsamukawa at maru dot jp
I have 2 different backtraces generated.
1st bt is geneated by running same script as the sample.
2nd bt is by script uses calling spl_autoload_register() from inside of
another user-defined function.
---
Program received signal SIGSEGV, Segmentation fault.
0xb77c8b44 in autoload_func_info_dtor (alfi=0x7373616c) at
/s/php-5.3.2/ext/spl/php_spl.c:362
362 if (alfi->obj) {
(gdb) bt
#0 0xb77c8b44 in autoload_func_info_dtor (alfi=0x7373616c) at
/s/php-5.3.2/ext/spl/php_spl.c:362
#1 0xb7966728 in zend_hash_destroy (ht=0x8412154) at
/s/php-5.3.2/Zend/zend_hash.c:526
#2 0xb77cb7a5 in zm_deactivate_spl (type=1, module_number=20) at
/s/php-5.3.2/ext/spl/php_spl.c:904
#3 0xb795fffc in module_registry_cleanup (module=0x82abd10) at
/s/php-5.3.2/Zend/zend_API.c:2150
#4 0xb7966f96 in zend_hash_reverse_apply (ht=0xb7ecaaa0,
apply_func=0xb795ffcd ) at /s/php-
5.3.2/Zend/zend_hash.c:755
#5 0xb7957950 in zend_deactivate_modules () at
/s/php-5.3.2/Zend/zend.c:866
#6 0xb78eb409 in php_request_shutdown (dummy=0x0) at
/s/php-5.3.2/main/main.c:1607
#7 0xb7a21b2d in php_apache_request_dtor (r=0x83971e0) at
/s/php-5.3.2/sapi/apache2handler/sapi_apache2.c:495
#8 0xb7a2241e in php_handler (r=0x83971e0) at
/s/php-5.3.2/sapi/apache2handler/sapi_apache2.c:667
#9 0x0807f629 in ap_run_handler (r=0x83971e0) at config.c:157
#10 0x08082797 in ap_invoke_handler (r=0x83971e0) at config.c:372
#11 0x080d64f8 in ap_process_request (r=0x83971e0) at
http_request.c:282
#12 0x080d36db in ap_process_http_connection (c=0x83d9810) at
http_core.c:190
#13 0x08086769 in ap_run_process_connection (c=0x83d9810) at
connection.c:43
#14 0x08104f1d in child_main (child_num_arg=) at
prefork.c:662
#15 0x08105163 in make_child (s=0x8152c98, slot=0) at prefork.c:702
#16 0x08105f3c in ap_mpm_run (_pconf=0x814a550, plog=0x81a47f8,
s=0x8152c98) at prefork.c:978
#17 0x0806cf25 in main (argc=135562568, argv=0x83d7630) at main.c:740
---
Program received signal SIGSEGV, Segmentation fault.
0xb7ffb402 in __kernel_vsyscall ()
(gdb) bt
#0 0xb7ffb402 in __kernel_vsyscall ()
#1 0x459e61b6 in kill () from /lib/libc.so.6
#2 0xb79e15a1 in zend_mm_panic (message=0xb7f3a690 "zend_mm_heap
corrupted") at /s/php-5.3.2/Zend/zend_alloc.c:92
#3 0xb79e3a2e in _zend_mm_alloc_int (heap=0x8284880, size=49,
__zend_filename=0xb7f3834b "Zend/zend_language_scanner.l",
__zend_lineno=690, __zend_orig_filename=0x0,
__zend_orig_lineno=0) at /s/php-5.3.2/Zend/zend_alloc.c:1827
#4 0xb79e50ff in _emalloc (size=49, __zend_filename=0xb7f3834b
"Zend/zend_language_scanner.l", __zend_lineno=690,
__zend_orig_filename=0x0, __zend_orig_lineno=0)
at /s/php-5.3.2/Zend/zend_alloc.c:2340
#5 0xb79cc147 in zend_multibyte_read_script (buf=0xb7fee000
") at
prefork.c:662
#29 0x08105163 in make_child (s=0x8152c98, slot=0) at prefork.c:702
#30 0x08105f3c in ap_mpm_run (_pconf=0x814a550, plog=0x81a47f8,
s=0x8152c98) at prefork.c:978
#31 0x0806cf25 in main (argc=135562568, argv=0x83d7628) at main.c:740
[2010-03-10 22:13:58] j...@php.net
After disabling ALL 3rd party extensions (opcode caches, debuggers,
etc.) provide a new backtrace of the crash.
[2010-03-10 06:18:57] tsamukawa at maru dot jp
I tryed this script from CLI repeatedly, no segmentation fault was
occured .
[2010-03-10 06:05:45] tsamukawa at maru dot jp
I tested without using eaccelerator and
