Bug #51399 [Fbk->Opn]: *** glibc detected *** /usr/sbin/httpd: double free or corruption (!prev)
Edit report at http://bugs.php.net/bug.php?id=51399&edit=1 ID: 51399 User updated by: jitendra dot admin at gmail dot com Reported by: jitendra dot admin at gmail dot com Summary: *** glibc detected *** /usr/sbin/httpd: double free or corruption (!prev) -Status: Feedback +Status: Open Type: Bug Package: Apache related Operating System: Debian 5.0 -PHP Version: Irrelevant +PHP Version: php 5.1.5 New Comment: === Memory map: 08048000-080ae000 r-xp 68:01 145154 /usr/sbin/httpd 080ae000-080b6000 rw-p 00065000 68:01 145154 /usr/sbin/httpd 080b6000-097d4000 rw-p 080b6000 00:00 0 [heap] b6f0-b6f21000 rw-p b6f0 00:00 0 b6f21000-b700 ---p b6f21000 00:00 0 b704b000-b717e000 r-xp 68:01 144652 /usr/lib/libxml2.so.2.6.32 b717e000-b7183000 rw-p 00132000 68:01 144652 /usr/lib/libxml2.so.2.6.32 b7183000-b7184000 rw-p b7183000 00:00 0 b7184000-b718b000 r--s 68:01 139270 /usr/lib/gconv/gconv-modules.cache b718b000-b7197000 rw-s 00:08 131072 /SYSV (deleted) b71c1000-b72fb000 r--p 68:01 156498 /usr/lib/locale/locale-archive b72fb000-b7305000 r-xp 68:01 2016443 /lib/i686/cmov/libnss_files-2.7.so b7305000-b7307000 rw-p 9000 68:01 2016443 /lib/i686/cmov/libnss_files-2.7.so b7307000-b730f000 r-xp 68:01 2016432 /lib/i686/cmov/libnss_nis-2.7.so b730f000-b7311000 rw-p 8000 68:01 2016432 /lib/i686/cmov/libnss_nis-2.7.so b7311000-b7318000 r-xp 68:01 2016436 /lib/i686/cmov/libnss_compat-2.7.so b7318000-b731a000 rw-p 6000 68:01 2016436 /lib/i686/cmov/libnss_compat-2.7.so b740b000-b7417000 r-xp 68:01 2007043/lib/libgcc_s.so.1 b7417000-b7418000 rw-p b000 68:01 2007043/lib/libgcc_s.so.1 b741e000-b743e000 r-xp 68:01 189105 /usr/lib/perl5/auto/DBI/DBI.so b743e000-b743f000 rw-p 0001f000 68:01 189105 /usr/lib/perl5/auto/DBI/DBI.so b743f000-b744f000 r-xp 68:01 2016442 /lib/i686/cmov/libresolv-2.7.so b744f000-b7451000 rw-p f000 68:01 2016442 /lib/i686/cmov/libresolv-2.7.so b7451000-b7453000 rw-p b7451000 00:00 0 b7453000-b7468000 r-xp 68:01 2016433 /lib/i686/cmov/libnsl-2.7.so b7468000-b746a000 rw-p 00014000 68:01 2016433 /lib/i686/cmov/libnsl-2.7.so b746a000-b746c000 rw-p b746a000 00:00 0 b747-b7474000 r-xp 68:01 2016440 /lib/i686/cmov/libnss_dns-2.7.so b7474000-b7476000 rw-p 3000 68:01 2016440 /lib/i686/cmov/libnss_dns-2.7.so b7476000-b747e000 r-xp 68:01 189901 /usr/local/lib/perl/5.10.0/auto/List/Util/Util.so b747e000-b747f000 rw-p 7000 68:01 189901 /usr/local/lib/perl/5.10.0/auto/List/Util/Util.so b747f000-b7493000 r-xp 68:01 141666 /usr/lib/libz.so.1.2.3.3 b7493000-b7494000 rw-p 00013000 68:01 141666 /usr/lib/libz.so.1.2.3.3 b7494000-b7638000 r-xp 68:01 144709 /usr/lib/libmysqlclient.so.15.0.0 b7638000-b767c000 rw-p 001a3000 68:01 144709 /usr/lib/libmysqlclient.so.15.0.0 b767c000-b767d000 rw-p b767c000 00:00 0 b767d000-b7b5d000 r-xp 68:01 182287 /usr/local/apache-1.3.41-DSO/libexec/libphp5.so b7b5d000-b7bbf000 rw-p 004e 68:01 182287 /usr/local/apache-1.3.41-DSO/libexec/libphp5.so b7bbf000-b7bca000 rw-p b7bbf000 00:00 0 b7bca000-b7d13000 r-xp 68:01 144987 /usr/lib/libperl.so.5.10.0 b7d13000-b7d18000 rw-p 00148000 68:01 144987 /usr/lib/libperl.so.5.10.0 b7d1e000-b7d74000 r-xp 68:01 181556 /usr/local/apache-1.3.41-DSO/libexec/libperl.so b7d74000-b7d75000 rw-p 00056000 68:01 181556 /usr/local/apache-1.3.41-DSO/libexec/libperl.so b7d75000-b7d8b000 r-xp 68:01 181554 /usr/local/apache-1.3.41-DSO/libexec/libproxy.so b7d8b000-b7d8c000 rw-p 00016000 68:01 181554 /usr/local/apache-1.3.41-DSO/libexec/libproxy.so b7d8c000-b7d99000 r-xp 68:01 181553 /usr/local/apache-1.3.41-DSO/libexec/mod_rewrite.so b7d99000-b7d9a000 rw-p c000 68:01 181553 /usr/local/apache-1.3.41-DSO/libexec/mod_rewrite.so b7d9a000-b7d9b000 rw-p b7d9a000 00:00 0 b7d9b000-b7ef r-xp 68:01 2016438 /lib/i686/cmov/libc-2.7.so b7ef-b7ef1000 r--p 00155000 68:01 2016438 /lib/i686/cmov/libc-2.7.so b7ef1000-b7ef3000 rw-p 00156000 68:01 2016438 /lib/i686/cmov/libc-2.7.so b7ef3000-b7ef6000 rw-p b7ef3000 00:00 0 b7ef6000-b7ef8000 r-xp 68:01 2016435 /lib/i686/cmov/libdl-2.7.so b7ef8000-b7efa000 rw-p 1000 68:01 2016435 /lib/i686/cmov/libdl-2.7.so b7efa000-b7f03000 r-xp 68:01 2016427 /lib/i686/cmov/libcrypt-2.7.so b7f03000-b7f05000 rw-p 8000 68:01 2016427 /lib/i686/cmov/libcrypt-2.7.so b7f05000-b7f2d000 rw-p b7f05000 00:00 0 b7f2d000-b7f51000 r-xp 68:01 2016423 /lib/i686/cmov/libm-2.7.so b7f51000-b7f53000 rw-p 00023000 68:01 2016423 /lib/i686/cmov/lib
Bug #51409 [Bgs]: foreach structure pass by reference scope issue
Edit report at http://bugs.php.net/bug.php?id=51409&edit=1
ID: 51409
Updated by: ras...@php.net
Reported by: sramage at nucleuslabs dot com
Summary: foreach structure pass by reference scope issue
Status: Bogus
Type: Bug
Package: Arrays related
Operating System: FREEBSD 8.0
PHP Version: 5.2.13
New Comment:
Ah, your bug title is a bit misleading then. How is this any different
from:
$foo = array(1,2,3);
$ref = &$foo[2];
$bar = $foo;
$ref = 4;
print_r($bar);
No classes or loops required. And yes, the reference to the array
element
survives the copy there.
Previous Comments:
[2010-03-27 01:03:50] sramage at nucleuslabs dot com
Everything you wrote was perfectly correct and I agree completely with
it but that is not the problem.
The problem is that a member of a class is being modified from outside
the class without directly referencing it.
The array $bananas was *copied* to the property $monkey->bananas before
the reference was modified.
$monkey->bananas appears to be the same array in memory as $bananas
(which is how PHP is designed to save on memory usage) at the point
which $bananas gets changed I would expect $monkey->bananas and $bananas
to diverge but they don't.
This is a very minor issue since it would be bad programming practice to
leave a pass by reference variable floating around without using
unset().
[2010-03-26 22:36:25] ras...@php.net
This makes perfect sense. After your first foreach loop, $banana is a
reference
to the last element in your $bananas array. Anything you do to that
$banana
variable is going to affect that last element. So, in your coconut
foreach, you
are now asking PHP to assign the first element of the coconut array to
the last
element of your bananas array which is exactly the output you are
getting. No
bug here.
[2010-03-26 22:31:41] sramage at nucleuslabs dot com
Description:
When an ampersand operator is used in a foreach language construct The
pass by reference variable causes *copies* of the parent array used in
the foreach loop to be modified in any future use of the initial pass by
reference variable.
This is very hard to explain clearly but see the test script below for
clarification it is a very simple test script.'
Similar bugs like this have been reported and documentation outlines a
simple workaround that does work and solves my problem.
but I figured I would report this problem as *copies* of the array are
affected and it seems kind of strange.
Test script:
---
class Monkey{
public $bananas=array();
public function AddBananas($bananas){
$this->bananas=$bananas;
}}
$bananas=array();
$bananas['banana1']=array('color'=>'yellow','size'=>'big');
$bananas['banana2']=array('color'=>'green','size'=>'small');
$coconuts=array();
$coconuts['coconut1']['size']='tiny';
$coconuts['coconut2']['size']="I'm a";
$monkey=new Monkey();
foreach($bananas as $key=>&$banana){
$banana['id']=$key+1;
}
$monkey->AddBananas($bananas);
foreach($coconuts as $banana){
$banana['type']="coconut!";
}
print_r($monkey->bananas);
Expected result:
Array
(
[banana1] => Array
(
[color] => yellow
[size] => big
[id] => 1
)
[banana2] => Array
(
[color] => green
[size] => small
[id] => 2
)
)
Actual result:
--
Array
(
[banana1] => Array
(
[color] => yellow
[size] => big
[id] => 1
)
[banana2] => Array
(
[size] => I'm a
[type] => coconut!
)
)
--
Edit this bug report at http://bugs.php.net/bug.php?id=51409&edit=1
Bug #51409 [Bgs]: foreach structure pass by reference scope issue
Edit report at http://bugs.php.net/bug.php?id=51409&edit=1
ID: 51409
User updated by: sramage at nucleuslabs dot com
Reported by: sramage at nucleuslabs dot com
Summary: foreach structure pass by reference scope issue
Status: Bogus
Type: Bug
Package: Arrays related
Operating System: FREEBSD 8.0
PHP Version: 5.2.13
New Comment:
Everything you wrote was perfectly correct and I agree completely with
it but that is not the problem.
The problem is that a member of a class is being modified from outside
the class without directly referencing it.
The array $bananas was *copied* to the property $monkey->bananas before
the reference was modified.
$monkey->bananas appears to be the same array in memory as $bananas
(which is how PHP is designed to save on memory usage) at the point
which $bananas gets changed I would expect $monkey->bananas and $bananas
to diverge but they don't.
This is a very minor issue since it would be bad programming practice to
leave a pass by reference variable floating around without using
unset().
Previous Comments:
[2010-03-26 22:36:25] ras...@php.net
This makes perfect sense. After your first foreach loop, $banana is a
reference
to the last element in your $bananas array. Anything you do to that
$banana
variable is going to affect that last element. So, in your coconut
foreach, you
are now asking PHP to assign the first element of the coconut array to
the last
element of your bananas array which is exactly the output you are
getting. No
bug here.
[2010-03-26 22:31:41] sramage at nucleuslabs dot com
Description:
When an ampersand operator is used in a foreach language construct The
pass by reference variable causes *copies* of the parent array used in
the foreach loop to be modified in any future use of the initial pass by
reference variable.
This is very hard to explain clearly but see the test script below for
clarification it is a very simple test script.'
Similar bugs like this have been reported and documentation outlines a
simple workaround that does work and solves my problem.
but I figured I would report this problem as *copies* of the array are
affected and it seems kind of strange.
Test script:
---
class Monkey{
public $bananas=array();
public function AddBananas($bananas){
$this->bananas=$bananas;
}}
$bananas=array();
$bananas['banana1']=array('color'=>'yellow','size'=>'big');
$bananas['banana2']=array('color'=>'green','size'=>'small');
$coconuts=array();
$coconuts['coconut1']['size']='tiny';
$coconuts['coconut2']['size']="I'm a";
$monkey=new Monkey();
foreach($bananas as $key=>&$banana){
$banana['id']=$key+1;
}
$monkey->AddBananas($bananas);
foreach($coconuts as $banana){
$banana['type']="coconut!";
}
print_r($monkey->bananas);
Expected result:
Array
(
[banana1] => Array
(
[color] => yellow
[size] => big
[id] => 1
)
[banana2] => Array
(
[color] => green
[size] => small
[id] => 2
)
)
Actual result:
--
Array
(
[banana1] => Array
(
[color] => yellow
[size] => big
[id] => 1
)
[banana2] => Array
(
[size] => I'm a
[type] => coconut!
)
)
--
Edit this bug report at http://bugs.php.net/bug.php?id=51409&edit=1
Bug #51409 [Opn->Bgs]: foreach structure pass by reference scope issue
Edit report at http://bugs.php.net/bug.php?id=51409&edit=1
ID: 51409
Updated by: ras...@php.net
Reported by: sramage at nucleuslabs dot com
Summary: foreach structure pass by reference scope issue
-Status: Open
+Status: Bogus
Type: Bug
Package: Arrays related
Operating System: FREEBSD 8.0
PHP Version: 5.2.13
New Comment:
This makes perfect sense. After your first foreach loop, $banana is a
reference
to the last element in your $bananas array. Anything you do to that
$banana
variable is going to affect that last element. So, in your coconut
foreach, you
are now asking PHP to assign the first element of the coconut array to
the last
element of your bananas array which is exactly the output you are
getting. No
bug here.
Previous Comments:
[2010-03-26 22:31:41] sramage at nucleuslabs dot com
Description:
When an ampersand operator is used in a foreach language construct The
pass by reference variable causes *copies* of the parent array used in
the foreach loop to be modified in any future use of the initial pass by
reference variable.
This is very hard to explain clearly but see the test script below for
clarification it is a very simple test script.'
Similar bugs like this have been reported and documentation outlines a
simple workaround that does work and solves my problem.
but I figured I would report this problem as *copies* of the array are
affected and it seems kind of strange.
Test script:
---
class Monkey{
public $bananas=array();
public function AddBananas($bananas){
$this->bananas=$bananas;
}}
$bananas=array();
$bananas['banana1']=array('color'=>'yellow','size'=>'big');
$bananas['banana2']=array('color'=>'green','size'=>'small');
$coconuts=array();
$coconuts['coconut1']['size']='tiny';
$coconuts['coconut2']['size']="I'm a";
$monkey=new Monkey();
foreach($bananas as $key=>&$banana){
$banana['id']=$key+1;
}
$monkey->AddBananas($bananas);
foreach($coconuts as $banana){
$banana['type']="coconut!";
}
print_r($monkey->bananas);
Expected result:
Array
(
[banana1] => Array
(
[color] => yellow
[size] => big
[id] => 1
)
[banana2] => Array
(
[color] => green
[size] => small
[id] => 2
)
)
Actual result:
--
Array
(
[banana1] => Array
(
[color] => yellow
[size] => big
[id] => 1
)
[banana2] => Array
(
[size] => I'm a
[type] => coconut!
)
)
--
Edit this bug report at http://bugs.php.net/bug.php?id=51409&edit=1
[PHP-BUG] Bug #51409 [NEW]: foreach structure pass by reference scope issue
From:
Operating system: FREEBSD 8.0
PHP version: 5.2.13
Package: Arrays related
Bug Type: Bug
Bug description:foreach structure pass by reference scope issue
Description:
When an ampersand operator is used in a foreach language construct The pass
by reference variable causes *copies* of the parent array used in the
foreach loop to be modified in any future use of the initial pass by
reference variable.
This is very hard to explain clearly but see the test script below for
clarification it is a very simple test script.'
Similar bugs like this have been reported and documentation outlines a
simple workaround that does work and solves my problem.
but I figured I would report this problem as *copies* of the array are
affected and it seems kind of strange.
Test script:
---
class Monkey{
public $bananas=array();
public function AddBananas($bananas){
$this->bananas=$bananas;
}}
$bananas=array();
$bananas['banana1']=array('color'=>'yellow','size'=>'big');
$bananas['banana2']=array('color'=>'green','size'=>'small');
$coconuts=array();
$coconuts['coconut1']['size']='tiny';
$coconuts['coconut2']['size']="I'm a";
$monkey=new Monkey();
foreach($bananas as $key=>&$banana){
$banana['id']=$key+1;
}
$monkey->AddBananas($bananas);
foreach($coconuts as $banana){
$banana['type']="coconut!";
}
print_r($monkey->bananas);
Expected result:
Array
(
[banana1] => Array
(
[color] => yellow
[size] => big
[id] => 1
)
[banana2] => Array
(
[color] => green
[size] => small
[id] => 2
)
)
Actual result:
--
Array
(
[banana1] => Array
(
[color] => yellow
[size] => big
[id] => 1
)
[banana2] => Array
(
[size] => I'm a
[type] => coconut!
)
)
--
Edit bug report at http://bugs.php.net/bug.php?id=51409&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51409&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51409&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51409&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51409&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51409&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51409&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51409&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51409&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51409&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51409&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51409&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51409&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51409&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51409&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51409&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51409&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51409&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51409&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51409&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51409&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51409&r=mysqlcfg
[PHP-BUG] Bug #51407 [NEW]: SOAP-ERROR: Parsing WSDL: Couldn't load from
From:
Operating system: Ubuntu
PHP version: 5.2.13
Package: SOAP related
Bug Type: Bug
Bug description:SOAP-ERROR: Parsing WSDL: Couldn't load from
Description:
made a copy of our store to my local machine and receive error of
SOAP-ERROR:
Parsing WSDL: Couldn't load from 'removed site name': failed to load
external
entity "removed sitename';
The module runs perfectly fine on a Ubuntu server running php 5.2.4
Checked to make sure that WSDL could be accessed from web browser.
Test script:
---
ini_set("soap.wsdl_cache_enabled", "0");
$wsdl = "http://www.usafa.org/WebService/RaisersEdge.asmx?wsdl";;
$params = array(
'strConstID' => $strConstID,
);
try {
$client = new SoapClient($wsdl);
} catch (Exception $e) {
echo '';
print_r($e);
echo '';
}
try {
$result = $client->VerfiyMembership($params);
$membership = $result->VerfiyMembershipResult;
} catch (Exception $f) {
echo 'Caught exception: ', $f->getMessage(), "\n";
}
unset($client);
return $membership;
Expected result:
return a boolean variable
Actual result:
--
Caught exception: SOAP-ERROR: Parsing WSDL: Couldn't load from
'http://www.usafa.org/WebService/RaisersEdge.asmx?wsdl' : failed to load
external
entity "http://www.usafa.org/WebService/RaisersEdge.asmx?wsdl";
Fatal error: Call to a member function VerfiyMembership() on a non-object
in
/var/www/drupal-6.16/sites/store/modules/uc_membership/uc_membership.module
on
line 214
--
Edit bug report at http://bugs.php.net/bug.php?id=51407&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51407&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51407&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51407&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51407&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51407&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51407&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51407&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51407&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51407&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51407&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51407&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51407&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51407&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51407&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51407&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51407&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51407&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51407&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51407&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51407&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51407&r=mysqlcfg
Bug #51403 [Bgs]: Multiple -d include_path command-line directives not handled correctly
Edit report at http://bugs.php.net/bug.php?id=51403&edit=1 ID: 51403 Updated by: ras...@php.net Reported by: ericp at activestate dot com Summary: Multiple -d include_path command-line directives not handled correctly Status: Bogus Type: Bug Package: Scripting Engine problem Operating System: Any PHP Version: 5.3.2 New Comment: That's because you didn't use quotes around your value there, so the shell ended your expression on the first semi-colon. Not a PHP issue. Previous Comments: [2010-03-26 21:44:23] ericp at activestate dot com But notice that this case fails to register both paths: php -d include_path=c:\php-5.2.8\PEAR;c:\php-5.2.8\PEAR\phpunit test.php - only the first path shows up. It would be useful if the command-line version had a way to add new directories to the include_path setting (after php.ini processing has taken place). I didn't see this in any existing bug. [2010-03-26 21:07:20] johan...@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 -d sets the setting, consequentially calls overwrite it, the last ones wins. That's the only consistent way to do it ... [2010-03-26 19:57:57] ericp at activestate dot com Description: If I try to specify more than one include_path directive on the command-line, only one sticks. WIth the following two command-lines, I expected to see two entries, but only saw the first. 1. Default case -- I see all three entries from my php.ini $ php test.php include_path=.;C:\apps\xampp\php\PEAR;c:\apps\smarty\libs $ php -d include_path=c:\php-5.2.8\PEAR;c:\php-5.2.8\PEAR\phpunit test.php include_path=c:\php-5.2.8\PEAR I was expecting to see both entries, not just the first. I'd also like an option to add to the existing include_path setting, not just override it. $ php -d include_path=c:\php-5.2.8\PEAR -d include_path=c:\php-5.2.8\PEAR\phpunit test.php include_path=c:\php-5.2.8\PEAR\phpunit Here I get the second entry only. Test script: --- Expected result: See the description. Actual result: -- See the description. -- Edit this bug report at http://bugs.php.net/bug.php?id=51403&edit=1
Bug #51403 [Bgs]: Multiple -d include_path command-line directives not handled correctly
Edit report at http://bugs.php.net/bug.php?id=51403&edit=1 ID: 51403 User updated by: ericp at activestate dot com Reported by: ericp at activestate dot com Summary: Multiple -d include_path command-line directives not handled correctly Status: Bogus Type: Bug Package: Scripting Engine problem Operating System: Any PHP Version: 5.3.2 New Comment: But notice that this case fails to register both paths: php -d include_path=c:\php-5.2.8\PEAR;c:\php-5.2.8\PEAR\phpunit test.php - only the first path shows up. It would be useful if the command-line version had a way to add new directories to the include_path setting (after php.ini processing has taken place). I didn't see this in any existing bug. Previous Comments: [2010-03-26 21:07:20] johan...@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 -d sets the setting, consequentially calls overwrite it, the last ones wins. That's the only consistent way to do it ... [2010-03-26 19:57:57] ericp at activestate dot com Description: If I try to specify more than one include_path directive on the command-line, only one sticks. WIth the following two command-lines, I expected to see two entries, but only saw the first. 1. Default case -- I see all three entries from my php.ini $ php test.php include_path=.;C:\apps\xampp\php\PEAR;c:\apps\smarty\libs $ php -d include_path=c:\php-5.2.8\PEAR;c:\php-5.2.8\PEAR\phpunit test.php include_path=c:\php-5.2.8\PEAR I was expecting to see both entries, not just the first. I'd also like an option to add to the existing include_path setting, not just override it. $ php -d include_path=c:\php-5.2.8\PEAR -d include_path=c:\php-5.2.8\PEAR\phpunit test.php include_path=c:\php-5.2.8\PEAR\phpunit Here I get the second entry only. Test script: --- Expected result: See the description. Actual result: -- See the description. -- Edit this bug report at http://bugs.php.net/bug.php?id=51403&edit=1
Bug #51396 [Fbk]: Math is Unreliable
Edit report at http://bugs.php.net/bug.php?id=51396&edit=1 ID: 51396 Updated by: paj...@php.net Reported by: codeslinger at compsalot dot com Summary: Math is Unreliable Status: Feedback Type: Bug Package: Math related Operating System: any PHP Version: Irrelevant New Comment: Please try using this snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Previous Comments: [2010-03-26 21:32:51] codeslinger at compsalot dot com as far as the low incidence of occurrence and the millions of users not seeing it. I've said all along that it is hard to reproduce. But when dealing with financial transactions, that is not good enough, it only takes one mistake to have a huge problem on your hands. Out of all of those millions of users, I'd venture to say that the very overwhelming majority are using php for string processing not number crunching. And in many cases where it does show up such as positioning something on a web page, it would be easy to shrug off. So there is no way to know how often this happens in the wild, based on user feedback. [2010-03-26 21:02:47] codeslinger at compsalot dot com The billing program was failing on multiple computers at multiple locations, it failed on XP and Windows 2000 with various cpus. Those were customer sites! I reproduced the problem on a vmware setup with windows 2000. This snowflake program is failing on Ubuntu Hardy 8.0.4 with all of the updates. This is the stock php that comes with Ubuntu. This is a Pentium M 32bit Laptop. I've never experienced a memory error on this computer and the fact of it's consistency would argue against this being some kind of hardware issue. Here is what I get when I run the simplefail in the default config. php -v PHP 5.2.4-2ubuntu5.10 with Suhosin-Patch 0.9.6.2 (cli) (built: Jan 6 2010 22:01:14) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies with Xdebug v2.0.3, Copyright (c) 2002-2007, by Derick Rethans with Zend Debugger v5.2.15, Copyright (c) 1999-2008, by Zend Technologies == php simplefail.php Selected onepair.txt, Found 1 items (string)(double) -0.1 === -0.1 which of course is correct But when we convert the value in an array it fails Conversion Error: PHP Math idx = 0 || '-0.1' !== '-0.0:' = THANK YOU I REALLY APPRECIATE THE HELP [2010-03-26 17:25:40] ahar...@php.net Well, it is the next character after '9', and the character string is built up in zend_dtoa() by adding a value L (presumably intended to be in the range 0..9) to '0'. If L somehow ends up being 10, you'd get a colon. With the values that are apparently causing problems (the problematic value in onepair.txt is 0.0167...), it does kind of look like a rounding issue to me, although I've no idea why it's not being triggered by more than two or three users in that case. [2010-03-26 17:18:22] ras...@php.net Bad memory perhaps? But why consistently a ':' ? [2010-03-26 16:57:15] ahar...@php.net JFTR, I was also unable to reproduce the failure case from any of the data files on both 32-bit and 64-bit Linux builds and a 32-bit Windows build. I've got a couple of boxen crunching away generating random doubles and converting them to strings in what seems to be the sort of range that causes problems (one 32-bit Linux, one 64-bit Linux): nothing yet after a couple of billion iterations. In short, I don't have a clue what it could be either, but I'll keep the random double generation going a while longer just in case it hits paydirt. 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=51396 -- Edit this bug report at http://bugs.php.net/bug.php?id=51396&edit=1
Bug #51396 [Com]: Math is Unreliable
Edit report at http://bugs.php.net/bug.php?id=51396&edit=1 ID: 51396 Comment by: codeslinger at compsalot dot com Reported by: codeslinger at compsalot dot com Summary: Math is Unreliable Status: Feedback Type: Bug Package: Math related Operating System: any PHP Version: Irrelevant New Comment: as far as the low incidence of occurrence and the millions of users not seeing it. I've said all along that it is hard to reproduce. But when dealing with financial transactions, that is not good enough, it only takes one mistake to have a huge problem on your hands. Out of all of those millions of users, I'd venture to say that the very overwhelming majority are using php for string processing not number crunching. And in many cases where it does show up such as positioning something on a web page, it would be easy to shrug off. So there is no way to know how often this happens in the wild, based on user feedback. Previous Comments: [2010-03-26 21:02:47] codeslinger at compsalot dot com The billing program was failing on multiple computers at multiple locations, it failed on XP and Windows 2000 with various cpus. Those were customer sites! I reproduced the problem on a vmware setup with windows 2000. This snowflake program is failing on Ubuntu Hardy 8.0.4 with all of the updates. This is the stock php that comes with Ubuntu. This is a Pentium M 32bit Laptop. I've never experienced a memory error on this computer and the fact of it's consistency would argue against this being some kind of hardware issue. Here is what I get when I run the simplefail in the default config. php -v PHP 5.2.4-2ubuntu5.10 with Suhosin-Patch 0.9.6.2 (cli) (built: Jan 6 2010 22:01:14) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies with Xdebug v2.0.3, Copyright (c) 2002-2007, by Derick Rethans with Zend Debugger v5.2.15, Copyright (c) 1999-2008, by Zend Technologies == php simplefail.php Selected onepair.txt, Found 1 items (string)(double) -0.1 === -0.1 which of course is correct But when we convert the value in an array it fails Conversion Error: PHP Math idx = 0 || '-0.1' !== '-0.0:' = THANK YOU I REALLY APPRECIATE THE HELP [2010-03-26 17:25:40] ahar...@php.net Well, it is the next character after '9', and the character string is built up in zend_dtoa() by adding a value L (presumably intended to be in the range 0..9) to '0'. If L somehow ends up being 10, you'd get a colon. With the values that are apparently causing problems (the problematic value in onepair.txt is 0.0167...), it does kind of look like a rounding issue to me, although I've no idea why it's not being triggered by more than two or three users in that case. [2010-03-26 17:18:22] ras...@php.net Bad memory perhaps? But why consistently a ':' ? [2010-03-26 16:57:15] ahar...@php.net JFTR, I was also unable to reproduce the failure case from any of the data files on both 32-bit and 64-bit Linux builds and a 32-bit Windows build. I've got a couple of boxen crunching away generating random doubles and converting them to strings in what seems to be the sort of range that causes problems (one 32-bit Linux, one 64-bit Linux): nothing yet after a couple of billion iterations. In short, I don't have a clue what it could be either, but I'll keep the random double generation going a while longer just in case it hits paydirt. [2010-03-26 16:39:33] paj...@php.net Rasmus, he is not the only person. There are two other reports about it. However he is the first one to experience it on non windows platform. 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=51396 -- Edit this bug report at http://bugs.php.net/bug.php?id=51396&edit=1
Bug #49145 [Com]: php command line segmentation fault
Edit report at http://bugs.php.net/bug.php?id=49145&edit=1 ID: 49145 Comment by: holger dot dippel at umassd dot edu Reported by: dhathorn at uchicago dot edu Summary: php command line segmentation fault Status: Closed Type: Bug Package: Reproducible crash Operating System: Linux (RedHat RHEL4) PHP Version: 5.3SVN-2009-08-03 (snap) New Comment: No kidding. I had compiled PHP 5.3.2 from the source on RedHat AS 2.6.9 with a general linux MySQL server/client 5.0.27 on the same machine. pear install and pecl would abort with a Segmentation Fault. Upgraded to MySQL 5.1.45 server/client (nothing else changed), reconfigured/recompiled PHP, and pear/pecl works like a charm. Previous Comments: [2009-10-08 18:46:49] dhathorn at uchicago dot edu Indeed, nothing else was updated. [2009-10-08 14:45:15] j...@php.net So there's no point in keeping this open. Are you sure nothing else was updated since you had the issue..? :) [2009-10-07 04:31:14] dhathorn at uchicago dot edu Upgrading the following rpms: MySQL-client-standard-5.0.27-0.rhel4.i386.rpm MySQL-devel-standard-5.0.27-0.rhel4.i386.rpm MySQL-shared-standard-5.0.27-0.rhel4.i386.rpm to: MySQL-client-community-5.0.84-0.rhel4.i386.rpm MySQL-devel-community-5.0.84-0.rhel4.i386.rpm MySQL-shared-community-5.0.84-0.rhel4.i386.rpm ...made this issue go away. [2009-08-10 15:22:02] dhathorn at uchicago dot edu Is there any further information that I can provide or anything else I can do to help resolve this? [2009-08-03 22:44:19] dhathorn at uchicago dot edu OpenSSL 0.9.7a Feb 19 2003 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=49145 -- Edit this bug report at http://bugs.php.net/bug.php?id=49145&edit=1
[PHP-BUG] Bug #51406 [NEW]: Exception constructor calling method statically populates $this
From: Operating system: Windows Server 2008 PHP version: 5.3.2 Package: *General Issues Bug Type: Bug Bug description:Exception constructor calling method statically populates $this Description: You are able to call a class method statically even if it is not defined as static. If you do this from the constructor of an Exception, $this references the Exception object. This is tested on my dev machine running Windows 7, IIS7.5 and PHP 5.3.2 as well as our test server running Windows Server 2008, IIS7 and PHP 5.3.2 Test script: --- Expected result: Actual result: -- ExtendedException Object ( [message:protected] => [string:Exception:private] => [code:protected] => 0 [file:protected] => D:\Public\Innovirt\bugtest.php [line:protected] => 18 [trace:Exception:private] => Array ( ) [previous:Exception:private] => ) -- Edit bug report at http://bugs.php.net/bug.php?id=51406&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51406&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51406&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51406&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51406&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51406&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51406&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51406&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51406&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51406&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51406&r=support Expected behavior: http://bugs.php.net/fix.php?id=51406&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51406&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51406&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51406&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51406&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51406&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51406&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51406&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51406&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51406&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51406&r=mysqlcfg
Bug #51403 [Opn->Bgs]: Multiple -d include_path command-line directives not handled correctly
Edit report at http://bugs.php.net/bug.php?id=51403&edit=1 ID: 51403 Updated by: johan...@php.net Reported by: ericp at activestate dot com Summary: Multiple -d include_path command-line directives not handled correctly -Status: Open +Status: Bogus Type: Bug Package: Scripting Engine problem Operating System: Any PHP Version: 5.3.2 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 -d sets the setting, consequentially calls overwrite it, the last ones wins. That's the only consistent way to do it ... Previous Comments: [2010-03-26 19:57:57] ericp at activestate dot com Description: If I try to specify more than one include_path directive on the command-line, only one sticks. WIth the following two command-lines, I expected to see two entries, but only saw the first. 1. Default case -- I see all three entries from my php.ini $ php test.php include_path=.;C:\apps\xampp\php\PEAR;c:\apps\smarty\libs $ php -d include_path=c:\php-5.2.8\PEAR;c:\php-5.2.8\PEAR\phpunit test.php include_path=c:\php-5.2.8\PEAR I was expecting to see both entries, not just the first. I'd also like an option to add to the existing include_path setting, not just override it. $ php -d include_path=c:\php-5.2.8\PEAR -d include_path=c:\php-5.2.8\PEAR\phpunit test.php include_path=c:\php-5.2.8\PEAR\phpunit Here I get the second entry only. Test script: --- Expected result: See the description. Actual result: -- See the description. -- Edit this bug report at http://bugs.php.net/bug.php?id=51403&edit=1
[PHP-BUG] Bug #51405 [NEW]: segmentation fault at the "engine shutdown"
From: Operating system: Linux PHP version: 5.3.2 Package: Reproducible crash Bug Type: Bug Bug description:segmentation fault at the "engine shutdown" Description: I have a repeatable crash in a project consisting from Zend Framework 1.10.2, Doctrine 1.2.1, and Dwoo 1.1.1. Unfortunately I'm unable to strip it down to a small enough test case. But the bug is very specific. ./configure '--enable-fpm' '--with-openssl' '--with-zlib' '--enable-bcmath' '--with-bz2' '--enable-calendar' '--with-curl' '--enable-exif' '--enable-ftp' '--with-gd' '--with-imap' '--with-imap-ssl' '--enable-mbstring' '--with-mcrypt' '--enable-pcntl' '--with-pdo-mysql' '--with-pdo-pgsql' '--with-pgsql' '--with-readline' '--with-mysql' '--enable-soap' '--enable-sockets' '--enable-sqlite-utf8' '--enable-sysvmsg' '--enable-sysvsem' '--enable-sysvshm' '--with-tidy' '--enable-wddx' '--with-xmlrpc' '--with-xsl' '--enable-zip' '--with-kerberos' '--with-mysqli' '--with-config-file-path=/usr/local/etc' '--with-config-file-scan-dir=/usr/local/etc/php.d' '--with-pear' '--with-jpeg-dir=/usr/lib' --with-freetype-dir=/usr/lib r...@mvubdevel:/usr/local/etc# diff php.ini php.ini-production 25c25 < ; they might mean something in the future. --- > ; they might mean something in the future. 201c201 < user_ini.filename = --- > ;user_ini.filename = 414c414 < realpath_cache_size = 16k --- > ;realpath_cache_size = 16k 420c420 < realpath_cache_ttl = 120 --- > ;realpath_cache_ttl = 120 444c444 < ; long running scripts. --- > ; long running scripts. 514c514 < error_reporting = E_ALL | E_STRICT --- > error_reporting = E_ALL & ~E_DEPRECATED 524,525c524,525 < ; Off = Do not display any errors < ; stderr = Display errors to STDERR (affects only CGI/CLI binaries!) --- > ; Off = Do not display any errors > ; stderr = Display errors to STDERR (affects only CGI/CLI binaries!) 531c531 < display_errors = On --- > display_errors = Off 542c542 < display_startup_errors = On --- > display_startup_errors = Off 586c586 < track_errors = On --- > track_errors = Off 604c604 < html_errors = On --- > html_errors = Off 636c636 < error_log = /var/log/php_errors.log --- > ;error_log = php_errors.log 644,645d643 < ; Note - track_vars is ALWAYS enabled < 677c675 < ; Leaving this value empty will cause PHP to use the value set in the --- > ; Leaving this value empty will cause PHP to use the value set in the 688,690c686 < ; with user data. This makes most sense when coupled with track_vars - in which < ; case you can access all of the GPC variables through the $HTTP_*_VARS[], < ; variables. --- > ; with user data. 811c807 < extension_dir = "/usr/local/lib/php/extensions/" --- > ; extension_dir = "./" 883c879,882 < upload_max_filesize = 6M --- > upload_max_filesize = 2M > > ; Maximum number of files that can be uploaded via a single request > max_file_uploads = 20 947c946 < ; --- > ; 997c996 < date.timezone = Europe/Ljubljana --- > ;date.timezone = 1019,1021c1018,1020 < iconv.input_encoding = UTF-8 < iconv.internal_encoding = UTF-8 < iconv.output_encoding = UTP-8 --- > ;iconv.input_encoding = ISO-8859-1 > ;iconv.internal_encoding = ISO-8859-1 > ;iconv.output_encoding = ISO-8859-1 1024c1023,1027 < ;intl.default_locale = --- > ;intl.default_locale = > ; This directive allows you to produce PHP errors when some error > ; happens within intl functions. The value is the level of the error produced. > ; Default is 0, which does not produce any errors. > ;intl.error_level = E_WARNING 1038,1040c1041,1043 < ;PCRE library recursion limit. < ;Please note that if you set this value to a high number you may consume all < ;the available process stack and eventually crash PHP (due to reaching the --- > ;PCRE library recursion limit. > ;Please note that if you set this value to a high number you may consume all > ;the available process stack and eventually crash PHP (due to reaching the 1064c1067 < phar.readonly = On --- > ;phar.readonly = On 1102c1105 < mail.log = /var/log/php-mail.log --- > ;mail.log = 1118c1121 < ; Controls the ODBC cursor model. --- > ; Controls the ODBC cursor model. 1245a1249,1256 > ; Allow accessing, from PHP's perspective, local files with LOAD DATA statements > ; http://php.net/mysqli.allow_local_infile > ;mysqli.allow_local_infile = On > > ; Allow or prevent persistent links. > ; http://php.net/mysqli.allow-persistent > mysqli.allow_persistent = On > 1294c1305 < mysqlnd.collect_memory_statistics = On --- > mysqlnd.collect_memory_statistics = Off 1504c1515 < session.cookie_httponly = --- > session.cookie_httponly = 1523c1534 < ; session initialization. The probability is calculated by using the following equation: --- > ; session initialization. The probability is calculated by using the following equation: 1572c1583 < session.bug_compat_warn = ffn --- > session.bug_compat_warn
Bug #51396 [Com]: Math is Unreliable
Edit report at http://bugs.php.net/bug.php?id=51396&edit=1 ID: 51396 Comment by: codeslinger at compsalot dot com Reported by: codeslinger at compsalot dot com Summary: Math is Unreliable Status: Feedback Type: Bug Package: Math related Operating System: any PHP Version: Irrelevant New Comment: The billing program was failing on multiple computers at multiple locations, it failed on XP and Windows 2000 with various cpus. Those were customer sites! I reproduced the problem on a vmware setup with windows 2000. This snowflake program is failing on Ubuntu Hardy 8.0.4 with all of the updates. This is the stock php that comes with Ubuntu. This is a Pentium M 32bit Laptop. I've never experienced a memory error on this computer and the fact of it's consistency would argue against this being some kind of hardware issue. Here is what I get when I run the simplefail in the default config. php -v PHP 5.2.4-2ubuntu5.10 with Suhosin-Patch 0.9.6.2 (cli) (built: Jan 6 2010 22:01:14) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies with Xdebug v2.0.3, Copyright (c) 2002-2007, by Derick Rethans with Zend Debugger v5.2.15, Copyright (c) 1999-2008, by Zend Technologies == php simplefail.php Selected onepair.txt, Found 1 items (string)(double) -0.1 === -0.1 which of course is correct But when we convert the value in an array it fails Conversion Error: PHP Math idx = 0 || '-0.1' !== '-0.0:' = THANK YOU I REALLY APPRECIATE THE HELP Previous Comments: [2010-03-26 17:25:40] ahar...@php.net Well, it is the next character after '9', and the character string is built up in zend_dtoa() by adding a value L (presumably intended to be in the range 0..9) to '0'. If L somehow ends up being 10, you'd get a colon. With the values that are apparently causing problems (the problematic value in onepair.txt is 0.0167...), it does kind of look like a rounding issue to me, although I've no idea why it's not being triggered by more than two or three users in that case. [2010-03-26 17:18:22] ras...@php.net Bad memory perhaps? But why consistently a ':' ? [2010-03-26 16:57:15] ahar...@php.net JFTR, I was also unable to reproduce the failure case from any of the data files on both 32-bit and 64-bit Linux builds and a 32-bit Windows build. I've got a couple of boxen crunching away generating random doubles and converting them to strings in what seems to be the sort of range that causes problems (one 32-bit Linux, one 64-bit Linux): nothing yet after a couple of billion iterations. In short, I don't have a clue what it could be either, but I'll keep the random double generation going a while longer just in case it hits paydirt. [2010-03-26 16:39:33] paj...@php.net Rasmus, he is not the only person. There are two other reports about it. However he is the first one to experience it on non windows platform. [2010-03-26 16:26:05] ras...@php.net I ran your simplefail.php on all 4 data files. Never saw the failure case. Then I took just the huge rawpairs.txt file (had to increase the memory_limit) and modified your program slightly to do: for($i=0;$i<10;$i++) ConvertData($data); and ran that, which took quite a while. Still no failures. You are still the only person who has ever reported these weird ":" characters showing up, and you have yet to produce any sort of code that reproduces it for someone else. We'll keep trying, but something that happens for 1 person out of millions is suspicious. 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=51396 -- Edit this bug report at http://bugs.php.net/bug.php?id=51396&edit=1
Bug #51220 [Asn->Csd]: ext/oci8/tests/lob_043.phpt kills 'make test'
Edit report at http://bugs.php.net/bug.php?id=51220&edit=1 ID: 51220 Updated by: s...@php.net Reported by: long at ku dot edu Summary: ext/oci8/tests/lob_043.phpt kills 'make test' -Status: Assigned +Status: Closed Type: Bug Package: *General Issues Operating System: Red Hat Enterprise Linux AS rele PHP Version: 5.3.2 Assigned To: sixd New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. This test can sometimes timeout but I've not seen the memory issue. I've added a flag to details.inc in the OCI8 test suite to enable/disable some "stress" tests. By default this flag is disabled and lob_043.phpt won't run. Previous Comments: [2010-03-26 20:38:28] s...@php.net Automatic comment from SVN on behalf of sixd Revision: http://svn.php.net/viewvc/?view=revision&revision=296893 Log: Fix #51220 by adding . Also improve reliability for tests using undefined behavior. [2010-03-06 02:25:56] johan...@php.net blind guess: The test creates way too much output. Can you check it, Chris? [2010-03-06 01:16:49] long at ku dot edu Description: Trying to run 'make test' leads to: FAIL Check various LOB error messages [ext/oci8/tests/lob_042.phpt] TEST 4281/10735 [ext/oci8/tests/lob_043.phpt] Fatal error: Out of memory (allocated 1605894144) (tried to allocate 1598922365 bytes) in /apps/home/long/src/php-5.3.2-ap2/run-tests.php on line 1724 make: [test] Error 255 (ignored) [l...@wbtstap php-5.3.2-ap2]$ [l...@wbtstap php-5.3.2-ap2]$ cat config.nice #! /bin/sh # # Created by configure CFLAGS='-O3' \ CXXFLAGS='-O3' \ LIBS='-lssl -lncurses' \ './configure' \ '--enable-discard-path' \ '--with-openssl=shared' \ '--with-zlib=shared' \ '--enable-bcmath' \ '--with-bz2=shared' \ '--enable-calendar' \ '--with-curl=shared' \ '--enable-dba=shared' \ '--with-gdbm=shared' \ '--with-db4=shared' \ '--enable-dbase' \ '--enable-exif' \ '--enable-ftp' \ '--with-gd=shared' \ '--enable-gd-native-ttf' \ '--enable-gd-jis-conv' \ '--with-gettext=shared' \ '--with-gmp=shared' \ '--with-imap=shared' \ '--with-kerberos' \ '--with-imap-ssl' \ '--with-ldap' \ '--enable-mbstring' \ '--with-mysql=/usr' \ '--with-ncurses=shared' \ '--with-oci8' \ '--with-pspell=shared' \ '--with-readline=shared' \ '--enable-shmop' \ '--with-snmp=shared' \ '--enable-sockets' \ '--with-sqlite=shared' \ '--enable-sysvmsg' \ '--enable-sysvsem' \ '--enable-sysvshm' \ '--enable-wddx' \ '--with-freetype-dir' \ '--with-jpeg-dir' \ '--with-xpm-dir' \ '--with-apxs2=/usr/local/apache/bin/apxs' \ '--with-mysqli' \ '--enable-pdo=shared' \ '--with-pdo-mysql=shared' \ '--with-pdo-oci=shared' \ '--with-pdo-sqlite=shared' \ '--with-tidy' \ '--enable-soap=shared' \ '--enable-zip' \ '--with-pgsql' \ "$@" [l...@wbtstap php-5.3.2-ap2]$ [l...@wbtstap php-5.3.2-ap2]$ cat /usr/local/lib/php.ini register_globals = on; ; Output buffering allows you to send header lines (including cookies) even ; after you send body content, at the price of slowing PHP's output layer a ; bit. You can enable output buffering during runtime by calling the output ; buffering functions. You can also enable output buffering for all files by ; setting this directive to On. If you wish to limit the size of the buffer ; to a certain size - you can use a maximum number of bytes instead of 'On', as ; a value for this directive (e.g., output_buffering=4096). output_buffering = 4096 ;; ; Error handling and logging ; ;; ; error_reporting is a bit-field. Or each number up to get desired error ; reporting level ; E_ALL - All errors and warnings ; E_ERROR - fatal run-time errors ; E_WARNING - run-time warnings (non-fatal errors) ; E_PARSE - compile-time parse errors ; E_NOTICE - run-time notices (these are warnings which often result ; from a bug in your code, but it's possible that it was ; intentional (e.g., using an uninitialized variable and ; relying on the fact it's automatically initialized to an ; empty string) ; E_STRICT - run-time notices, enable to have PHP suggest changes ; to your code which will ensure the best interoperability ; and forward compatibility of your code ; E_CORE_ERROR - fatal errors that occur during PHP's initial startu
[PHP-BUG] Bug #51404 [NEW]: is_dir() returns false on cifs mounted share
From:
Operating system: Linux
PHP version: Irrelevant
Package: Directory function related
Bug Type: Bug
Bug description:is_dir() returns false on cifs mounted share
Description:
I upgraded my kernel to 2.6.31 (stable) and has php-5.2.12 (stable), but
php function is_dir() returns false for folder on my cifs mounted share.
strace php -r 'var_dump(is_dir("/path_to_mounted_folder/"));'
...
stat64("/path_to_mounted_folder/", {st_mode=S_IFDIR|0755, st_size=32768,
...}) = 0
gettimeofday({1269602972, 30466}, NULL) = 0
write(1, "bool(false)\n", 12bool(false)
) = 12
...
Test script:
---
php -r 'var_dump(is_dir("/path_to_mounted_folder/"));'
Expected result:
bool(true)
Actual result:
--
bool(false)
--
Edit bug report at http://bugs.php.net/bug.php?id=51404&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51404&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51404&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51404&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51404&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51404&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51404&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51404&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51404&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51404&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51404&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51404&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51404&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51404&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51404&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51404&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51404&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51404&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51404&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51404&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51404&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51404&r=mysqlcfg
[PHP-BUG] Bug #51403 [NEW]: Multiple -d include_path command-line directives not handled correctly
From: Operating system: Any PHP version: 5.3.2 Package: Scripting Engine problem Bug Type: Bug Bug description:Multiple -d include_path command-line directives not handled correctly Description: If I try to specify more than one include_path directive on the command-line, only one sticks. WIth the following two command-lines, I expected to see two entries, but only saw the first. 1. Default case -- I see all three entries from my php.ini $ php test.php include_path=.;C:\apps\xampp\php\PEAR;c:\apps\smarty\libs $ php -d include_path=c:\php-5.2.8\PEAR;c:\php-5.2.8\PEAR\phpunit test.php include_path=c:\php-5.2.8\PEAR I was expecting to see both entries, not just the first. I'd also like an option to add to the existing include_path setting, not just override it. $ php -d include_path=c:\php-5.2.8\PEAR -d include_path=c:\php-5.2.8\PEAR\phpunit test.php include_path=c:\php-5.2.8\PEAR\phpunit Here I get the second entry only. Test script: --- Expected result: See the description. Actual result: -- See the description. -- Edit bug report at http://bugs.php.net/bug.php?id=51403&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51403&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51403&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51403&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51403&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51403&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51403&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51403&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51403&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51403&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51403&r=support Expected behavior: http://bugs.php.net/fix.php?id=51403&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51403&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51403&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51403&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51403&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51403&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51403&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51403&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51403&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51403&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51403&r=mysqlcfg
Bug #51205 [Fbk->Opn]: Fatal error: com_exception: The parameter is incorrect
Edit report at http://bugs.php.net/bug.php?id=51205&edit=1
ID: 51205
User updated by: zelnaga at gmail dot com
Reported by: zelnaga at gmail dot com
Summary: Fatal error: com_exception: The parameter is incorrect
-Status: Feedback
+Status: Open
Type: Bug
Package: COM related
Operating System: Windows XP
PHP Version: 5.3.1
New Comment:
the $rng->GetBytes($v); line.
Previous Comments:
[2010-03-15 15:27:30] ka...@php.net
In what line does this happen?
[2010-03-04 22:31:57] zelnaga at gmail dot com
Description:
Hi,
I need to use RNGCryptoServiceProvider in PHP.
I have tried:
$rng = new DOTNET("mscorlib",
"System.Security.Cryptography.RNGCryptoServiceProvider");
$arr = array(0);
$v = new VARIANT($arr,VT_ARRAY);
$rng->GetBytes($v);
unset($rng);
The component loads fine.
But I got this error: Fatal error: Uncaught exception 'com_exception'
with message 'Error [0x80070057] The parameter is incorrect.
Any ideas?
--
Edit this bug report at http://bugs.php.net/bug.php?id=51205&edit=1
Bug #51396 [Fbk]: Math is Unreliable
Edit report at http://bugs.php.net/bug.php?id=51396&edit=1 ID: 51396 Updated by: ahar...@php.net Reported by: codeslinger at compsalot dot com Summary: Math is Unreliable Status: Feedback Type: Bug Package: Math related Operating System: any PHP Version: Irrelevant New Comment: Well, it is the next character after '9', and the character string is built up in zend_dtoa() by adding a value L (presumably intended to be in the range 0..9) to '0'. If L somehow ends up being 10, you'd get a colon. With the values that are apparently causing problems (the problematic value in onepair.txt is 0.0167...), it does kind of look like a rounding issue to me, although I've no idea why it's not being triggered by more than two or three users in that case. Previous Comments: [2010-03-26 17:18:22] ras...@php.net Bad memory perhaps? But why consistently a ':' ? [2010-03-26 16:57:15] ahar...@php.net JFTR, I was also unable to reproduce the failure case from any of the data files on both 32-bit and 64-bit Linux builds and a 32-bit Windows build. I've got a couple of boxen crunching away generating random doubles and converting them to strings in what seems to be the sort of range that causes problems (one 32-bit Linux, one 64-bit Linux): nothing yet after a couple of billion iterations. In short, I don't have a clue what it could be either, but I'll keep the random double generation going a while longer just in case it hits paydirt. [2010-03-26 16:39:33] paj...@php.net Rasmus, he is not the only person. There are two other reports about it. However he is the first one to experience it on non windows platform. [2010-03-26 16:26:05] ras...@php.net I ran your simplefail.php on all 4 data files. Never saw the failure case. Then I took just the huge rawpairs.txt file (had to increase the memory_limit) and modified your program slightly to do: for($i=0;$i<10;$i++) ConvertData($data); and ran that, which took quite a while. Still no failures. You are still the only person who has ever reported these weird ":" characters showing up, and you have yet to produce any sort of code that reproduces it for someone else. We'll keep trying, but something that happens for 1 person out of millions is suspicious. [2010-03-26 15:28:16] codeslinger at compsalot dot com it's still not 20 lines... it never will be but I found one surprising thing, if I save the array to disk and read it back in I still get the same failure. so essentially the snowflake is a Psudo-RNG and that's why trying to simplify it does not work, because it has to be able to generate all of those different numbers. but once we have the set of numbers the generator becomes irrelevant. Try this program: http://www.compsalot.com/phpbug/kochsnowflake/simplefail/ weirdly, every failure is a -0.1 but there are two things that I'm concerned about. 1) It seems unlikely that the billing program was only failing on that amount, it is a pretty unusual amount. Not one I'd normally expect to see and there were a lot of failures. 2) I'm concerned about the limitations of the detection method. I am only finding bad values because they have a colon in the string. I am not currently checking for mathematical correctness. We may not be seeing the whole story, there could be a lot more bad values that just are not blatant enough to be observed. But at least this should give you the starting point that you are asking for. The program is reduced to reading a file from disk and checking each number to see if it's valid. can't get any simpler than that. Of course if the corruption is happening when the value is created, looking at them after the fact may still not help much. But when I look at these values in the eclipse zend debugger, they look normal enough despite the fact that they can't be properly converted. -- The data files are as follows: rawpairs.txt is a 6.5meg file and contains both good and bad values, you don't need this file unless you are trying to validate the serialization. This is from a single run of the snowflake, $Nest = 3; $Depth = 5; The following were extracted from the raw data. onepair.txt contains a single failure item selectpairs.txt contains 8 failures which were from a single run of snowflake manypairs.txt contains about 40 failures which are the result of multiple runs of the snowflake using different Nest & Depth parameters.
Bug #51396 [Fbk]: Math is Unreliable
Edit report at http://bugs.php.net/bug.php?id=51396&edit=1 ID: 51396 Updated by: ras...@php.net Reported by: codeslinger at compsalot dot com Summary: Math is Unreliable Status: Feedback Type: Bug Package: Math related Operating System: any PHP Version: Irrelevant New Comment: Bad memory perhaps? But why consistently a ':' ? Previous Comments: [2010-03-26 16:57:15] ahar...@php.net JFTR, I was also unable to reproduce the failure case from any of the data files on both 32-bit and 64-bit Linux builds and a 32-bit Windows build. I've got a couple of boxen crunching away generating random doubles and converting them to strings in what seems to be the sort of range that causes problems (one 32-bit Linux, one 64-bit Linux): nothing yet after a couple of billion iterations. In short, I don't have a clue what it could be either, but I'll keep the random double generation going a while longer just in case it hits paydirt. [2010-03-26 16:39:33] paj...@php.net Rasmus, he is not the only person. There are two other reports about it. However he is the first one to experience it on non windows platform. [2010-03-26 16:26:05] ras...@php.net I ran your simplefail.php on all 4 data files. Never saw the failure case. Then I took just the huge rawpairs.txt file (had to increase the memory_limit) and modified your program slightly to do: for($i=0;$i<10;$i++) ConvertData($data); and ran that, which took quite a while. Still no failures. You are still the only person who has ever reported these weird ":" characters showing up, and you have yet to produce any sort of code that reproduces it for someone else. We'll keep trying, but something that happens for 1 person out of millions is suspicious. [2010-03-26 15:28:16] codeslinger at compsalot dot com it's still not 20 lines... it never will be but I found one surprising thing, if I save the array to disk and read it back in I still get the same failure. so essentially the snowflake is a Psudo-RNG and that's why trying to simplify it does not work, because it has to be able to generate all of those different numbers. but once we have the set of numbers the generator becomes irrelevant. Try this program: http://www.compsalot.com/phpbug/kochsnowflake/simplefail/ weirdly, every failure is a -0.1 but there are two things that I'm concerned about. 1) It seems unlikely that the billing program was only failing on that amount, it is a pretty unusual amount. Not one I'd normally expect to see and there were a lot of failures. 2) I'm concerned about the limitations of the detection method. I am only finding bad values because they have a colon in the string. I am not currently checking for mathematical correctness. We may not be seeing the whole story, there could be a lot more bad values that just are not blatant enough to be observed. But at least this should give you the starting point that you are asking for. The program is reduced to reading a file from disk and checking each number to see if it's valid. can't get any simpler than that. Of course if the corruption is happening when the value is created, looking at them after the fact may still not help much. But when I look at these values in the eclipse zend debugger, they look normal enough despite the fact that they can't be properly converted. -- The data files are as follows: rawpairs.txt is a 6.5meg file and contains both good and bad values, you don't need this file unless you are trying to validate the serialization. This is from a single run of the snowflake, $Nest = 3; $Depth = 5; The following were extracted from the raw data. onepair.txt contains a single failure item selectpairs.txt contains 8 failures which were from a single run of snowflake manypairs.txt contains about 40 failures which are the result of multiple runs of the snowflake using different Nest & Depth parameters. [2010-03-26 11:14:13] paj...@php.net Does it happen always? Can you try to make a script with only this function call with the values causing this effect? 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=51396 -- Edit this bug report at http://bugs.php.net/bug.php?id=51396&edit=1
Bug #51396 [Fbk]: Math is Unreliable
Edit report at http://bugs.php.net/bug.php?id=51396&edit=1
ID: 51396
Updated by: ahar...@php.net
Reported by: codeslinger at compsalot dot com
Summary: Math is Unreliable
Status: Feedback
Type: Bug
Package: Math related
Operating System: any
PHP Version: Irrelevant
New Comment:
JFTR, I was also unable to reproduce the failure case from any of the
data files on both 32-bit and 64-bit Linux builds and a 32-bit Windows
build. I've got a couple of boxen crunching away generating random
doubles and converting them to strings in what seems to be the sort of
range that causes problems (one 32-bit Linux, one 64-bit Linux): nothing
yet after a couple of billion iterations.
In short, I don't have a clue what it could be either, but I'll keep the
random double generation going a while longer just in case it hits
paydirt.
Previous Comments:
[2010-03-26 16:39:33] paj...@php.net
Rasmus, he is not the only person. There are two other reports about it.
However he is the first one to experience it on non windows platform.
[2010-03-26 16:26:05] ras...@php.net
I ran your simplefail.php on all 4 data files. Never saw the failure
case.
Then I took just the huge rawpairs.txt file (had to increase the
memory_limit)
and modified your program slightly to do:
for($i=0;$i<10;$i++) ConvertData($data);
and ran that, which took quite a while. Still no failures.
You are still the only person who has ever reported these weird ":"
characters
showing up, and you have yet to produce any sort of code that reproduces
it for
someone else. We'll keep trying, but something that happens for 1
person out of
millions is suspicious.
[2010-03-26 15:28:16] codeslinger at compsalot dot com
it's still not 20 lines... it never will be but I found one
surprising thing, if I save the array to disk and read it back in I
still get the same failure.
so essentially the snowflake is a Psudo-RNG and that's why trying to
simplify it does not work, because it has to be able to generate all of
those different numbers. but once we have the set of numbers the
generator becomes irrelevant.
Try this program:
http://www.compsalot.com/phpbug/kochsnowflake/simplefail/
weirdly, every failure is a -0.1
but there are two things that I'm concerned about.
1) It seems unlikely that the billing program was only failing on that
amount, it is a pretty unusual amount. Not one I'd normally expect to
see and there were a lot of failures.
2) I'm concerned about the limitations of the detection method. I am
only finding bad values because they have a colon in the string. I am
not currently checking for mathematical correctness. We may not be
seeing the whole story, there could be a lot more bad values that just
are not blatant enough to be observed.
But at least this should give you the starting point that you are asking
for. The program is reduced to reading a file from disk and checking
each number to see if it's valid. can't get any simpler than that.
Of course if the corruption is happening when the value is created,
looking at them after the fact may still not help much. But when I look
at these values in the eclipse zend debugger, they look normal enough
despite the fact that they can't be properly converted.
--
The data files are as follows:
rawpairs.txt is a 6.5meg file and contains both good and bad values,
you don't need this file unless you are trying to validate the
serialization. This is from a single run of the snowflake, $Nest = 3;
$Depth = 5;
The following were extracted from the raw data.
onepair.txt contains a single failure item
selectpairs.txt contains 8 failures which were from a single run of
snowflake
manypairs.txt contains about 40 failures which are the result of
multiple runs of the snowflake using different Nest & Depth parameters.
[2010-03-26 11:14:13] paj...@php.net
Does it happen always? Can you try to make a script with only this
function call with the values causing this effect?
[2010-03-26 11:11:05] codeslinger at compsalot dot com
String conversion errors
There is a flag called $FloatType
You can use it to select the type of conversion that is done.
//this fails with string conversion error
case 0: $s = (string)$f;
//this fails with string conversion error
case 12: $s = is_float($f) ? sprintf('%.12F', $f) : (string)$f;
//this fails with string conversion error
case 14: $s = is_float($f) ? sprintf('%.14F', $f) : (string)$f;
//this W
Bug #51402 [Bgs]: popen() not work correctly!
Edit report at http://bugs.php.net/bug.php?id=51402&edit=1
ID: 51402
Updated by: paj...@php.net
Reported by: stefano at supergenesis dot it
Summary: popen() not work correctly!
Status: Bogus
Type: Bug
Package: Filesystem function related
Operating System: Windows 7
PHP Version: 5.3.2
New Comment:
It works just fine. If you have issues (other than this GUI problem),
please explain them.
Previous Comments:
[2010-03-26 16:22:48] stefano at supergenesis dot it
Ok, but in this mode open(); not work correctly on windows 7!
[2010-03-26 16:17:16] paj...@php.net
Not related to PHP, that's security and other settings in windows. Also
I don't see why one would allow that by default in a web either.
[2010-03-26 16:10:59] stefano at supergenesis dot it
Description:
I want to start gui application with use popen().
In windows xp i use pclose(popen("start /B calc.exe", "r")); and windows
open correctly the calculator.
In windows 7 this open a calculator but i show only in a process list,
and i not see the gui! Then in the services list i have set in the
connect tab, the propety interact with desktop.
The problem is now when i start open(...) windows 7 show me a strange
message "an application want show a message" and show me 2 button that i
can read message or not. If i click on read windows go in strange mode
and show me the calculator, after i have to click another button to
return from 'normal mode'.
What is this?!?!?
Expected result:
Open normal application without go in 'strange mode'!
--
Edit this bug report at http://bugs.php.net/bug.php?id=51402&edit=1
Bug #51396 [Fbk]: Math is Unreliable
Edit report at http://bugs.php.net/bug.php?id=51396&edit=1
ID: 51396
Updated by: paj...@php.net
Reported by: codeslinger at compsalot dot com
Summary: Math is Unreliable
Status: Feedback
Type: Bug
Package: Math related
Operating System: any
PHP Version: Irrelevant
New Comment:
Rasmus, he is not the only person. There are two other reports about it.
However he is the first one to experience it on non windows platform.
Previous Comments:
[2010-03-26 16:26:05] ras...@php.net
I ran your simplefail.php on all 4 data files. Never saw the failure
case.
Then I took just the huge rawpairs.txt file (had to increase the
memory_limit)
and modified your program slightly to do:
for($i=0;$i<10;$i++) ConvertData($data);
and ran that, which took quite a while. Still no failures.
You are still the only person who has ever reported these weird ":"
characters
showing up, and you have yet to produce any sort of code that reproduces
it for
someone else. We'll keep trying, but something that happens for 1
person out of
millions is suspicious.
[2010-03-26 15:28:16] codeslinger at compsalot dot com
it's still not 20 lines... it never will be but I found one
surprising thing, if I save the array to disk and read it back in I
still get the same failure.
so essentially the snowflake is a Psudo-RNG and that's why trying to
simplify it does not work, because it has to be able to generate all of
those different numbers. but once we have the set of numbers the
generator becomes irrelevant.
Try this program:
http://www.compsalot.com/phpbug/kochsnowflake/simplefail/
weirdly, every failure is a -0.1
but there are two things that I'm concerned about.
1) It seems unlikely that the billing program was only failing on that
amount, it is a pretty unusual amount. Not one I'd normally expect to
see and there were a lot of failures.
2) I'm concerned about the limitations of the detection method. I am
only finding bad values because they have a colon in the string. I am
not currently checking for mathematical correctness. We may not be
seeing the whole story, there could be a lot more bad values that just
are not blatant enough to be observed.
But at least this should give you the starting point that you are asking
for. The program is reduced to reading a file from disk and checking
each number to see if it's valid. can't get any simpler than that.
Of course if the corruption is happening when the value is created,
looking at them after the fact may still not help much. But when I look
at these values in the eclipse zend debugger, they look normal enough
despite the fact that they can't be properly converted.
--
The data files are as follows:
rawpairs.txt is a 6.5meg file and contains both good and bad values,
you don't need this file unless you are trying to validate the
serialization. This is from a single run of the snowflake, $Nest = 3;
$Depth = 5;
The following were extracted from the raw data.
onepair.txt contains a single failure item
selectpairs.txt contains 8 failures which were from a single run of
snowflake
manypairs.txt contains about 40 failures which are the result of
multiple runs of the snowflake using different Nest & Depth parameters.
[2010-03-26 11:14:13] paj...@php.net
Does it happen always? Can you try to make a script with only this
function call with the values causing this effect?
[2010-03-26 11:11:05] codeslinger at compsalot dot com
String conversion errors
There is a flag called $FloatType
You can use it to select the type of conversion that is done.
//this fails with string conversion error
case 0: $s = (string)$f;
//this fails with string conversion error
case 12: $s = is_float($f) ? sprintf('%.12F', $f) : (string)$f;
//this fails with string conversion error
case 14: $s = is_float($f) ? sprintf('%.14F', $f) : (string)$f;
//this WORKS, does not cause a string conversion error
case 20: $s = is_float($f) ? sprintf('%.20F', $f) : (string)$f;
When I say conversion error, I mean that the result is "0.0:" not that
php gives any kind of error message.
[2010-03-26 10:23:27] codeslinger at compsalot dot com
quote: Btw, it could be due to bad initialized data as well
I don't understand the question/statement.
The program generates all of it's data.
If you look near the bottom of pov.pco.php you will see the following
line:
echo "FATAL ERROR: PHP Math is Corrupt Again!!! idx = $idx\n";
Bug #51396 [Fbk]: Math is Unreliable
Edit report at http://bugs.php.net/bug.php?id=51396&edit=1
ID: 51396
Updated by: ras...@php.net
Reported by: codeslinger at compsalot dot com
Summary: Math is Unreliable
Status: Feedback
Type: Bug
Package: Math related
Operating System: any
PHP Version: Irrelevant
New Comment:
I ran your simplefail.php on all 4 data files. Never saw the failure
case.
Then I took just the huge rawpairs.txt file (had to increase the
memory_limit)
and modified your program slightly to do:
for($i=0;$i<10;$i++) ConvertData($data);
and ran that, which took quite a while. Still no failures.
You are still the only person who has ever reported these weird ":"
characters
showing up, and you have yet to produce any sort of code that reproduces
it for
someone else. We'll keep trying, but something that happens for 1
person out of
millions is suspicious.
Previous Comments:
[2010-03-26 15:28:16] codeslinger at compsalot dot com
it's still not 20 lines... it never will be but I found one
surprising thing, if I save the array to disk and read it back in I
still get the same failure.
so essentially the snowflake is a Psudo-RNG and that's why trying to
simplify it does not work, because it has to be able to generate all of
those different numbers. but once we have the set of numbers the
generator becomes irrelevant.
Try this program:
http://www.compsalot.com/phpbug/kochsnowflake/simplefail/
weirdly, every failure is a -0.1
but there are two things that I'm concerned about.
1) It seems unlikely that the billing program was only failing on that
amount, it is a pretty unusual amount. Not one I'd normally expect to
see and there were a lot of failures.
2) I'm concerned about the limitations of the detection method. I am
only finding bad values because they have a colon in the string. I am
not currently checking for mathematical correctness. We may not be
seeing the whole story, there could be a lot more bad values that just
are not blatant enough to be observed.
But at least this should give you the starting point that you are asking
for. The program is reduced to reading a file from disk and checking
each number to see if it's valid. can't get any simpler than that.
Of course if the corruption is happening when the value is created,
looking at them after the fact may still not help much. But when I look
at these values in the eclipse zend debugger, they look normal enough
despite the fact that they can't be properly converted.
--
The data files are as follows:
rawpairs.txt is a 6.5meg file and contains both good and bad values,
you don't need this file unless you are trying to validate the
serialization. This is from a single run of the snowflake, $Nest = 3;
$Depth = 5;
The following were extracted from the raw data.
onepair.txt contains a single failure item
selectpairs.txt contains 8 failures which were from a single run of
snowflake
manypairs.txt contains about 40 failures which are the result of
multiple runs of the snowflake using different Nest & Depth parameters.
[2010-03-26 11:14:13] paj...@php.net
Does it happen always? Can you try to make a script with only this
function call with the values causing this effect?
[2010-03-26 11:11:05] codeslinger at compsalot dot com
String conversion errors
There is a flag called $FloatType
You can use it to select the type of conversion that is done.
//this fails with string conversion error
case 0: $s = (string)$f;
//this fails with string conversion error
case 12: $s = is_float($f) ? sprintf('%.12F', $f) : (string)$f;
//this fails with string conversion error
case 14: $s = is_float($f) ? sprintf('%.14F', $f) : (string)$f;
//this WORKS, does not cause a string conversion error
case 20: $s = is_float($f) ? sprintf('%.20F', $f) : (string)$f;
When I say conversion error, I mean that the result is "0.0:" not that
php gives any kind of error message.
[2010-03-26 10:23:27] codeslinger at compsalot dot com
quote: Btw, it could be due to bad initialized data as well
I don't understand the question/statement.
The program generates all of it's data.
If you look near the bottom of pov.pco.php you will see the following
line:
echo "FATAL ERROR: PHP Math is Corrupt Again!!! idx = $idx\n";
If you set a breakpoint there in a php debugger and examine the vaules
you will see that that array contains a float of 0.1
and that the string it was converted to is "0.0:"
[201
Bug #51402 [Bgs]: popen() not work correctly!
Edit report at http://bugs.php.net/bug.php?id=51402&edit=1
ID: 51402
User updated by: stefano at supergenesis dot it
Reported by: stefano at supergenesis dot it
Summary: popen() not work correctly!
Status: Bogus
Type: Bug
Package: Filesystem function related
Operating System: Windows 7
PHP Version: 5.3.2
New Comment:
Ok, but in this mode open(); not work correctly on windows 7!
Previous Comments:
[2010-03-26 16:17:16] paj...@php.net
Not related to PHP, that's security and other settings in windows. Also
I don't see why one would allow that by default in a web either.
[2010-03-26 16:10:59] stefano at supergenesis dot it
Description:
I want to start gui application with use popen().
In windows xp i use pclose(popen("start /B calc.exe", "r")); and windows
open correctly the calculator.
In windows 7 this open a calculator but i show only in a process list,
and i not see the gui! Then in the services list i have set in the
connect tab, the propety interact with desktop.
The problem is now when i start open(...) windows 7 show me a strange
message "an application want show a message" and show me 2 button that i
can read message or not. If i click on read windows go in strange mode
and show me the calculator, after i have to click another button to
return from 'normal mode'.
What is this?!?!?
Expected result:
Open normal application without go in 'strange mode'!
--
Edit this bug report at http://bugs.php.net/bug.php?id=51402&edit=1
Bug #51402 [Opn->Bgs]: popen() not work correctly!
Edit report at http://bugs.php.net/bug.php?id=51402&edit=1
ID: 51402
Updated by: paj...@php.net
Reported by: stefano at supergenesis dot it
Summary: popen() not work correctly!
-Status: Open
+Status: Bogus
Type: Bug
Package: Filesystem function related
Operating System: Windows 7
PHP Version: 5.3.2
New Comment:
Not related to PHP, that's security and other settings in windows. Also
I don't see why one would allow that by default in a web either.
Previous Comments:
[2010-03-26 16:10:59] stefano at supergenesis dot it
Description:
I want to start gui application with use popen().
In windows xp i use pclose(popen("start /B calc.exe", "r")); and windows
open correctly the calculator.
In windows 7 this open a calculator but i show only in a process list,
and i not see the gui! Then in the services list i have set in the
connect tab, the propety interact with desktop.
The problem is now when i start open(...) windows 7 show me a strange
message "an application want show a message" and show me 2 button that i
can read message or not. If i click on read windows go in strange mode
and show me the calculator, after i have to click another button to
return from 'normal mode'.
What is this?!?!?
Expected result:
Open normal application without go in 'strange mode'!
--
Edit this bug report at http://bugs.php.net/bug.php?id=51402&edit=1
[PHP-BUG] Bug #51402 [NEW]: popen() not work correctly!
From:
Operating system: Windows 7
PHP version: 5.3.2
Package: Filesystem function related
Bug Type: Bug
Bug description:popen() not work correctly!
Description:
I want to start gui application with use popen().
In windows xp i use pclose(popen("start /B calc.exe", "r")); and windows
open correctly the calculator.
In windows 7 this open a calculator but i show only in a process list, and
i not see the gui! Then in the services list i have set in the connect tab,
the propety interact with desktop.
The problem is now when i start open(...) windows 7 show me a strange
message "an application want show a message" and show me 2 button that i
can read message or not. If i click on read windows go in strange mode and
show me the calculator, after i have to click another button to return from
'normal mode'.
What is this?!?!?
Expected result:
Open normal application without go in 'strange mode'!
--
Edit bug report at http://bugs.php.net/bug.php?id=51402&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51402&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51402&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51402&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51402&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51402&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51402&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51402&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51402&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51402&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51402&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51402&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51402&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51402&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51402&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51402&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51402&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51402&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51402&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51402&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51402&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51402&r=mysqlcfg
Bug #51399 [Opn->Fbk]: *** glibc detected *** /usr/sbin/httpd: double free or corruption (!prev)
Edit report at http://bugs.php.net/bug.php?id=51399&edit=1 ID: 51399 Updated by: der...@php.net Reported by: jitendra dot admin at gmail dot com Summary: *** glibc detected *** /usr/sbin/httpd: double free or corruption (!prev) -Status: Open +Status: Feedback Type: Bug Package: Apache related Operating System: Debian 5.0 PHP Version: Irrelevant New Comment: Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Previous Comments: [2010-03-26 13:46:33] jitendra dot admin at gmail dot com Description: Debian 5.0 (2.6.26-2-686 #1 SMP ) ii linux-image-2.6-686 2.6.26+17+lenny1 Linux 2.6 image on PPro/Celeron/PII/PIII/P4 ii linux-image-2.6.26-2-686 2.6.26-21lenny3Linux 2.6.26 image on PPro/Celeron/PII/PIII/P4 ii linux-libc-dev2.6.26-21lenny3Linux support headers for userspace development ### GCC: ii gcc 4:4.3.2-2 The GNU C compiler ii gcc-4.1-base 4.1.2-25 The GNU Compiler Collection (base package) ii gcc-4.2-base 4.2.4-6The GNU Compiler Collection (base package) ii gcc-4.3 4.3.2-1.1 The GNU C compiler ii gcc-4.3-base 4.3.2-1.1 The GNU Compiler Collection (base package) ii gcc-4.3-locales 4.3.2-1.1 The GNU C compiler (native language support files) ii gcc-4.3-multilib 4.3.2-1.1 The GNU C compiler (multilib files) ii gcc-multilib 4:4.3.2-2 The GNU C compiler (multilib files) ii lib64gcc1 1:4.3.2-1.1GCC support library (64bit) ii libgcc1 1:4.3.2-1.1GCC support library ii libgcc1-dbg 1:4.3.2-1.1GCC support library (debug symbols) ### =>libc: ii klibc-utils 1.5.12-2 small utilities built with klibc for early boot ii libc6 2.7-18lenny2 GNU C Library: Shared libraries ii libc6-amd64 2.7-18lenny2 GNU C Library: 64bit Shared libraries for AMD64 ii libc6-dev 2.7-18lenny2 GNU C Library: Development Libraries and Header Files ii libc6-dev-amd64 2.7-18lenny2 GNU C Library: 64bit Development Libraries for AMD64 ii libc6-i6862.7-18lenny2 GNU C Library: Shared libraries [i686 optimized] ii libcap1 1:1.10-14 support for getting/setting POSIX.1e capabilities ii libcomerr21.41.3-1 common error description library ii libcompress-raw-zlib-perl 2.012-1lenny1 low-level interface to zlib compression library ii libcompress-zlib-perl 2.012-1Perl module for creation and manipulation of gzip files ii libconsole1:0.2.3dbs-65.1Shared libraries for Linux console and font manipulation ii libconvert-binhex-perl1.119+pristine-3 Perl5 module for extracting data from macintosh BinHex files ii libcrypt-ssleay-perl 0.57-1+b1 Support for https protocol in LWP ii libcups2 1.3.8-1+lenny7 Common UNIX Printing System(tm) - libs ii libcupsimage2 1.3.8-1+lenny7 Common UNIX Printing System(tm) - image libs ii libcwidget3 0.5.12-4 high-level terminal interface library for C++ (runtime files) ii libklibc 1.5.12-2 minimal libc subset for use with initramfs ii liblocale-gettext-perl1.05-4 Using libc functions for internationalization in Perl ii linux-libc-dev2.6.26-21lenny3Linux support headers for userspace development ii zlibc 0.9k-4 An on-fly auto-uncompressing C library ### =>APACHE: apache_1.3.41 => PHP: php-5.1.5 ### Suddenly i am getting high load (CPU,Memory), as well as this error at the time of shutdown the apache.. [Thu Mar 25 09:49:
Bug #51396 [Com]: Math is Unreliable
Edit report at http://bugs.php.net/bug.php?id=51396&edit=1
ID: 51396
Comment by: codeslinger at compsalot dot com
Reported by: codeslinger at compsalot dot com
Summary: Math is Unreliable
Status: Feedback
Type: Bug
Package: Math related
Operating System: any
PHP Version: Irrelevant
New Comment:
it's still not 20 lines... it never will be but I found one
surprising thing, if I save the array to disk and read it back in I
still get the same failure.
so essentially the snowflake is a Psudo-RNG and that's why trying to
simplify it does not work, because it has to be able to generate all of
those different numbers. but once we have the set of numbers the
generator becomes irrelevant.
Try this program:
http://www.compsalot.com/phpbug/kochsnowflake/simplefail/
weirdly, every failure is a -0.1
but there are two things that I'm concerned about.
1) It seems unlikely that the billing program was only failing on that
amount, it is a pretty unusual amount. Not one I'd normally expect to
see and there were a lot of failures.
2) I'm concerned about the limitations of the detection method. I am
only finding bad values because they have a colon in the string. I am
not currently checking for mathematical correctness. We may not be
seeing the whole story, there could be a lot more bad values that just
are not blatant enough to be observed.
But at least this should give you the starting point that you are asking
for. The program is reduced to reading a file from disk and checking
each number to see if it's valid. can't get any simpler than that.
Of course if the corruption is happening when the value is created,
looking at them after the fact may still not help much. But when I look
at these values in the eclipse zend debugger, they look normal enough
despite the fact that they can't be properly converted.
--
The data files are as follows:
rawpairs.txt is a 6.5meg file and contains both good and bad values,
you don't need this file unless you are trying to validate the
serialization. This is from a single run of the snowflake, $Nest = 3;
$Depth = 5;
The following were extracted from the raw data.
onepair.txt contains a single failure item
selectpairs.txt contains 8 failures which were from a single run of
snowflake
manypairs.txt contains about 40 failures which are the result of
multiple runs of the snowflake using different Nest & Depth parameters.
Previous Comments:
[2010-03-26 11:14:13] paj...@php.net
Does it happen always? Can you try to make a script with only this
function call with the values causing this effect?
[2010-03-26 11:11:05] codeslinger at compsalot dot com
String conversion errors
There is a flag called $FloatType
You can use it to select the type of conversion that is done.
//this fails with string conversion error
case 0: $s = (string)$f;
//this fails with string conversion error
case 12: $s = is_float($f) ? sprintf('%.12F', $f) : (string)$f;
//this fails with string conversion error
case 14: $s = is_float($f) ? sprintf('%.14F', $f) : (string)$f;
//this WORKS, does not cause a string conversion error
case 20: $s = is_float($f) ? sprintf('%.20F', $f) : (string)$f;
When I say conversion error, I mean that the result is "0.0:" not that
php gives any kind of error message.
[2010-03-26 10:23:27] codeslinger at compsalot dot com
quote: Btw, it could be due to bad initialized data as well
I don't understand the question/statement.
The program generates all of it's data.
If you look near the bottom of pov.pco.php you will see the following
line:
echo "FATAL ERROR: PHP Math is Corrupt Again!!! idx = $idx\n";
If you set a breakpoint there in a php debugger and examine the vaules
you will see that that array contains a float of 0.1
and that the string it was converted to is "0.0:"
[2010-03-26 10:17:47] codeslinger at compsalot dot com
Thank You for the response.
This program executes thousands of identical loops
it performs a number format conversion on each of those thousands of
numbers in it's array.
Out of all of those thousands of identical conversions about 4 of them
will produce an invalid result.
for this specific program, if I skip the array_merge (see $Nest) then
the bug does not occur.
Every time I make a change to the loops etc. the behavior changes, even
to where the bug is not triggered. I have already simplified this
program quite a bit and the result was that it now fails at a totally
different array index then when I first observed the pro
Bug #51400 [Opn->Bgs]: mysql_fetch_array() returns NULL
Edit report at http://bugs.php.net/bug.php?id=51400&edit=1 ID: 51400 Updated by: johan...@php.net Reported by: aa at marcandi dot com Summary: mysql_fetch_array() returns NULL -Status: Open +Status: Bogus Type: Bug Package: MySQL related Operating System: CentOS 5.2 (64-bit) PHP Version: 5.3.2 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 The documentation states If the parameters given to a function are not what it expects, such as passing an array where a string is expected, the return value of the function is undefined. In this case it will likely return NULL but this is just a convention, and cannot be relied upon. http://www.php.net/manual/en/functions.internal.php You are passing "false" to a function expecting a "mysql result resource" Previous Comments: [2010-03-26 14:56:18] aa at marcandi dot com Description: Calling mysql_fetch_array() with an empty/errorneous result set returns NULL, not FALSE. This is a behavioral change from 5.2.10. Documentation says: "Returns an array of strings that corresponds to the fetched row, or FALSE if there are no more rows." Test script: --- $r = @mysql_query( 'This is a broken query' ); $f = @mysql_fetch_array( $r ); print var_dump( $f ); Expected result: FALSE Actual result: -- NULL -- Edit this bug report at http://bugs.php.net/bug.php?id=51400&edit=1
Bug #43682 [Com]: domain/subdomain problems with session cookies
Edit report at http://bugs.php.net/bug.php?id=43682&edit=1
ID: 43682
Comment by: serhio_forever at yahoo dot com
Reported by: k dot andris at gmail dot com
Summary: domain/subdomain problems with session cookies
Status: Closed
Type: Bug
Package: Session related
Operating System: Debian Sarge
PHP Version: 5.2.4
New Comment:
To "k dot andris at gmail dot com"
You're right. Had exactly the same problem.
Solution. Just add these 2 lines in your php.ini file:
suhosin.session.cryptdocroot=Off
suhosin.cookie.cryptdocroot=Off
or, if you don't have access to it, these 2 in some of your general
config.php file:
ini_set("suhosin.session.cryptdocroot", "Off");
ini_set("suhosin.cookie.cryptdocroot", "Off");
Previous Comments:
[2008-04-13 22:50:50] k dot andris at gmail dot com
Actually Suhosin's suhosin.session.cryptdocroot option was the problem.
If the session encryption key is based on the DocRoot it causes the
problem described here (if the base domain and the subdomains are served
from different directories).
[2008-02-21 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".
[2008-02-13 18:39:55] j...@php.net
I don't see how this is PHP bug at all. More like lighttpd bug if a bug
at all. Check these: What host PHP script gets from ligttpd
($_SERVER['SERVER_NAME'] and what is tried to be set for the cookie.
[2008-02-10 18:29:19] k dot andris at gmail dot com
I found it! The problem only occours if you serve the base domain and
the subdomains from different sections of lighttpd config file, like
this:
$HTTP["host"] =~ "^mysite\.com" {
server.document-root = "/var/www/mysite/"
}
$HTTP["host"] =~ "(.+)\.mysite\.com$" {
server.document-root = "/var/www/mysubdomains/"
}
[2008-02-10 18:17:20] k dot andris at gmail dot com
It seems to work on another server. I'll try to find out what was wrong
with the first one. Sorry..
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=43682
--
Edit this bug report at http://bugs.php.net/bug.php?id=43682&edit=1
[PHP-BUG] Bug #51400 [NEW]: mysql_fetch_array() returns NULL
From: Operating system: CentOS 5.2 (64-bit) PHP version: 5.3.2 Package: MySQL related Bug Type: Bug Bug description:mysql_fetch_array() returns NULL Description: Calling mysql_fetch_array() with an empty/errorneous result set returns NULL, not FALSE. This is a behavioral change from 5.2.10. Documentation says: "Returns an array of strings that corresponds to the fetched row, or FALSE if there are no more rows." Test script: --- $r = @mysql_query( 'This is a broken query' ); $f = @mysql_fetch_array( $r ); print var_dump( $f ); Expected result: FALSE Actual result: -- NULL -- Edit bug report at http://bugs.php.net/bug.php?id=51400&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=51400&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=51400&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=51400&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=51400&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=51400&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=51400&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=51400&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=51400&r=needscript Try newer version: http://bugs.php.net/fix.php?id=51400&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=51400&r=support Expected behavior: http://bugs.php.net/fix.php?id=51400&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=51400&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=51400&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=51400&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51400&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=51400&r=dst IIS Stability: http://bugs.php.net/fix.php?id=51400&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=51400&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=51400&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=51400&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=51400&r=mysqlcfg
Bug #50271 [PATCH]: Windows hard coding of CMD / COMMAND.COM rather than envvar(COMSPEC)
Edit report at http://bugs.php.net/bug.php?id=50271&edit=1
ID: 50271
Patch added by: rquadl...@php.net
Reported by: RQuadling at GMail dot com
Summary: Windows hard coding of CMD / COMMAND.COM rather than
envvar(COMSPEC)
Status: Open
Type: Bug
Package: Program Execution
Operating System: win32 only - Windows XP SP3
PHP Version: 5.3SVN-2009-11-23 (SVN)
New Comment:
The following patch has been added/updated:
Patch Name: proc_open_COMSPEC.patch
Revision: 1269610539
URL:
http://bugs.php.net/patch-display.php?bug=50271&patch=proc_open_COMSPEC.patch&revision=1269610539
Previous Comments:
[2010-03-26 14:05:26] rquadl...@php.net
The following patch has been added/updated:
Patch Name: TSRM_Win32_COMSPEC.patch
Revision: 1269608726
URL:
http://bugs.php.net/patch-display.php?bug=50271&patch=TSRM_Win32_COMSPEC.patch&revision=1269608726
[2009-11-23 13:31:13] j...@php.net
FYI: In the future when a bug is clearly windows only, use os prefix
'win32 only -' to preserve my sanity..
[2009-11-23 13:15:31] RQuadling at GMail dot com
Description:
In http://lxr.php.net/source/TSRM/tsrm_win32.c#52, the shell to execute
is hardcoded.
This should be retrieved via GetEnvironmentVariable('COMSPEC', ...);
As such, any program called cmd.exe (or command.com for older, and now
unsupported by PHP, versions of windows) in a directory accessible via
the PATH _before_ the actual location of cmd.exe/command.com will be
loaded for the shell.
The environment variable "COMSPEC" (now known as "ComSpec", but is case
insensitive for Windows) by default includes the path.
Whilst this is not a series bug, it does mean PHP conforms to other
languages and applications that can invoke a console shell via COMSPEC,
rather than using a hard-coded name.
Considering that PHP doesn't support older versions of windows any
longer, the whole test on GetVersion() is also redundant.
--
Edit this bug report at http://bugs.php.net/bug.php?id=50271&edit=1
Bug #48551 [Com]: Unable to compile
Edit report at http://bugs.php.net/bug.php?id=48551&edit=1 ID: 48551 Comment by: holger dot dippel at umassd dot edu Reported by: hckurniawan at gmail dot com Summary: Unable to compile Status: Bogus Type: Bug Package: Compile Failure Operating System: Debian 5 PHP Version: 5.3.0RC3 New Comment: I am compiling PHP 5.3.2 on RHEL 2.6.9 and notice the following: It compiles fine with a non-MPM version of Apache 2.2.9 on a standard kernel. On an otherwise identical system running a SMP kernel and a MPM-worker build of Apache, PHP fails to compile with the same error. Some other online forum suggests that this error goes back to a problem with the php-cli build. Previous Comments: [2010-03-08 21:53:19] jachym dot tousek at gmail dot com I've exactly the same problem with stable PHP 5.3.2. When i use snapshot, it takes lng time with just "Generating phar.php" and nothing else happened. [2009-06-15 12:15:41] hckurniawan at gmail dot com Thank you Jani for confirming. I tried the snapshot, and it worked. [2009-06-15 11:55:41] j...@php.net Works for me. [2009-06-15 11:50:30] hckurniawan at gmail dot com I'm sorry, I was trying to test RC3 RELEASE (since you ARE calling for testers)! I didn't know I have to go test the snapshot too I took the time to test it. At least you can take the time to confirm (or not-confirm) the bug. [2009-06-15 08:38:55] j...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ 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=48551 -- Edit this bug report at http://bugs.php.net/bug.php?id=48551&edit=1
Bug #50271 [PATCH]: Windows hard coding of CMD / COMMAND.COM rather than envvar(COMSPEC)
Edit report at http://bugs.php.net/bug.php?id=50271&edit=1
ID: 50271
Patch added by: rquadl...@php.net
Reported by: RQuadling at GMail dot com
Summary: Windows hard coding of CMD / COMMAND.COM rather than
envvar(COMSPEC)
Status: Open
Type: Bug
Package: Program Execution
Operating System: win32 only - Windows XP SP3
PHP Version: 5.3SVN-2009-11-23 (SVN)
New Comment:
The following patch has been added/updated:
Patch Name: TSRM_Win32_COMSPEC.patch
Revision: 1269608726
URL:
http://bugs.php.net/patch-display.php?bug=50271&patch=TSRM_Win32_COMSPEC.patch&revision=1269608726
Previous Comments:
[2009-11-23 13:31:13] j...@php.net
FYI: In the future when a bug is clearly windows only, use os prefix
'win32 only -' to preserve my sanity..
[2009-11-23 13:15:31] RQuadling at GMail dot com
Description:
In http://lxr.php.net/source/TSRM/tsrm_win32.c#52, the shell to execute
is hardcoded.
This should be retrieved via GetEnvironmentVariable('COMSPEC', ...);
As such, any program called cmd.exe (or command.com for older, and now
unsupported by PHP, versions of windows) in a directory accessible via
the PATH _before_ the actual location of cmd.exe/command.com will be
loaded for the shell.
The environment variable "COMSPEC" (now known as "ComSpec", but is case
insensitive for Windows) by default includes the path.
Whilst this is not a series bug, it does mean PHP conforms to other
languages and applications that can invoke a console shell via COMSPEC,
rather than using a hard-coded name.
Considering that PHP doesn't support older versions of windows any
longer, the whole test on GetVersion() is also redundant.
--
Edit this bug report at http://bugs.php.net/bug.php?id=50271&edit=1
[PHP-BUG] Bug #51399 [NEW]: *** glibc detected *** /usr/sbin/httpd: double free or corruption (!prev)
From: Operating system: Debian 5.0 PHP version: Irrelevant Package: Apache related Bug Type: Bug Bug description:*** glibc detected *** /usr/sbin/httpd: double free or corruption (!prev) Description: Debian 5.0 (2.6.26-2-686 #1 SMP ) ii linux-image-2.6-686 2.6.26+17+lenny1 Linux 2.6 image on PPro/Celeron/PII/PIII/P4 ii linux-image-2.6.26-2-686 2.6.26-21lenny3Linux 2.6.26 image on PPro/Celeron/PII/PIII/P4 ii linux-libc-dev2.6.26-21lenny3Linux support headers for userspace development ### GCC: ii gcc 4:4.3.2-2 The GNU C compiler ii gcc-4.1-base 4.1.2-25 The GNU Compiler Collection (base package) ii gcc-4.2-base 4.2.4-6The GNU Compiler Collection (base package) ii gcc-4.3 4.3.2-1.1 The GNU C compiler ii gcc-4.3-base 4.3.2-1.1 The GNU Compiler Collection (base package) ii gcc-4.3-locales 4.3.2-1.1 The GNU C compiler (native language support files) ii gcc-4.3-multilib 4.3.2-1.1 The GNU C compiler (multilib files) ii gcc-multilib 4:4.3.2-2 The GNU C compiler (multilib files) ii lib64gcc1 1:4.3.2-1.1GCC support library (64bit) ii libgcc1 1:4.3.2-1.1GCC support library ii libgcc1-dbg 1:4.3.2-1.1GCC support library (debug symbols) ### =>libc: ii klibc-utils 1.5.12-2 small utilities built with klibc for early boot ii libc6 2.7-18lenny2 GNU C Library: Shared libraries ii libc6-amd64 2.7-18lenny2 GNU C Library: 64bit Shared libraries for AMD64 ii libc6-dev 2.7-18lenny2 GNU C Library: Development Libraries and Header Files ii libc6-dev-amd64 2.7-18lenny2 GNU C Library: 64bit Development Libraries for AMD64 ii libc6-i6862.7-18lenny2 GNU C Library: Shared libraries [i686 optimized] ii libcap1 1:1.10-14 support for getting/setting POSIX.1e capabilities ii libcomerr21.41.3-1 common error description library ii libcompress-raw-zlib-perl 2.012-1lenny1 low-level interface to zlib compression library ii libcompress-zlib-perl 2.012-1Perl module for creation and manipulation of gzip files ii libconsole1:0.2.3dbs-65.1Shared libraries for Linux console and font manipulation ii libconvert-binhex-perl1.119+pristine-3 Perl5 module for extracting data from macintosh BinHex files ii libcrypt-ssleay-perl 0.57-1+b1 Support for https protocol in LWP ii libcups2 1.3.8-1+lenny7 Common UNIX Printing System(tm) - libs ii libcupsimage2 1.3.8-1+lenny7 Common UNIX Printing System(tm) - image libs ii libcwidget3 0.5.12-4 high-level terminal interface library for C++ (runtime files) ii libklibc 1.5.12-2 minimal libc subset for use with initramfs ii liblocale-gettext-perl1.05-4 Using libc functions for internationalization in Perl ii linux-libc-dev2.6.26-21lenny3Linux support headers for userspace development ii zlibc 0.9k-4 An on-fly auto-uncompressing C library ### =>APACHE: apache_1.3.41 => PHP: php-5.1.5 ### Suddenly i am getting high load (CPU,Memory), as well as this error at the time of shutdown the apache.. [Thu Mar 25 09:49:46 2010] [warn] child process 4431 still did not exit, sending a SIGTERM [Thu Mar 25 09:49:46 2010] [warn] child process 4432 still did not exit, sending a SIGTERM *** glibc detected *** /usr/sbin/httpd: double free or corruption (!prev): 0x08100bf8 *** *** glibc detected *** /usr/sbin/httpd: double free or corruption (!prev): 0x08100bf8 *** *** glibc detected *** /usr/sbin/httpd: double free or corruption (!prev): 0x0812e398 *** *** glibc detected *** /usr/sbin/httpd: double free or corruption (!prev): 0x08100bf8 ***
Bug #51397 [Opn->Ver]: Math calculation bug
Edit report at http://bugs.php.net/bug.php?id=51397&edit=1
ID: 51397
Updated by: f...@php.net
Reported by: emanuel dot dejanu at humaninfo dot ro
Summary: Math calculation bug
-Status: Open
+Status: Verified
Type: Bug
Package: Scripting Engine problem
Operating System: FREEBSD & LINUX
PHP Version: 5.2.13
New Comment:
Verified with 5.2.13 on Debian (default configure)
Verified in the Debian 5.2.6+lenny4 PHP (just for completeness)
Correct result with 5.3.2 on Gentoo
Previous Comments:
[2010-03-26 08:20:19] emanuel dot dejanu at humaninfo dot ro
Description:
I have used the code from the test script on my development machine
(Windows Professional 7 32bit) with php 5.2.12 and is working correctly
but when I have deployed on my production machine that is FreeBSD 6.3
32bit with the same php version 5.2.12 is giving wrong results
(-2147483593). I also run this on other production machine that is
RedHat 5 32bit with php 5.2.6 and is also giving wrong results
(-2147483593).
I can not test with php 5.2.13 on production machines (virtual
hosting).
On windows is giving the correctly result (754303898) with PHP 5.2.12
and PHP 5.3.1. I am running in 32bit platform on all machines.
---
PHP_INT_SIZE: 4
System => FreeBSD somehost.com 6.3-RELEASE FreeBSD 6.3-RELEASE #6: Wed
Oc
t 21 09:32:42 MDT 2009 r...@fc:/usr/src/sys/i386/compile/VKERN i386
Build Date => Mar 3 2010 12:51:00
Configure Command => './configure' '--with-layout=GNU'
'--with-config-file-sca
n-dir=/usr/local/etc/php' '--disable-all' '--enable-libxml'
'--with-libxml-dir=/
usr/local' '--enable-reflection' '--program-prefix=' '--enable-fastcgi'
'--with-
apxs2=/usr/local/sbin/apxs' '--with-regex=php' '--with-zend-vm=CALL'
'--prefix=/
usr/local' '--mandir=/usr/local/man' '--infodir=/usr/local/info/'
'--build=i386-
portbld-freebsd6.3'
Server API => Command Line Interface
Virtual Directory Support => disabled
Configuration File (php.ini) Path => /usr/local/etc
Loaded Configuration File => /usr/local/etc/php.ini
Scan this dir for additional .ini files => /usr/local/etc/php
additional .ini files parsed => /usr/local/etc/php/extensions.ini
PHP API => 20041225
PHP Extension => 20060613
Zend Extension => 220060519
Debug Build => no
Test script:
---
function myhash($key) {
$h = 5381;
$l = strlen($key);
for($i = 0; $i < $l; ++$i) {
$h = (($h << 5) + $h) ^ ord($key[$i]);
}
return $h;
}
$h = myhash('CL6.1.7');
if ($h != 754303898)
echo "bug\n";
echo $h . "\n";
Expected result:
754303898
Actual result:
--
bug
-2147483593
--
Edit this bug report at http://bugs.php.net/bug.php?id=51397&edit=1
Bug #51396 [Fbk]: Math is Unreliable
Edit report at http://bugs.php.net/bug.php?id=51396&edit=1
ID: 51396
Updated by: paj...@php.net
Reported by: codeslinger at compsalot dot com
Summary: Math is Unreliable
Status: Feedback
Type: Bug
Package: Math related
Operating System: any
PHP Version: Irrelevant
Assigned To: aharvey
New Comment:
Does it happen always? Can you try to make a script with only this
function call with the values causing this effect?
Previous Comments:
[2010-03-26 11:11:05] codeslinger at compsalot dot com
String conversion errors
There is a flag called $FloatType
You can use it to select the type of conversion that is done.
//this fails with string conversion error
case 0: $s = (string)$f;
//this fails with string conversion error
case 12: $s = is_float($f) ? sprintf('%.12F', $f) : (string)$f;
//this fails with string conversion error
case 14: $s = is_float($f) ? sprintf('%.14F', $f) : (string)$f;
//this WORKS, does not cause a string conversion error
case 20: $s = is_float($f) ? sprintf('%.20F', $f) : (string)$f;
When I say conversion error, I mean that the result is "0.0:" not that
php gives any kind of error message.
[2010-03-26 10:23:27] codeslinger at compsalot dot com
quote: Btw, it could be due to bad initialized data as well
I don't understand the question/statement.
The program generates all of it's data.
If you look near the bottom of pov.pco.php you will see the following
line:
echo "FATAL ERROR: PHP Math is Corrupt Again!!! idx = $idx\n";
If you set a breakpoint there in a php debugger and examine the vaules
you will see that that array contains a float of 0.1
and that the string it was converted to is "0.0:"
[2010-03-26 10:17:47] codeslinger at compsalot dot com
Thank You for the response.
This program executes thousands of identical loops
it performs a number format conversion on each of those thousands of
numbers in it's array.
Out of all of those thousands of identical conversions about 4 of them
will produce an invalid result.
for this specific program, if I skip the array_merge (see $Nest) then
the bug does not occur.
Every time I make a change to the loops etc. the behavior changes, even
to where the bug is not triggered. I have already simplified this
program quite a bit and the result was that it now fails at a totally
different array index then when I first observed the problem. The
trigger is very finicky.
XP is not a factor here, even though the original problem was found on
XP, I am running this Snowflake program on Ubuntu Linux.
converting a number to a string should never result in that string
containing a non-numeric character.
I can try to reduce this program further, but really and truly, it is
hard to trigger this -- but once triggered it is totally consistent and
repeatable.
[2010-03-26 10:11:25] paj...@php.net
Btw, it could be due to bad initialized data as well (as you experience
it on unix as well).
Can you try to run your script under valgrind too?
[2010-03-26 09:54:33] paj...@php.net
It looks to me in a bug at the number formatting in the Windows API (not
php dependent). Other users met this problem on old XP systems. You
could reproduce it using number_format only. Or maybe only with a single
printf function.
Can you try using another windows box or using 5.3.2-vc9 builds?
Btw, it is not about bad or good attitude but about having something we
can actually use to help you. I can understand your worries after having
spent hours to debug this problem, but we will still use a small script
to debug this problem, if any.
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=51396
--
Edit this bug report at http://bugs.php.net/bug.php?id=51396&edit=1
Bug #51396 [Com]: Math is Unreliable
Edit report at http://bugs.php.net/bug.php?id=51396&edit=1
ID: 51396
Comment by: codeslinger at compsalot dot com
Reported by: codeslinger at compsalot dot com
Summary: Math is Unreliable
Status: Feedback
Type: Bug
Package: Math related
Operating System: any
PHP Version: Irrelevant
Assigned To: aharvey
New Comment:
String conversion errors
There is a flag called $FloatType
You can use it to select the type of conversion that is done.
//this fails with string conversion error
case 0: $s = (string)$f;
//this fails with string conversion error
case 12: $s = is_float($f) ? sprintf('%.12F', $f) : (string)$f;
//this fails with string conversion error
case 14: $s = is_float($f) ? sprintf('%.14F', $f) : (string)$f;
//this WORKS, does not cause a string conversion error
case 20: $s = is_float($f) ? sprintf('%.20F', $f) : (string)$f;
When I say conversion error, I mean that the result is "0.0:" not that
php gives any kind of error message.
Previous Comments:
[2010-03-26 10:23:27] codeslinger at compsalot dot com
quote: Btw, it could be due to bad initialized data as well
I don't understand the question/statement.
The program generates all of it's data.
If you look near the bottom of pov.pco.php you will see the following
line:
echo "FATAL ERROR: PHP Math is Corrupt Again!!! idx = $idx\n";
If you set a breakpoint there in a php debugger and examine the vaules
you will see that that array contains a float of 0.1
and that the string it was converted to is "0.0:"
[2010-03-26 10:17:47] codeslinger at compsalot dot com
Thank You for the response.
This program executes thousands of identical loops
it performs a number format conversion on each of those thousands of
numbers in it's array.
Out of all of those thousands of identical conversions about 4 of them
will produce an invalid result.
for this specific program, if I skip the array_merge (see $Nest) then
the bug does not occur.
Every time I make a change to the loops etc. the behavior changes, even
to where the bug is not triggered. I have already simplified this
program quite a bit and the result was that it now fails at a totally
different array index then when I first observed the problem. The
trigger is very finicky.
XP is not a factor here, even though the original problem was found on
XP, I am running this Snowflake program on Ubuntu Linux.
converting a number to a string should never result in that string
containing a non-numeric character.
I can try to reduce this program further, but really and truly, it is
hard to trigger this -- but once triggered it is totally consistent and
repeatable.
[2010-03-26 10:11:25] paj...@php.net
Btw, it could be due to bad initialized data as well (as you experience
it on unix as well).
Can you try to run your script under valgrind too?
[2010-03-26 09:54:33] paj...@php.net
It looks to me in a bug at the number formatting in the Windows API (not
php dependent). Other users met this problem on old XP systems. You
could reproduce it using number_format only. Or maybe only with a single
printf function.
Can you try using another windows box or using 5.3.2-vc9 builds?
Btw, it is not about bad or good attitude but about having something we
can actually use to help you. I can understand your worries after having
spent hours to debug this problem, but we will still use a small script
to debug this problem, if any.
[2010-03-26 09:40:23] codeslinger at compsalot dot com
did you even LOOOKK at the script that I provided?
it is not that complicated. a few loops and some array allocations.
previous attempts to reduce this to anything simpler have been
unsuccessful.
this is exactly the attitude that causes me to be overwrought.
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=51396
--
Edit this bug report at http://bugs.php.net/bug.php?id=51396&edit=1
Bug #51396 [Com]: Math is Unreliable
Edit report at http://bugs.php.net/bug.php?id=51396&edit=1 ID: 51396 Comment by: codeslinger at compsalot dot com Reported by: codeslinger at compsalot dot com Summary: Math is Unreliable Status: Feedback Type: Bug Package: Math related Operating System: any PHP Version: Irrelevant Assigned To: aharvey New Comment: quote: Btw, it could be due to bad initialized data as well I don't understand the question/statement. The program generates all of it's data. If you look near the bottom of pov.pco.php you will see the following line: echo "FATAL ERROR: PHP Math is Corrupt Again!!! idx = $idx\n"; If you set a breakpoint there in a php debugger and examine the vaules you will see that that array contains a float of 0.1 and that the string it was converted to is "0.0:" Previous Comments: [2010-03-26 10:17:47] codeslinger at compsalot dot com Thank You for the response. This program executes thousands of identical loops it performs a number format conversion on each of those thousands of numbers in it's array. Out of all of those thousands of identical conversions about 4 of them will produce an invalid result. for this specific program, if I skip the array_merge (see $Nest) then the bug does not occur. Every time I make a change to the loops etc. the behavior changes, even to where the bug is not triggered. I have already simplified this program quite a bit and the result was that it now fails at a totally different array index then when I first observed the problem. The trigger is very finicky. XP is not a factor here, even though the original problem was found on XP, I am running this Snowflake program on Ubuntu Linux. converting a number to a string should never result in that string containing a non-numeric character. I can try to reduce this program further, but really and truly, it is hard to trigger this -- but once triggered it is totally consistent and repeatable. [2010-03-26 10:11:25] paj...@php.net Btw, it could be due to bad initialized data as well (as you experience it on unix as well). Can you try to run your script under valgrind too? [2010-03-26 09:54:33] paj...@php.net It looks to me in a bug at the number formatting in the Windows API (not php dependent). Other users met this problem on old XP systems. You could reproduce it using number_format only. Or maybe only with a single printf function. Can you try using another windows box or using 5.3.2-vc9 builds? Btw, it is not about bad or good attitude but about having something we can actually use to help you. I can understand your worries after having spent hours to debug this problem, but we will still use a small script to debug this problem, if any. [2010-03-26 09:40:23] codeslinger at compsalot dot com did you even LOOOKK at the script that I provided? it is not that complicated. a few loops and some array allocations. previous attempts to reduce this to anything simpler have been unsuccessful. this is exactly the attitude that causes me to be overwrought. [2010-03-26 09:30:30] paj...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=51396 -- Edit this bug report at http://bugs.php.net/bug.php?id=51396&edit=1
Bug #51396 [Com]: Math is Unreliable
Edit report at http://bugs.php.net/bug.php?id=51396&edit=1 ID: 51396 Comment by: codeslinger at compsalot dot com Reported by: codeslinger at compsalot dot com Summary: Math is Unreliable Status: Feedback Type: Bug Package: Math related Operating System: any PHP Version: Irrelevant Assigned To: aharvey New Comment: Thank You for the response. This program executes thousands of identical loops it performs a number format conversion on each of those thousands of numbers in it's array. Out of all of those thousands of identical conversions about 4 of them will produce an invalid result. for this specific program, if I skip the array_merge (see $Nest) then the bug does not occur. Every time I make a change to the loops etc. the behavior changes, even to where the bug is not triggered. I have already simplified this program quite a bit and the result was that it now fails at a totally different array index then when I first observed the problem. The trigger is very finicky. XP is not a factor here, even though the original problem was found on XP, I am running this Snowflake program on Ubuntu Linux. converting a number to a string should never result in that string containing a non-numeric character. I can try to reduce this program further, but really and truly, it is hard to trigger this -- but once triggered it is totally consistent and repeatable. Previous Comments: [2010-03-26 10:11:25] paj...@php.net Btw, it could be due to bad initialized data as well (as you experience it on unix as well). Can you try to run your script under valgrind too? [2010-03-26 09:54:33] paj...@php.net It looks to me in a bug at the number formatting in the Windows API (not php dependent). Other users met this problem on old XP systems. You could reproduce it using number_format only. Or maybe only with a single printf function. Can you try using another windows box or using 5.3.2-vc9 builds? Btw, it is not about bad or good attitude but about having something we can actually use to help you. I can understand your worries after having spent hours to debug this problem, but we will still use a small script to debug this problem, if any. [2010-03-26 09:40:23] codeslinger at compsalot dot com did you even LOOOKK at the script that I provided? it is not that complicated. a few loops and some array allocations. previous attempts to reduce this to anything simpler have been unsuccessful. this is exactly the attitude that causes me to be overwrought. [2010-03-26 09:30:30] paj...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. [2010-03-26 08:51:34] codeslinger at compsalot dot com oops, fixed. various attempts to isolate this to a simple test case have not yet succeeded. This program is the closest I've come to a simple test case. after many hours of working on this, what I can tell you is that it requires lots of calculations and the use of arrays. - lots of memory allocations. yes, I confess to being overwrought. I've got 3 years of work, and the future of my software company at stake with this bug. and a lot of experience with bug reports that get ignored, including the original entry for this bug. 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=51396 -- Edit this bug report at http://bugs.php.net/bug.php?id=51396&edit=1
Bug #51274 [Com]: Integer overflow does not cast as float
Edit report at http://bugs.php.net/bug.php?id=51274&edit=1 ID: 51274 Comment by: cduncan at regatta dot com Reported by: cduncan at regatta dot com Summary: Integer overflow does not cast as float Status: Open Type: Bug Package: *General Issues Operating System: Linux PHP Version: 5.3.2 New Comment: Thanks, I was worried I was going mad for a moment there. Unfortunately I can't reproduce it on the machines I'm using at the moment. The machine I was experiencing it on was a production box, so finding time to reproduce it again could be tricky. Once I am able to do so, what extra information would assist in tracking this down? Thanks Previous Comments: [2010-03-26 09:24:56] ahar...@php.net Oh, I see what you're getting at now. Sorry about that. I still can't reproduce it, though. [2010-03-26 09:16:37] cduncan at regatta dot com Sorry but I'm misunderstanding what you are telling me. Why is the number reduced to the 32bit limit? (2147483647) Especially if you're saying the only way this could occur is with a 64bit OS? As I stated in my last edit, wouldn't a 64bit OS return: int(2147483648) [2010-03-26 07:50:20] ahar...@php.net Automatic comment from SVN on behalf of aharvey Revision: http://svn.php.net/viewvc/?view=revision&revision=296829 Log: Update to the integer type page to make it clearer how overflow works on 32- and 64-bit systems and what the critical thresholds are. Prompted by bug #51274, although not an actual fix for it. [2010-03-26 06:33:35] ahar...@php.net I can't really see any way this could occur other than your server having a 64-bit install of Linux on it. What distribution is the server running, what does "uname -m" output, and what does configure say the host and target system types are? (Side note: the manual could admittedly be a bit clearer on this; although the fact integer size differs on different platforms is mentioned, it might be useful if the Integer Overflow section actually reiterated it. I'll see about updating it.) [2010-03-26 06:21:39] ssufficool at gmail dot com 64 bit ubuntu 10.04 PHP 5.3 SVN: int(2147483647) int(2147483648) 32 bit machine and OS PHP 5.2.10: int(2147483647) float(2147483648) 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=51274 -- Edit this bug report at http://bugs.php.net/bug.php?id=51274&edit=1
Bug #51396 [Fbk]: Math is Unreliable
Edit report at http://bugs.php.net/bug.php?id=51396&edit=1 ID: 51396 Updated by: paj...@php.net Reported by: codeslinger at compsalot dot com Summary: Math is Unreliable Status: Feedback Type: Bug Package: Math related Operating System: any PHP Version: Irrelevant Assigned To: aharvey New Comment: Btw, it could be due to bad initialized data as well (as you experience it on unix as well). Can you try to run your script under valgrind too? Previous Comments: [2010-03-26 09:54:33] paj...@php.net It looks to me in a bug at the number formatting in the Windows API (not php dependent). Other users met this problem on old XP systems. You could reproduce it using number_format only. Or maybe only with a single printf function. Can you try using another windows box or using 5.3.2-vc9 builds? Btw, it is not about bad or good attitude but about having something we can actually use to help you. I can understand your worries after having spent hours to debug this problem, but we will still use a small script to debug this problem, if any. [2010-03-26 09:40:23] codeslinger at compsalot dot com did you even LOOOKK at the script that I provided? it is not that complicated. a few loops and some array allocations. previous attempts to reduce this to anything simpler have been unsuccessful. this is exactly the attitude that causes me to be overwrought. [2010-03-26 09:30:30] paj...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. [2010-03-26 08:51:34] codeslinger at compsalot dot com oops, fixed. various attempts to isolate this to a simple test case have not yet succeeded. This program is the closest I've come to a simple test case. after many hours of working on this, what I can tell you is that it requires lots of calculations and the use of arrays. - lots of memory allocations. yes, I confess to being overwrought. I've got 3 years of work, and the future of my software company at stake with this bug. and a lot of experience with bug reports that get ignored, including the original entry for this bug. [2010-03-26 04:31:56] ahar...@php.net It looks like the Web server you've posted the sample code to is interpreting the PHP files, so it's impossible to get the source. If you could upload the files with an extension that's not being handled by your PHP module, that would be handy. If there's any chance of a more minimal test case, that would also be rather useful. Finally, without wanting to sound overly snarky, that description was about 1200 words too long and infinitely too overwrought. Brevity is appreciated. 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=51396 -- Edit this bug report at http://bugs.php.net/bug.php?id=51396&edit=1
Bug #51396 [Fbk]: Math is Unreliable
Edit report at http://bugs.php.net/bug.php?id=51396&edit=1 ID: 51396 Updated by: paj...@php.net Reported by: codeslinger at compsalot dot com Summary: Math is Unreliable Status: Feedback Type: Bug Package: Math related Operating System: any PHP Version: Irrelevant Assigned To: aharvey New Comment: It looks to me in a bug at the number formatting in the Windows API (not php dependent). Other users met this problem on old XP systems. You could reproduce it using number_format only. Or maybe only with a single printf function. Can you try using another windows box or using 5.3.2-vc9 builds? Btw, it is not about bad or good attitude but about having something we can actually use to help you. I can understand your worries after having spent hours to debug this problem, but we will still use a small script to debug this problem, if any. Previous Comments: [2010-03-26 09:40:23] codeslinger at compsalot dot com did you even LOOOKK at the script that I provided? it is not that complicated. a few loops and some array allocations. previous attempts to reduce this to anything simpler have been unsuccessful. this is exactly the attitude that causes me to be overwrought. [2010-03-26 09:30:30] paj...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. [2010-03-26 08:51:34] codeslinger at compsalot dot com oops, fixed. various attempts to isolate this to a simple test case have not yet succeeded. This program is the closest I've come to a simple test case. after many hours of working on this, what I can tell you is that it requires lots of calculations and the use of arrays. - lots of memory allocations. yes, I confess to being overwrought. I've got 3 years of work, and the future of my software company at stake with this bug. and a lot of experience with bug reports that get ignored, including the original entry for this bug. [2010-03-26 04:31:56] ahar...@php.net It looks like the Web server you've posted the sample code to is interpreting the PHP files, so it's impossible to get the source. If you could upload the files with an extension that's not being handled by your PHP module, that would be handy. If there's any chance of a more minimal test case, that would also be rather useful. Finally, without wanting to sound overly snarky, that description was about 1200 words too long and infinitely too overwrought. Brevity is appreciated. [2010-03-26 00:36:48] codeslinger at compsalot dot com Description: is math accuracy important? no I am not talking about round-off errors. I am talking about the fact that most of the time, php correctly says that 2+2 = 4, but that sometimes it says that 2+2 = 0. What if your paycheck was being printed by a php program and you discovered that the math is inaccurate, would you care then? I ask these questions because I previously reported this bug because it occurred in a billing system that I wrote, but nobody considered that bug important enough to pursue it. Too complex, too hard to reproduce. whatever. Well, I have now encountered this bug again, with a much simpler program. and this program demonstrates that math in php is completely and totally untrustworthy. Does anyone care that fundamental functionality is unreliable? What good is a programming language that can't do math? php passes trivial math tests just fine; it's only when you use it in complex real-world ways that it starts failing. No these aren't binary base conversion errors, I'm guessing that this is memory corruption, so far I've only observed it with thousands of calculations. But the trivial programs I wrote in an attempt to reproduce the problem never succeeded in failing. I can only get it to fail when I'm doing real-world / complex stuff Characteristics: This is not a bug in the php program; under specific conditions - described below - the php program does run correctly. The main problem occurs when a float is converted to a string by a program that makes heavy use of arrays. It's not an out of memory condition, I have successfully stress tested a
Bug #51396 [Com]: Math is Unreliable
Edit report at http://bugs.php.net/bug.php?id=51396&edit=1 ID: 51396 Comment by: codeslinger at compsalot dot com Reported by: codeslinger at compsalot dot com Summary: Math is Unreliable Status: Feedback Type: Bug Package: Math related Operating System: any PHP Version: Irrelevant Assigned To: aharvey New Comment: did you even LOOOKK at the script that I provided? it is not that complicated. a few loops and some array allocations. previous attempts to reduce this to anything simpler have been unsuccessful. this is exactly the attitude that causes me to be overwrought. Previous Comments: [2010-03-26 09:30:30] paj...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. [2010-03-26 08:51:34] codeslinger at compsalot dot com oops, fixed. various attempts to isolate this to a simple test case have not yet succeeded. This program is the closest I've come to a simple test case. after many hours of working on this, what I can tell you is that it requires lots of calculations and the use of arrays. - lots of memory allocations. yes, I confess to being overwrought. I've got 3 years of work, and the future of my software company at stake with this bug. and a lot of experience with bug reports that get ignored, including the original entry for this bug. [2010-03-26 04:31:56] ahar...@php.net It looks like the Web server you've posted the sample code to is interpreting the PHP files, so it's impossible to get the source. If you could upload the files with an extension that's not being handled by your PHP module, that would be handy. If there's any chance of a more minimal test case, that would also be rather useful. Finally, without wanting to sound overly snarky, that description was about 1200 words too long and infinitely too overwrought. Brevity is appreciated. [2010-03-26 00:36:48] codeslinger at compsalot dot com Description: is math accuracy important? no I am not talking about round-off errors. I am talking about the fact that most of the time, php correctly says that 2+2 = 4, but that sometimes it says that 2+2 = 0. What if your paycheck was being printed by a php program and you discovered that the math is inaccurate, would you care then? I ask these questions because I previously reported this bug because it occurred in a billing system that I wrote, but nobody considered that bug important enough to pursue it. Too complex, too hard to reproduce. whatever. Well, I have now encountered this bug again, with a much simpler program. and this program demonstrates that math in php is completely and totally untrustworthy. Does anyone care that fundamental functionality is unreliable? What good is a programming language that can't do math? php passes trivial math tests just fine; it's only when you use it in complex real-world ways that it starts failing. No these aren't binary base conversion errors, I'm guessing that this is memory corruption, so far I've only observed it with thousands of calculations. But the trivial programs I wrote in an attempt to reproduce the problem never succeeded in failing. I can only get it to fail when I'm doing real-world / complex stuff Characteristics: This is not a bug in the php program; under specific conditions - described below - the php program does run correctly. The main problem occurs when a float is converted to a string by a program that makes heavy use of arrays. It's not an out of memory condition, I have successfully stress tested an array with one million items, but I am seeing it fail with only a thousand items. When it fails, the failure it totally repeatable, it always fails in exactly the same place in exactly the same way. And yet there is no discernible pattern to the failure, the trigger condition is unpredictable, it seems to depend on the actual data values. It is not a hardware issue, this has been observed on multiple machines. Also my main computer has had extensive memory diagnostic and hard disk tests run on it without finding any problems. It is not operating system specific, this failure has been observed on both Linux and Windows. It is not an FDIV b
Bug #51396 [Asn->Fbk]: Math is Unreliable
Edit report at http://bugs.php.net/bug.php?id=51396&edit=1 ID: 51396 Updated by: paj...@php.net Reported by: codeslinger at compsalot dot com Summary: Math is Unreliable -Status: Assigned +Status: Feedback Type: Bug Package: Math related Operating System: any PHP Version: Irrelevant Assigned To: aharvey New Comment: Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. Previous Comments: [2010-03-26 08:51:34] codeslinger at compsalot dot com oops, fixed. various attempts to isolate this to a simple test case have not yet succeeded. This program is the closest I've come to a simple test case. after many hours of working on this, what I can tell you is that it requires lots of calculations and the use of arrays. - lots of memory allocations. yes, I confess to being overwrought. I've got 3 years of work, and the future of my software company at stake with this bug. and a lot of experience with bug reports that get ignored, including the original entry for this bug. [2010-03-26 04:31:56] ahar...@php.net It looks like the Web server you've posted the sample code to is interpreting the PHP files, so it's impossible to get the source. If you could upload the files with an extension that's not being handled by your PHP module, that would be handy. If there's any chance of a more minimal test case, that would also be rather useful. Finally, without wanting to sound overly snarky, that description was about 1200 words too long and infinitely too overwrought. Brevity is appreciated. [2010-03-26 00:36:48] codeslinger at compsalot dot com Description: is math accuracy important? no I am not talking about round-off errors. I am talking about the fact that most of the time, php correctly says that 2+2 = 4, but that sometimes it says that 2+2 = 0. What if your paycheck was being printed by a php program and you discovered that the math is inaccurate, would you care then? I ask these questions because I previously reported this bug because it occurred in a billing system that I wrote, but nobody considered that bug important enough to pursue it. Too complex, too hard to reproduce. whatever. Well, I have now encountered this bug again, with a much simpler program. and this program demonstrates that math in php is completely and totally untrustworthy. Does anyone care that fundamental functionality is unreliable? What good is a programming language that can't do math? php passes trivial math tests just fine; it's only when you use it in complex real-world ways that it starts failing. No these aren't binary base conversion errors, I'm guessing that this is memory corruption, so far I've only observed it with thousands of calculations. But the trivial programs I wrote in an attempt to reproduce the problem never succeeded in failing. I can only get it to fail when I'm doing real-world / complex stuff Characteristics: This is not a bug in the php program; under specific conditions - described below - the php program does run correctly. The main problem occurs when a float is converted to a string by a program that makes heavy use of arrays. It's not an out of memory condition, I have successfully stress tested an array with one million items, but I am seeing it fail with only a thousand items. When it fails, the failure it totally repeatable, it always fails in exactly the same place in exactly the same way. And yet there is no discernible pattern to the failure, the trigger condition is unpredictable, it seems to depend on the actual data values. It is not a hardware issue, this has been observed on multiple machines. Also my main computer has had extensive memory diagnostic and hard disk tests run on it without finding any problems. It is not operating system specific, this failure has been observed on both Linux and Windows. It is not an FDIV bug. This Pentium chip is verified to not have that bug. Different versions of php are triggered by different sequences of events. But all of them fail in some way. I have two programs, both of which fail, but the specifics of the failure vary depending on which version of php they are being run on. One program is a billing system, it is large and complex an
Bug #51274 [Fbk->Opn]: Integer overflow does not cast as float
Edit report at http://bugs.php.net/bug.php?id=51274&edit=1 ID: 51274 Updated by: ahar...@php.net Reported by: cduncan at regatta dot com Summary: Integer overflow does not cast as float -Status: Feedback +Status: Open Type: Bug Package: *General Issues Operating System: Linux PHP Version: 5.3.2 New Comment: Oh, I see what you're getting at now. Sorry about that. I still can't reproduce it, though. Previous Comments: [2010-03-26 09:16:37] cduncan at regatta dot com Sorry but I'm misunderstanding what you are telling me. Why is the number reduced to the 32bit limit? (2147483647) Especially if you're saying the only way this could occur is with a 64bit OS? As I stated in my last edit, wouldn't a 64bit OS return: int(2147483648) [2010-03-26 07:50:20] ahar...@php.net Automatic comment from SVN on behalf of aharvey Revision: http://svn.php.net/viewvc/?view=revision&revision=296829 Log: Update to the integer type page to make it clearer how overflow works on 32- and 64-bit systems and what the critical thresholds are. Prompted by bug #51274, although not an actual fix for it. [2010-03-26 06:33:35] ahar...@php.net I can't really see any way this could occur other than your server having a 64-bit install of Linux on it. What distribution is the server running, what does "uname -m" output, and what does configure say the host and target system types are? (Side note: the manual could admittedly be a bit clearer on this; although the fact integer size differs on different platforms is mentioned, it might be useful if the Integer Overflow section actually reiterated it. I'll see about updating it.) [2010-03-26 06:21:39] ssufficool at gmail dot com 64 bit ubuntu 10.04 PHP 5.3 SVN: int(2147483647) int(2147483648) 32 bit machine and OS PHP 5.2.10: int(2147483647) float(2147483648) [2010-03-11 19:05:31] cduncan at regatta dot com 64bit machine, 32bit OS. Also, wouldn't we expect a 64bit to return: int(2147483647) int(2147483648) 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=51274 -- Edit this bug report at http://bugs.php.net/bug.php?id=51274&edit=1
Bug #51274 [Com]: Integer overflow does not cast as float
Edit report at http://bugs.php.net/bug.php?id=51274&edit=1 ID: 51274 Comment by: cduncan at regatta dot com Reported by: cduncan at regatta dot com Summary: Integer overflow does not cast as float Status: Feedback Type: Bug Package: *General Issues Operating System: Linux PHP Version: 5.3.2 New Comment: Sorry but I'm misunderstanding what you are telling me. Why is the number reduced to the 32bit limit? (2147483647) Especially if you're saying the only way this could occur is with a 64bit OS? As I stated in my last edit, wouldn't a 64bit OS return: int(2147483648) Previous Comments: [2010-03-26 07:50:20] ahar...@php.net Automatic comment from SVN on behalf of aharvey Revision: http://svn.php.net/viewvc/?view=revision&revision=296829 Log: Update to the integer type page to make it clearer how overflow works on 32- and 64-bit systems and what the critical thresholds are. Prompted by bug #51274, although not an actual fix for it. [2010-03-26 06:33:35] ahar...@php.net I can't really see any way this could occur other than your server having a 64-bit install of Linux on it. What distribution is the server running, what does "uname -m" output, and what does configure say the host and target system types are? (Side note: the manual could admittedly be a bit clearer on this; although the fact integer size differs on different platforms is mentioned, it might be useful if the Integer Overflow section actually reiterated it. I'll see about updating it.) [2010-03-26 06:21:39] ssufficool at gmail dot com 64 bit ubuntu 10.04 PHP 5.3 SVN: int(2147483647) int(2147483648) 32 bit machine and OS PHP 5.2.10: int(2147483647) float(2147483648) [2010-03-11 19:05:31] cduncan at regatta dot com 64bit machine, 32bit OS. Also, wouldn't we expect a 64bit to return: int(2147483647) int(2147483648) [2010-03-11 17:58:30] j...@php.net Could it possibly be that you're running this on 64bit machine? :) The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=51274 -- Edit this bug report at http://bugs.php.net/bug.php?id=51274&edit=1
Bug #51396 [Fbk->Asn]: Math is Unreliable
Edit report at http://bugs.php.net/bug.php?id=51396&edit=1 ID: 51396 Updated by: ahar...@php.net Reported by: codeslinger at compsalot dot com Summary: Math is Unreliable -Status: Feedback +Status: Assigned Type: Bug Package: Math related Operating System: any PHP Version: Irrelevant -Assigned To: +Assigned To: aharvey Previous Comments: [2010-03-26 08:51:34] codeslinger at compsalot dot com oops, fixed. various attempts to isolate this to a simple test case have not yet succeeded. This program is the closest I've come to a simple test case. after many hours of working on this, what I can tell you is that it requires lots of calculations and the use of arrays. - lots of memory allocations. yes, I confess to being overwrought. I've got 3 years of work, and the future of my software company at stake with this bug. and a lot of experience with bug reports that get ignored, including the original entry for this bug. [2010-03-26 04:31:56] ahar...@php.net It looks like the Web server you've posted the sample code to is interpreting the PHP files, so it's impossible to get the source. If you could upload the files with an extension that's not being handled by your PHP module, that would be handy. If there's any chance of a more minimal test case, that would also be rather useful. Finally, without wanting to sound overly snarky, that description was about 1200 words too long and infinitely too overwrought. Brevity is appreciated. [2010-03-26 00:36:48] codeslinger at compsalot dot com Description: is math accuracy important? no I am not talking about round-off errors. I am talking about the fact that most of the time, php correctly says that 2+2 = 4, but that sometimes it says that 2+2 = 0. What if your paycheck was being printed by a php program and you discovered that the math is inaccurate, would you care then? I ask these questions because I previously reported this bug because it occurred in a billing system that I wrote, but nobody considered that bug important enough to pursue it. Too complex, too hard to reproduce. whatever. Well, I have now encountered this bug again, with a much simpler program. and this program demonstrates that math in php is completely and totally untrustworthy. Does anyone care that fundamental functionality is unreliable? What good is a programming language that can't do math? php passes trivial math tests just fine; it's only when you use it in complex real-world ways that it starts failing. No these aren't binary base conversion errors, I'm guessing that this is memory corruption, so far I've only observed it with thousands of calculations. But the trivial programs I wrote in an attempt to reproduce the problem never succeeded in failing. I can only get it to fail when I'm doing real-world / complex stuff Characteristics: This is not a bug in the php program; under specific conditions - described below - the php program does run correctly. The main problem occurs when a float is converted to a string by a program that makes heavy use of arrays. It's not an out of memory condition, I have successfully stress tested an array with one million items, but I am seeing it fail with only a thousand items. When it fails, the failure it totally repeatable, it always fails in exactly the same place in exactly the same way. And yet there is no discernible pattern to the failure, the trigger condition is unpredictable, it seems to depend on the actual data values. It is not a hardware issue, this has been observed on multiple machines. Also my main computer has had extensive memory diagnostic and hard disk tests run on it without finding any problems. It is not operating system specific, this failure has been observed on both Linux and Windows. It is not an FDIV bug. This Pentium chip is verified to not have that bug. Different versions of php are triggered by different sequences of events. But all of them fail in some way. I have two programs, both of which fail, but the specifics of the failure vary depending on which version of php they are being run on. One program is a billing system, it is large and complex and proprietary and the data is confidential and it uses several external libraries. The other program generates a Koch Snowflake (a type of graphics fractal). It is small and has no required dependencies and I am happy to make it's source code available. Both fail with the same or similar math errors but the behavior is not identical. The billing system *appears* to run fine on Windows PHP 5.2.5 (standard build as provided by php.net). The billing system is in dail
Bug #51396 [Com]: Math is Unreliable
Edit report at http://bugs.php.net/bug.php?id=51396&edit=1 ID: 51396 Comment by: codeslinger at compsalot dot com Reported by: codeslinger at compsalot dot com Summary: Math is Unreliable Status: Feedback Type: Bug Package: Math related Operating System: any PHP Version: Irrelevant New Comment: oops, fixed. various attempts to isolate this to a simple test case have not yet succeeded. This program is the closest I've come to a simple test case. after many hours of working on this, what I can tell you is that it requires lots of calculations and the use of arrays. - lots of memory allocations. yes, I confess to being overwrought. I've got 3 years of work, and the future of my software company at stake with this bug. and a lot of experience with bug reports that get ignored, including the original entry for this bug. Previous Comments: [2010-03-26 04:31:56] ahar...@php.net It looks like the Web server you've posted the sample code to is interpreting the PHP files, so it's impossible to get the source. If you could upload the files with an extension that's not being handled by your PHP module, that would be handy. If there's any chance of a more minimal test case, that would also be rather useful. Finally, without wanting to sound overly snarky, that description was about 1200 words too long and infinitely too overwrought. Brevity is appreciated. [2010-03-26 00:36:48] codeslinger at compsalot dot com Description: is math accuracy important? no I am not talking about round-off errors. I am talking about the fact that most of the time, php correctly says that 2+2 = 4, but that sometimes it says that 2+2 = 0. What if your paycheck was being printed by a php program and you discovered that the math is inaccurate, would you care then? I ask these questions because I previously reported this bug because it occurred in a billing system that I wrote, but nobody considered that bug important enough to pursue it. Too complex, too hard to reproduce. whatever. Well, I have now encountered this bug again, with a much simpler program. and this program demonstrates that math in php is completely and totally untrustworthy. Does anyone care that fundamental functionality is unreliable? What good is a programming language that can't do math? php passes trivial math tests just fine; it's only when you use it in complex real-world ways that it starts failing. No these aren't binary base conversion errors, I'm guessing that this is memory corruption, so far I've only observed it with thousands of calculations. But the trivial programs I wrote in an attempt to reproduce the problem never succeeded in failing. I can only get it to fail when I'm doing real-world / complex stuff Characteristics: This is not a bug in the php program; under specific conditions - described below - the php program does run correctly. The main problem occurs when a float is converted to a string by a program that makes heavy use of arrays. It's not an out of memory condition, I have successfully stress tested an array with one million items, but I am seeing it fail with only a thousand items. When it fails, the failure it totally repeatable, it always fails in exactly the same place in exactly the same way. And yet there is no discernible pattern to the failure, the trigger condition is unpredictable, it seems to depend on the actual data values. It is not a hardware issue, this has been observed on multiple machines. Also my main computer has had extensive memory diagnostic and hard disk tests run on it without finding any problems. It is not operating system specific, this failure has been observed on both Linux and Windows. It is not an FDIV bug. This Pentium chip is verified to not have that bug. Different versions of php are triggered by different sequences of events. But all of them fail in some way. I have two programs, both of which fail, but the specifics of the failure vary depending on which version of php they are being run on. One program is a billing system, it is large and complex and proprietary and the data is confidential and it uses several external libraries. The other program generates a Koch Snowflake (a type of graphics fractal). It is small and has no required dependencies and I am happy to make it's source code available. Both fail with the same or similar math errors but the behavior is not identical. The billing system *appears* to run fine on Windows PHP 5.2.5 (standard build as provided by php.net). The billing system is in daily use and no errors have been reported... so far... At one point it was decided to upgrade to PHP 5.2.9 (standard build from php.net). The billing system passed the prel
Req #51390 [Bgs]: need PHP APC binaries for 5.2.13
Edit report at http://bugs.php.net/bug.php?id=51390&edit=1 ID: 51390 User updated by: t_wiedmann at t-online dot de Reported by: t_wiedmann at t-online dot de Summary: need PHP APC binaries for 5.2.13 Status: Bogus Type: Feature/Change Request Package: *Extensibility Functions Operating System: Windows XP PHP Version: 5.2.13 Assigned To: pajoye New Comment: some more informations: I move my projekt to a new server (both Windows XP Server 2003) old: * apache_2.2.4-win32-x86-no_ssl.msi * php-5.2.3-Win32 * php_apc.dll (Version 5.2.1.1) * Zend Framework 1.5.2 Work well! same code on the new server failed * Apache apache_2.2.14-win32-x86-no_ssl.msi * php-5.2.13-Win32 * php_apc.dll (Version 5.2.9) * Zend Framework 1.5.2 Hope this helps Thanks! Thomas Previous Comments: [2010-03-26 08:17:30] t_wiedmann at t-online dot de but I get problems. I work with * Apache apache_2.2.14-win32-x86-no_ssl.msi * php-5.2.13-Win32 * Zend Framework anything work well, but if I enable this APC dll (5.2.9) Apache STOPs and I get this in error.log: [Fri Mar 26 08:05:14 2010] [apc-error] Cannot redeclare class zend_registry Looks like a problem with Zend Framework, but without APC anything work well. php.ini: [APC] apc.enabled=1 apc.shm_segments=1 apc.optimization=0 apc.shm_size=128 apc.ttl=7200 apc.user_ttl=7200 apc.num_files_hint=1024 apc.enable_cli=0 apc.rfc1867=1 apc.mmap_file_mask="c:/Programme/SVEN/apc-temp/apc.XX" Bug or feature ? Thanks for any help! Thomas [2010-03-25 15:28:42] paj...@php.net There is no bug (and certainly not in php :). And yes, the 5.2 bins work for anything after 5.2.6. [2010-03-25 15:25:43] johan...@php.net the 5.2.9 build should in theory work, pierre can you update anyways? [2010-03-25 15:09:28] t_wiedmann at t-online dot de Description: Hi, I need php_apc.dll binaries for PHP 5.2.13. On http://downloads.php.net/pierre/ the lastest version is 5.2.9. Many thanks! Thomas Expected result: php_apc.dll binaries for PHP 5.2.13 -- Edit this bug report at http://bugs.php.net/bug.php?id=51390&edit=1
[PHP-BUG] Bug #51397 [NEW]: Math calculation bug
From:
Operating system: FREEBSD & LINUX
PHP version: 5.2.13
Package: Scripting Engine problem
Bug Type: Bug
Bug description:Math calculation bug
Description:
I have used the code from the test script on my development machine
(Windows Professional 7 32bit) with php 5.2.12 and is working correctly but
when I have deployed on my production machine that is FreeBSD 6.3 32bit
with the same php version 5.2.12 is giving wrong results (-2147483593). I
also run this on other production machine that is RedHat 5 32bit with php
5.2.6 and is also giving wrong results (-2147483593).
I can not test with php 5.2.13 on production machines (virtual hosting).
On windows is giving the correctly result (754303898) with PHP 5.2.12 and
PHP 5.3.1. I am running in 32bit platform on all machines.
---
PHP_INT_SIZE: 4
System => FreeBSD somehost.com 6.3-RELEASE FreeBSD 6.3-RELEASE #6: Wed Oc
t 21 09:32:42 MDT 2009 r...@fc:/usr/src/sys/i386/compile/VKERN i386
Build Date => Mar 3 2010 12:51:00
Configure Command => './configure' '--with-layout=GNU'
'--with-config-file-sca
n-dir=/usr/local/etc/php' '--disable-all' '--enable-libxml'
'--with-libxml-dir=/
usr/local' '--enable-reflection' '--program-prefix=' '--enable-fastcgi'
'--with-
apxs2=/usr/local/sbin/apxs' '--with-regex=php' '--with-zend-vm=CALL'
'--prefix=/
usr/local' '--mandir=/usr/local/man' '--infodir=/usr/local/info/'
'--build=i386-
portbld-freebsd6.3'
Server API => Command Line Interface
Virtual Directory Support => disabled
Configuration File (php.ini) Path => /usr/local/etc
Loaded Configuration File => /usr/local/etc/php.ini
Scan this dir for additional .ini files => /usr/local/etc/php
additional .ini files parsed => /usr/local/etc/php/extensions.ini
PHP API => 20041225
PHP Extension => 20060613
Zend Extension => 220060519
Debug Build => no
Test script:
---
function myhash($key) {
$h = 5381;
$l = strlen($key);
for($i = 0; $i < $l; ++$i) {
$h = (($h << 5) + $h) ^ ord($key[$i]);
}
return $h;
}
$h = myhash('CL6.1.7');
if ($h != 754303898)
echo "bug\n";
echo $h . "\n";
Expected result:
754303898
Actual result:
--
bug
-2147483593
--
Edit bug report at http://bugs.php.net/bug.php?id=51397&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51397&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51397&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51397&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51397&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51397&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51397&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51397&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51397&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51397&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51397&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51397&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51397&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51397&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51397&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51397&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51397&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51397&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51397&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51397&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51397&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51397&r=mysqlcfg
Req #51390 [Bgs]: need PHP APC binaries for 5.2.13
Edit report at http://bugs.php.net/bug.php?id=51390&edit=1 ID: 51390 User updated by: t_wiedmann at t-online dot de Reported by: t_wiedmann at t-online dot de Summary: need PHP APC binaries for 5.2.13 Status: Bogus Type: Feature/Change Request Package: *Extensibility Functions Operating System: Windows XP PHP Version: 5.2.13 Assigned To: pajoye New Comment: but I get problems. I work with * Apache apache_2.2.14-win32-x86-no_ssl.msi * php-5.2.13-Win32 * Zend Framework anything work well, but if I enable this APC dll (5.2.9) Apache STOPs and I get this in error.log: [Fri Mar 26 08:05:14 2010] [apc-error] Cannot redeclare class zend_registry Looks like a problem with Zend Framework, but without APC anything work well. php.ini: [APC] apc.enabled=1 apc.shm_segments=1 apc.optimization=0 apc.shm_size=128 apc.ttl=7200 apc.user_ttl=7200 apc.num_files_hint=1024 apc.enable_cli=0 apc.rfc1867=1 apc.mmap_file_mask="c:/Programme/SVEN/apc-temp/apc.XX" Bug or feature ? Thanks for any help! Thomas Previous Comments: [2010-03-25 15:28:42] paj...@php.net There is no bug (and certainly not in php :). And yes, the 5.2 bins work for anything after 5.2.6. [2010-03-25 15:25:43] johan...@php.net the 5.2.9 build should in theory work, pierre can you update anyways? [2010-03-25 15:09:28] t_wiedmann at t-online dot de Description: Hi, I need php_apc.dll binaries for PHP 5.2.13. On http://downloads.php.net/pierre/ the lastest version is 5.2.9. Many thanks! Thomas Expected result: php_apc.dll binaries for PHP 5.2.13 -- Edit this bug report at http://bugs.php.net/bug.php?id=51390&edit=1
