#49448 [NEW]: Sunset/Sunrise Zenith default values wrong
From: the_good_technician at yahoo dot com
Operating system: Any
PHP version: 5.3.0
PHP Bug Type: Unknown/Other Function
Bug description: Sunset/Sunrise Zenith default values wrong
Description:
This is an easy problem to fix. I'm surprised nobody has reported it so
far.
The default configuration value for "date.sunrise_zenith" and
"date.sunset_zenith" is "90.58". But this value is incorrect!
The correct value for a sunrise/sunset zenith angle is 90 + (50/60)
WHICH EQUALS
90.833
NOT
90.583
Reproduce code:
---
echo ini_get("date.sunrise_zenith") . "\n";
echo ini_get("date.sunset_zenith") . "\n";
Expected result:
90.833
90.833
Actual result:
--
90.583
90.583
--
Edit bug report at http://bugs.php.net/?id=49448&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49448&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49448&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49448&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49448&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49448&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49448&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49448&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49448&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49448&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49448&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49448&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49448&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49448&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49448&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49448&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49448&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49448&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49448&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49448&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49448&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49448&r=mysqlcfg
#49448 [Opn->Asn]: Sunset/Sunrise Zenith default values wrong
ID: 49448
Updated by: der...@php.net
Reported By: the_good_technician at yahoo dot com
-Status: Open
+Status: Assigned
Bug Type: Unknown/Other Function
Operating System: Any
PHP Version: 5.3.0
-Assigned To:
+Assigned To: derick
Previous Comments:
[2009-09-03 07:58:41] the_good_technician at yahoo dot com
Description:
This is an easy problem to fix. I'm surprised nobody has reported it
so far.
The default configuration value for "date.sunrise_zenith" and
"date.sunset_zenith" is "90.58". But this value is incorrect!
The correct value for a sunrise/sunset zenith angle is 90 + (50/60)
WHICH EQUALS
90.833
NOT
90.583
Reproduce code:
---
echo ini_get("date.sunrise_zenith") . "\n";
echo ini_get("date.sunset_zenith") . "\n";
Expected result:
90.833
90.833
Actual result:
--
90.583
90.583
--
Edit this bug report at http://bugs.php.net/?id=49448&edit=1
#49344 [Com]: pdo_mssql fails to connect,throws PDOException SQLSTATE[] (null) (severity 0)
ID: 49344
Comment by: rockyjl at gmail dot com
Reported By: rockyjl at gmai dot com
Status: Open
Bug Type: PDO related
Operating System: win2003 X64
PHP Version: 5.2.11RC1
New Comment:
web server is Apache 2.2.11 and Apache 2.2.13 x86 no_ssl
Previous Comments:
[2009-08-27 08:27:57] rockyjl at gmail dot com
php-5.2.11RC2-dev-win32-VC6-x86 has the Bug too!
Anyone can help me ? Please !
[2009-08-25 02:08:48] rockyjl at gmail dot com
I upgrade to php-5.2.11RC2-dev-win32-VC6-x86 now !
Testing the bug
[2009-08-24 10:06:51] rockyjl at gmai dot com
Description:
in Bug #48539
[28 Jun 2:10am UTC] fel...@php.net
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Fixed in 5.2 and HEAD.
5.3 in soon.
Thanks.
But the bug still often happen in PHP 5.2.11RC1 ...
Could you tell me which version(win32 zip) can work in the environment
of win2003 x64 + apache 2.2.11 + sql2005,and the pdo_mssql can connect
DB successfully ??
Reproduce code:
---
function db()
{
try
{
$db = new PDO(DB_DSN, DB_User, DB_Password);
return $db;
}
catch (PDOException $e)
{
die($e->getMessage());
}
}
Expected result:
connect DB Successful
Actual result:
--
SQLSTATE[] (null) (severity 0)
--
Edit this bug report at http://bugs.php.net/?id=49344&edit=1
#46539 [Opn->Bgs]: SoapClient uses HTTP/1.1 options over HTTP/1.0
ID: 46539 Updated by: sjo...@php.net Reported By: marques at displague dot com -Status: Open +Status: Bogus Bug Type: SOAP related Operating System: * PHP Version: 5.2.6 New Comment: Thank you for your bug report. While the usage of digest authentication with HTTP/1.0 may very well be a bug, we have no interest in fixing it in the 5.2 branch. Fixing it would be much work and users can use PHP 5.3 instead if they experience this bug. The Host header is allowed in HTTP/1.0. The difference with HTTP/1.1 is that it is _required_ in HTTP/1.1. Previous Comments: [2009-07-27 12:24:25] alayn at irontec dot com Confirmed. My problem disappeared with 5.3 Sorry again [2009-07-23 13:52:08] alayn at irontec dot com Up... It seems like my bug is more related to: http://bugs.php.net/bug.php?id=47021 I will try 5.3 as soon as i have time for it. Sorry :S [2009-07-23 11:42:50] alayn at irontec dot com Using HTTP/1.0 for the WSDL request against a JAX-WS service, makes PHP freeze until timeout arrives, eventhought it gets the complete response. Not sure if this is a JAX-WS or PHP related issue, but I think it should be possible to resolve it by performing an HTTP/1.1 request... A related bug is reported at Java's bug system too: https://jax-ws.dev.java.net/issues/show_bug.cgi?id=257 It seems they resolved the issue with wget, but I still having the same problem from PHP 5.2.9 :( [2008-11-10 22:01:49] marques at displague dot com Description: When setting the SoapClient option 'authorization' to SOAP_AUTHENTICATION_DIGEST, the SoapClient connection should attempt to GET with HTTP/1.1 rather than HTTP/1.0 since digest is HTTP/1.1 specific. I also noticed that the HTTP/1.0 WSDL request issued by the SoapClient class used "Host:" lines. I may be wrong, but I thought that implied HTTP/1.1. (I don't see it in the HTTP/1.0 RFC). -- Edit this bug report at http://bugs.php.net/?id=46539&edit=1
#49444 [Opn->Fbk]: $_GET variable
ID: 49444
Updated by: sjo...@php.net
Reported By: hafizanil at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: Scripting Engine problem
Operating System: Windows Xp
PHP Version: 5.3.0
New Comment:
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
Thank you for your interest in PHP.
Previous Comments:
[2009-09-03 01:16:15] hafizanil at gmail dot com
Javascript (Page 1)
function sentMail() {
var url;
var to;
url = 'ml_compose_com.php?';
document.form.title.value='admin (sit: mr chang n mr sairi n mr
pzan)
,';
title = escape(document.form.title.value);
if(title){ url= url+'&title='+ title; }
location = url+"&sent_mail=1";
}
Page 2 (ml_compose_com.php)
".print_r($_GET)."";
var_dump($_GET);
?>
[2009-09-02 19:11:27] j...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
[2009-09-02 16:07:28] hafizanil at gmail dot com
Description:
Want to sent variable via javascript via $_GET method and the output
going hirewire.The varible sent also been escape
first(javascript).Tested using 5.29 and 5.3
Browser 1.Internet Explorer 7
2 Firefox 3.52
3. Opera 10
Reproduce code:
---
This is tested 5.29
[code]
$_GET['to']="admin (sit: mr chang n mr sairi n mr pzan)
,";
echo strlen($_GET['to'])
// out put 63
var_dump($_GET);
// output only showing admin (sit: mr chang n mr sairi n mr pzan)
[/code]
This is tested 5.30
[code]
$_GET['to']="admin (sit: mr chang n mr sairi n mr pzan)
,";
echo strlen($_GET['to'])
// out put 63
var_dump($_GET);
//output :Page going crazy.show all the php source
[/code]
Expected result:
var_dump or print_r $_GET array should understand the variable which
might contain "<>";
Actual result:
--
On 5.3 It show all the source php .
--
Edit this bug report at http://bugs.php.net/?id=49444&edit=1
#48746 [Com]: Unable to browse directories within Junction Points
ID: 48746
Comment by: phpstuff at cresstone dot com
Reported By: ddkees at illinois dot edu
Status: Feedback
Bug Type: Directory function related
Operating System: win32 only - Windows Server 2003
PHP Version: 5.3.0
Assigned To: pajoye
New Comment:
I'm getting good test behavior from the that snapshot. More tellingly,
the original script I've been trying to run is now working correctly.
Thanks.
Previous Comments:
[2009-09-02 23:26:04] paj...@php.net
I can't reproduce the problem with is_dir or is_file behave correctly,
however I think I found the problem and commited a fix.
I can reproduce the scandir one, same fix. I manually launched a build,
you can get the vc9-x86 here: http://is.gd/2OtDf (other snaps should be
online within 15mins).
[2009-09-02 22:59:59] s...@php.net
Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revision&revision=287975
Log: - #48746, len includes null already
[2009-09-02 21:29:08] phpstuff at cresstone dot com
Using Windows 7 x64. It seems all files in my mounted volumes are being
treated as directories. (is_dir returns true, is_file returns false.)
Directory operations pointed at files seem to point back to the root of
the volume.
The following script:
echo "dumping: scandir('mounted_volume')\n";
var_dump(scandir('mounted_volume'));
echo "dumping: scandir('mounted_volume\\file1')\n";
var_dump(scandir('mounted_volume\file1'));
gives this output:
dumping: scandir('mounted_volume')
array(4) {
[0]=>
string(12) "$RECYCLE.BIN"
[1]=>
string(4) "dir1"
[2]=>
string(4) "dir2"
[3]=>
string(5) "file1"
}
dumping: scandir('mounted_volume\file1')
array(4) {
[0]=>
string(12) "$RECYCLE.BIN"
[1]=>
string(4) "dir1"
[2]=>
string(4) "dir2"
[3]=>
string(5) "file1"
}
Nesting does not seem to matter, eg:
scandir('mounted_volume\dir1\file_in_dir1'); gives the same output
Something else that's interesting... When I create the junction from a
drive letter, eg: "mklink mounted_volume y:" everything works perfectly,
files are files and dirs are dirs. It's only when I use the volume name
in the creation ("mklink /J mounted_volume
\\?\Volume{feeac7c1-2ad0-11de-89bb-001fd0ae05ac}\") that I get this
strange behavior. Bizarre, but I swear I'm not making this up :)
[2009-09-02 10:35:32] paj...@php.net
Can't reproduce here. Which OS are you using for this test?
[2009-09-02 10:30:20] paj...@php.net
Oh my, I'm about to loose my last hair :)
But we are getting close now... back to code
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/48746
--
Edit this bug report at http://bugs.php.net/?id=48746&edit=1
#49449 [NEW]: Segmentation fault with ArrayObject::offsetSet()
From: arnold at adaniels dot nl
Operating system: Linux / Ubuntu 9.04
PHP version: 5.3.0
PHP Bug Type: Reproducible crash
Bug description: Segmentation fault with ArrayObject::offsetSet()
Description:
Using array access on $this in ArrayObject::offsetSet() causes a
segmentation fault.
(Calling parent::offsetSet() instead, works fine)
Reproduce code:
---
class AOTest extends ArrayObject
{
public function offsetSet($index, $newval)
{
$this[$index] = (int)$newval;
}
}
$a = new AOTest();
$a['test'] = "10 doves";
var_dump((array)$a);
Expected result:
array(1) {
["test"]=>
int(10)
}
Actual result:
--
Segmentation fault
--
Edit bug report at http://bugs.php.net/?id=49449&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49449&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49449&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49449&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49449&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49449&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49449&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49449&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49449&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49449&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49449&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49449&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49449&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49449&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49449&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49449&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49449&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49449&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49449&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49449&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49449&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49449&r=mysqlcfg
#49450 [NEW]: Segmentation fault with ArrayObject::offsetSet()
From: arnold at adaniels dot nl
Operating system: Linux / Ubuntu 9.04
PHP version: 5.3.0
PHP Bug Type: Reproducible crash
Bug description: Segmentation fault with ArrayObject::offsetSet()
Description:
Using array access on $this in ArrayObject::offsetSet() causes a
segmentation fault.
(Calling parent::offsetSet() instead, works fine)
Reproduce code:
---
class AOTest extends ArrayObject
{
public function offsetSet($index, $newval)
{
$this[$index] = (int)$newval;
}
}
$a = new AOTest();
$a['test'] = "10 doves";
var_dump((array)$a);
Expected result:
array(1) {
["test"]=>
int(10)
}
Actual result:
--
Segmentation fault
--
Edit bug report at http://bugs.php.net/?id=49450&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49450&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49450&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49450&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49450&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49450&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49450&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49450&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49450&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49450&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49450&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49450&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49450&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49450&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49450&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49450&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49450&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49450&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49450&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49450&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49450&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49450&r=mysqlcfg
#49451 [NEW]: Segmentation fault with ArrayObject::offsetSet()
From: info at adaniels dot nl
Operating system: Linux / Ubuntu 9.04
PHP version: 5.3.0
PHP Bug Type: Reproducible crash
Bug description: Segmentation fault with ArrayObject::offsetSet()
Description:
Using array access on $this in ArrayObject::offsetSet() causes a
segmentation fault.
(Calling parent::offsetSet() instead, works fine)
Reproduce code:
---
class AOTest extends ArrayObject
{
public function offsetSet($index, $newval)
{
$this[$index] = (int)$newval;
}
}
$a = new AOTest();
$a['test'] = "10 doves";
var_dump((array)$a);
Expected result:
array(1) {
["test"]=>
int(10)
}
Actual result:
--
Segmentation fault
--
Edit bug report at http://bugs.php.net/?id=49451&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49451&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49451&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49451&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49451&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49451&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49451&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49451&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49451&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49451&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49451&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49451&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49451&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49451&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49451&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49451&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49451&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49451&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49451&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49451&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49451&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49451&r=mysqlcfg
#49452 [NEW]: Segmentation fault with ArrayObject::offsetSet()
From: info at adaniels dot nl
Operating system: Linux / Ubuntu 9.04
PHP version: 5.3.0
PHP Bug Type: Reproducible crash
Bug description: Segmentation fault with ArrayObject::offsetSet()
Description:
Using array access on $this in ArrayObject::offsetSet() causes a
segmentation fault.
(Calling parent::offsetSet() instead, works fine)
Reproduce code:
---
class AOTest extends ArrayObject
{
public function offsetSet($index, $newval)
{
$this[$index] = (int)$newval;
}
}
$a = new AOTest();
$a['test'] = "10 doves";
var_dump((array)$a);
Expected result:
array(1) {
["test"]=>
int(10)
}
Actual result:
--
Segmentation fault
--
Edit bug report at http://bugs.php.net/?id=49452&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49452&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49452&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49452&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49452&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49452&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49452&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49452&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49452&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49452&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49452&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49452&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49452&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49452&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49452&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49452&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49452&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49452&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49452&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49452&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49452&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49452&r=mysqlcfg
#49450 [Opn->Bgs]: Segmentation fault with ArrayObject::offsetSet()
ID: 49450
Updated by: der...@php.net
Reported By: arnold at adaniels dot nl
-Status: Open
+Status: Bogus
Bug Type: Reproducible crash
Operating System: Linux / Ubuntu 9.04
PHP Version: 5.3.0
New Comment:
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
49449
Previous Comments:
[2009-09-03 10:33:46] arnold at adaniels dot nl
Description:
Using array access on $this in ArrayObject::offsetSet() causes a
segmentation fault.
(Calling parent::offsetSet() instead, works fine)
Reproduce code:
---
class AOTest extends ArrayObject
{
public function offsetSet($index, $newval)
{
$this[$index] = (int)$newval;
}
}
$a = new AOTest();
$a['test'] = "10 doves";
var_dump((array)$a);
Expected result:
array(1) {
["test"]=>
int(10)
}
Actual result:
--
Segmentation fault
--
Edit this bug report at http://bugs.php.net/?id=49450&edit=1
#49451 [Opn->Bgs]: Segmentation fault with ArrayObject::offsetSet()
ID: 49451
Updated by: der...@php.net
Reported By: info at adaniels dot nl
-Status: Open
+Status: Bogus
Bug Type: Reproducible crash
Operating System: Linux / Ubuntu 9.04
PHP Version: 5.3.0
New Comment:
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
49449
Previous Comments:
[2009-09-03 10:34:06] info at adaniels dot nl
Description:
Using array access on $this in ArrayObject::offsetSet() causes a
segmentation fault.
(Calling parent::offsetSet() instead, works fine)
Reproduce code:
---
class AOTest extends ArrayObject
{
public function offsetSet($index, $newval)
{
$this[$index] = (int)$newval;
}
}
$a = new AOTest();
$a['test'] = "10 doves";
var_dump((array)$a);
Expected result:
array(1) {
["test"]=>
int(10)
}
Actual result:
--
Segmentation fault
--
Edit this bug report at http://bugs.php.net/?id=49451&edit=1
#49452 [Opn->Bgs]: Segmentation fault with ArrayObject::offsetSet()
ID: 49452
Updated by: der...@php.net
Reported By: info at adaniels dot nl
-Status: Open
+Status: Bogus
Bug Type: Reproducible crash
Operating System: Linux / Ubuntu 9.04
PHP Version: 5.3.0
New Comment:
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
49449
Previous Comments:
[2009-09-03 10:35:05] info at adaniels dot nl
Description:
Using array access on $this in ArrayObject::offsetSet() causes a
segmentation fault.
(Calling parent::offsetSet() instead, works fine)
Reproduce code:
---
class AOTest extends ArrayObject
{
public function offsetSet($index, $newval)
{
$this[$index] = (int)$newval;
}
}
$a = new AOTest();
$a['test'] = "10 doves";
var_dump((array)$a);
Expected result:
array(1) {
["test"]=>
int(10)
}
Actual result:
--
Segmentation fault
--
Edit this bug report at http://bugs.php.net/?id=49452&edit=1
#49450 [Bgs]: Segmentation fault with ArrayObject::offsetSet()
ID: 49450
User updated by: arnold at adaniels dot nl
Reported By: arnold at adaniels dot nl
Status: Bogus
Bug Type: Reproducible crash
Operating System: Linux / Ubuntu 9.04
PHP Version: 5.3.0
New Comment:
The PHP bugs app resulted in 'Authentication failed' and appeared not
to have submitted the bug. Therefor I pressed 'Submit' again. I didn't
get the confirmed page until I cleared my cookies.
Previous Comments:
[2009-09-03 10:42:19] der...@php.net
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
49449
[2009-09-03 10:33:46] arnold at adaniels dot nl
Description:
Using array access on $this in ArrayObject::offsetSet() causes a
segmentation fault.
(Calling parent::offsetSet() instead, works fine)
Reproduce code:
---
class AOTest extends ArrayObject
{
public function offsetSet($index, $newval)
{
$this[$index] = (int)$newval;
}
}
$a = new AOTest();
$a['test'] = "10 doves";
var_dump((array)$a);
Expected result:
array(1) {
["test"]=>
int(10)
}
Actual result:
--
Segmentation fault
--
Edit this bug report at http://bugs.php.net/?id=49450&edit=1
#49447 [Ana->Asn]: php engine need to correctly check for socket API return status on windows
ID: 49447
Updated by: j...@php.net
Reported By: sriram dot natarajan at gmail dot com
-Status: Analyzed
+Status: Assigned
Bug Type: Sockets related
-Operating System: windows xp
+Operating System: win32 only - windows xp
PHP Version: 5.3.0
Assigned To: srinatar
Previous Comments:
[2009-09-03 01:39:46] srina...@php.net
here is the patch to address this issue.
Index: ext/openssl/xp_ssl.c
===
--- ext/openssl/xp_ssl.c(revision 287975)
+++ ext/openssl/xp_ssl.c(working copy)
@@ -259,6 +259,10 @@
SSL_CTX_free(sslsock->ctx);
sslsock->ctx = NULL;
}
+#ifdef PHP_WIN32
+ if (sslsock->s.socket == -1)
+ sslsock->s.socket = SOCK_ERR;
+#endif
if (sslsock->s.socket != SOCK_ERR) {
#ifdef PHP_WIN32
/* prevent more data from coming in */
Index: ext/ftp/ftp.c
===
--- ext/ftp/ftp.c (revision 287975)
+++ ext/ftp/ftp.c (working copy)
@@ -147,7 +147,7 @@
size = sizeof(ftp->localaddr);
memset(&ftp->localaddr, 0, size);
- if (getsockname(ftp->fd, (struct sockaddr*) &ftp->localaddr, &size)
== -1) {
+ if (getsockname(ftp->fd, (struct sockaddr*) &ftp->localaddr, &size)
!= 0) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, "getsockname
failed: %s
(%d)", strerror(errno), errno);
goto bail;
}
@@ -1387,7 +1387,7 @@
sa = (struct sockaddr *) &ftp->localaddr;
/* bind/listen */
- if ((fd = socket(sa->sa_family, SOCK_STREAM, 0)) == -1) {
+ if ((fd = socket(sa->sa_family, SOCK_STREAM, 0)) == SOCK_ERR) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, "socket() failed: %s
(%d)", strerror(errno), errno);
goto bail;
}
@@ -1420,17 +1420,17 @@
php_any_addr(sa->sa_family, &addr, 0);
size = php_sockaddr_size(&addr);
- if (bind(fd, (struct sockaddr*) &addr, size) == -1) {
+ if (bind(fd, (struct sockaddr*) &addr, size) != 0) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, "bind() failed: %s
(%d)", strerror(errno), errno);
goto bail;
}
- if (getsockname(fd, (struct sockaddr*) &addr, &size) == -1) {
+ if (getsockname(fd, (struct sockaddr*) &addr, &size) != 0) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, "getsockname()
failed:
%s (%d)", strerror(errno), errno);
goto bail;
}
- if (listen(fd, 5) == -1) {
+ if (listen(fd, 5) != 0) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, "listen() failed: %s
(%d)", strerror(errno), errno);
goto bail;
}
Index: ext/sockets/sockets.c
===
--- ext/sockets/sockets.c (revision 287975)
+++ ext/sockets/sockets.c (working copy)
@@ -370,14 +370,14 @@
sock->type = PF_INET;
- if (bind(sock->bsd_socket, (struct sockaddr *)&la, sizeof(la)) < 0)
{
+ if (bind(sock->bsd_socket, (struct sockaddr *)&la, sizeof(la)) != 0)
{
PHP_SOCKET_ERROR(sock, "unable to bind to given address",
errno);
close(sock->bsd_socket);
efree(sock);
return 0;
}
- if (listen(sock->bsd_socket, backlog) < 0) {
+ if (listen(sock->bsd_socket, backlog) != 0) {
PHP_SOCKET_ERROR(sock, "unable to listen on socket", errno);
close(sock->bsd_socket);
efree(sock);
Index: main/network.c
===
--- main/network.c (revision 287975)
+++ main/network.c (working copy)
@@ -314,7 +314,7 @@
SET_SOCKET_BLOCKING_MODE(sockfd, orig_flags);
- if ((n = connect(sockfd, addr, addrlen)) < 0) {
+ if ((n = connect(sockfd, addr, addrlen)) != 0) {
error = php_socket_errno();
if (error_code) {
@@ -348,7 +348,7 @@
BSD-derived systems set errno correctly
Solaris returns -1 from getsockopt in case of error
*/
- if (getsockopt(sockfd, SOL_SOCKET, SO_ERROR, (char*)&error,
&len) <
0) {
+ if (getsockopt(sockfd, SOL_SOCKET, SO_ERROR, (char*)&error,
&len) !=
0) {
ret = -1;
}
} else {
@@ -375,7 +375,7 @@
if (asynchronous) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, "Asynchronous
connect()
not supported on this platform");
}
- return connect(sockfd, addr, addrlen);
+ return (connect(sockfd, addr, addrlen) == 0) ? 0 : -1;
#end
#49449 [Opn->Bgs]: Segmentation fault with ArrayObject::offsetSet()
ID: 49449
Updated by: m...@php.net
Reported By: arnold at adaniels dot nl
-Status: Open
+Status: Bogus
Bug Type: Reproducible crash
Operating System: Linux / Ubuntu 9.04
PHP Version: 5.3.0
New Comment:
You generate an infinite recursion.
Previous Comments:
[2009-09-03 10:33:06] arnold at adaniels dot nl
Description:
Using array access on $this in ArrayObject::offsetSet() causes a
segmentation fault.
(Calling parent::offsetSet() instead, works fine)
Reproduce code:
---
class AOTest extends ArrayObject
{
public function offsetSet($index, $newval)
{
$this[$index] = (int)$newval;
}
}
$a = new AOTest();
$a['test'] = "10 doves";
var_dump((array)$a);
Expected result:
array(1) {
["test"]=>
int(10)
}
Actual result:
--
Segmentation fault
--
Edit this bug report at http://bugs.php.net/?id=49449&edit=1
#49444 [Fbk->Bgs]: $_GET variable
ID: 49444
Updated by: m...@php.net
Reported By: hafizanil at gmail dot com
-Status: Feedback
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Windows Xp
PHP Version: 5.3.0
New Comment:
JS treats literal new lines as delimiter.
Previous Comments:
[2009-09-03 09:39:20] sjo...@php.net
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
Thank you for your interest in PHP.
[2009-09-03 01:16:15] hafizanil at gmail dot com
Javascript (Page 1)
function sentMail() {
var url;
var to;
url = 'ml_compose_com.php?';
document.form.title.value='admin (sit: mr chang n mr sairi n mr
pzan)
,';
title = escape(document.form.title.value);
if(title){ url= url+'&title='+ title; }
location = url+"&sent_mail=1";
}
Page 2 (ml_compose_com.php)
".print_r($_GET)."";
var_dump($_GET);
?>
[2009-09-02 19:11:27] j...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
[2009-09-02 16:07:28] hafizanil at gmail dot com
Description:
Want to sent variable via javascript via $_GET method and the output
going hirewire.The varible sent also been escape
first(javascript).Tested using 5.29 and 5.3
Browser 1.Internet Explorer 7
2 Firefox 3.52
3. Opera 10
Reproduce code:
---
This is tested 5.29
[code]
$_GET['to']="admin (sit: mr chang n mr sairi n mr pzan)
,";
echo strlen($_GET['to'])
// out put 63
var_dump($_GET);
// output only showing admin (sit: mr chang n mr sairi n mr pzan)
[/code]
This is tested 5.30
[code]
$_GET['to']="admin (sit: mr chang n mr sairi n mr pzan)
,";
echo strlen($_GET['to'])
// out put 63
var_dump($_GET);
//output :Page going crazy.show all the php source
[/code]
Expected result:
var_dump or print_r $_GET array should understand the variable which
might contain "<>";
Actual result:
--
On 5.3 It show all the source php .
--
Edit this bug report at http://bugs.php.net/?id=49444&edit=1
#49454 [NEW]: Call ArrayObject::getArrayCopy() when casting an ArrayObject to an array
From: info at adaniels dot nl
Operating system: Linux / Ubuntu 9.04
PHP version: 5.3.0
PHP Bug Type: Feature/Change Request
Bug description: Call ArrayObject::getArrayCopy() when casting an ArrayObject
to an array
Description:
It would be nice if you could affect the behaviour of casting an
ArrayObject to an array by overloading the getArrayCopy() method.
This would be usefull to create lazy load arrays.
Reproduce code:
---
$id));
}
public function offsetGet($key)
{
$item = parent::offsetGet($key);
if (!is_object($item)) {
$item = $this->load($item);
$this->offsetSet($key, $item);
}
return $item;
}
public function getArrayCopy()
{
$array = parent::getArrayCopy();
foreach ($array as $i=>&$item) {
if (!is_object($item)) {
$item = $this->load($item);
$this->offsetSet($i, $item);
}
}
return $array;
}
}
$a = new Items();
$a[] = 'jan';
$a[] = 'piet';
var_dump($a[0]);
var_dump((array)$a);
Expected result:
object(stdClass)#2 (1) {
["id"]=>
string(3) "jan"
}
array(2) {
[0]=>
object(stdClass)#2 (1) {
["id"]=>
string(3) "jan"
}
[1]=>
object(stdClass)#3 (1) {
["id"]=>
string(4) "piet"
}
}
Actual result:
--
object(stdClass)#2 (1) {
["id"]=>
string(3) "jan"
}
array(2) {
[0]=>
object(stdClass)#2 (1) {
["id"]=>
string(3) "jan"
}
[1]=>
string(4) "piet"
}
--
Edit bug report at http://bugs.php.net/?id=49454&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49454&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49454&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49454&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49454&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49454&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49454&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49454&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49454&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49454&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49454&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49454&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49454&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49454&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49454&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49454&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49454&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49454&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49454&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49454&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49454&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49454&r=mysqlcfg
#49436 [Opn->Fbk]: during query executed, mysql connection lost
ID: 49436
Updated by: j...@php.net
Reported By: november at netsecuretech dot com
-Status: Open
+Status: Feedback
Bug Type: MySQLi related
Operating System: windowsXP
PHP Version: 5.3.0
New Comment:
Did you check the mysql server error log if it has any clues what
happened?
Previous Comments:
[2009-09-02 10:07:21] november at netsecuretech dot com
I installed VC9 x86 Thread Safe (2009-Sep-02 11:00:00) verion.
It is not work well.
result is below...
thank you.
C:\php\Script>..\php.exe mysqli_test.php
2009-09-02 19:03:27 => query start...
2006 MySQL server has gone away
2009-09-02 19:04:27 => query end...
C:\php\Script>
[2009-09-02 09:41:45] j...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2009-09-02 04:40:26] november at netsecuretech dot com
mysql query takes 20~30 minutes;
$query = "create table test as select c_ip, count(*) from iis_summary
group by c_ip";
thank you
[2009-09-02 04:37:23] november at netsecuretech dot com
Description:
PHP version : 5.3.0 Windows Binary VC9 x86 Thread Safe (2009-Jun-30
08:52:56)
Mysql version : 5.1.37-community-edition (CentOS 4.7)
I use php CLI SAPI.
PHP cli's default max_execution_time is unlimited.
When I execute php script, mysql connection is lost.
When I use php 5.2.10, mysql query executed well.
What Can I do?
Thank you.
Reproduce code:
---
query start...\r\n";
$query = "create table test as select c_ip, count(*) from iis_summary
group by c_ip";
mysqli_query($db, $query);
if (mysqli_errno($db) != 0) {
echo mysqli_errno($db)." ".mysqli_error($db)."\r\n";
}
echo date("Y-m-d H:i:s")." => query end...\r\n";
mysqli_close($db);
?>
Expected result:
During query, mysql connection lost.
PHP Warning: mysqli_query(): MySQL server has gone away in
C:\php\Script\mysqli
_test.php on line 14
Actual result:
--
C:\php\Script>..\php.exe mysqli_test.php
2009-09-02 13:23:15 => query start...
PHP Warning: mysqli_query(): MySQL server has gone away in
C:\php\Script\mysqli
_test.php on line 14
PHP Warning: mysqli_query(): Error reading result set's header in
C:\php\Script
\mysqli_test.php on line 14
2006 MySQL server has gone away
2009-09-02 13:24:15 => query end...
C:\php\Script>
--
Edit this bug report at http://bugs.php.net/?id=49436&edit=1
#49444 [Bgs]: $_GET variable
ID: 49444
User updated by: hafizanil at gmail dot com
Reported By: hafizanil at gmail dot com
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Windows Xp
PHP Version: 5.3.0
New Comment:
Thesolution i try is to split the string in js first
[code]
to_array = to.split("<");
[/code]
Then send back to php as reference.Bug still consider as a bug.
E.g Again
address bar : test.php?mail=admin (sit: mr chang n mr sairi n mr pzan)
[code]
";
echo print_r($_GET);
echo "";
?>
[/code]
Output
Array
(
[mail] => admin (sit: mr chang n mr sairi n mr pzan)
)
1
Image :http://img512.imageshack.us/img512/9974/bugso.jpg
Previous Comments:
[2009-09-03 11:13:37] m...@php.net
JS treats literal new lines as delimiter.
[2009-09-03 09:39:20] sjo...@php.net
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
Thank you for your interest in PHP.
[2009-09-03 01:16:15] hafizanil at gmail dot com
Javascript (Page 1)
function sentMail() {
var url;
var to;
url = 'ml_compose_com.php?';
document.form.title.value='admin (sit: mr chang n mr sairi n mr
pzan)
,';
title = escape(document.form.title.value);
if(title){ url= url+'&title='+ title; }
location = url+"&sent_mail=1";
}
Page 2 (ml_compose_com.php)
".print_r($_GET)."";
var_dump($_GET);
?>
[2009-09-02 19:11:27] j...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
[2009-09-02 16:07:28] hafizanil at gmail dot com
Description:
Want to sent variable via javascript via $_GET method and the output
going hirewire.The varible sent also been escape
first(javascript).Tested using 5.29 and 5.3
Browser 1.Internet Explorer 7
2 Firefox 3.52
3. Opera 10
Reproduce code:
---
This is tested 5.29
[code]
$_GET['to']="admin (sit: mr chang n mr sairi n mr pzan)
,";
echo strlen($_GET['to'])
// out put 63
var_dump($_GET);
// output only showing admin (sit: mr chang n mr sairi n mr pzan)
[/code]
This is tested 5.30
[code]
$_GET['to']="admin (sit: mr chang n mr sairi n mr pzan)
,";
echo strlen($_GET['to'])
// out put 63
var_dump($_GET);
//output :Page going crazy.show all the php source
[/code]
Expected result:
var_dump or print_r $_GET array should understand the variable which
might contain "<>";
Actual result:
--
On 5.3 It show all the source php .
--
Edit this bug report at http://bugs.php.net/?id=49444&edit=1
#49383 [Bgs]: Lots of empty fstat() calls slow performance
ID: 49383
User updated by: olga at metacafe dot com
Reported By: olga at metacafe dot com
Status: Bogus
Bug Type: Performance problem
Operating System: Red Hat 3.4.6-10
PHP Version: 5.3, 6
New Comment:
Turning all messages on/off didn't change the behavior. We tend
eliminate the notices on the development stage.
Can you please look at the system calls summary below? fstat() takes
25% of the total time. This doesn't happen in PHP 5.2.9.
% time seconds usecs/call callserrors syscall
-- --- --- - -
24.85 33.820248 256131908 fstat
13.54 18.431644 263 7000266 lstat
9.81 13.346466 259 51520 mmap
9.72 13.223388 258 51175 munmap
9.39 12.775102 264 48450 192 stat
8.83 12.014341 265 4538310 open
8.72 11.866944 257 46154 close
3.474.724639 255 18530 396 read
3.264.430927 256 17297 lseek
1.882.557480 244 10477 poll
1.592.170520 261 8326 recvfrom
1.522.073135 259 7994 sendto
...
-- --- --- - -
100.00 136.108580526555 1324 total
In 5.2.9 fstat() takes about 8% of total time.
Previous Comments:
[2009-09-01 18:27:31] ras...@php.net
You need to do proper profiling to determine that. Start by turning on
all warning messages. If you are throwing warnings or notices, even if
you are not displaying or logging them anywhere, it is going to slow you
down and there are a bunch of new ones in 5.3. Set your error reporting
to something like 16777215 (0xff) which will catch all current and
future error levels and fix anything you see. Then check your
performance again.
[2009-09-01 18:13:05] olga at metacafe dot com
When I compare 5.2.9 with 5.3, I see that
(a) 5.3 is slower. According to release notes, I was expecting
performance improvement, or at least the same performance as in previous
version.
(b) top 5 system calls in 5.3 take more time that in 5.2.9
lstat() calls are reduced, but fstat(), mmap() and munmap() are used
much more than before.
Maybe I'm wrong about fstat(), but that's the only difference I found
so far. What else could have caused this performance problem?
[2009-09-01 15:01:17] ras...@php.net
You suppose it is because of fstat? I seriously doubt that. fstat is
really fast because it doesn't need to touch the disk at all. It simply
grabs the stat struct from an already open file descriptor. If you can
show me some profiling numbers where fstat is anywhere on the radar,
I'll take a look, but I am highly suspicious that fstat would have
anything to do with any performance issues.
Disk-touching stats like lstat are the ones you need to worry about.
[2009-09-01 14:48:03] olga at metacafe dot com
Any PHP code does it.
The code:
The strace:
open("[path]/test.php", O_RDONLY) = 16
fstat(16, {st_mode=S_IFREG|0644, st_size=82, ...}) = 0
fstat(16, {st_mode=S_IFREG|0644, st_size=82, ...}) = 0
fstat(16, {st_mode=S_IFREG|0644, st_size=82, ...}) = 0
mmap(NULL, 82, PROT_READ, MAP_SHARED, 16, 0) = 0x2a9a8b4000
munmap(0x2a9a8b4000, 82)= 0
close(16) = 0
[2009-08-31 11:48:20] j...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/49383
--
Edit this bug report at http://bugs.php.net/?id=49383&edit=1
#49455 [NEW]: eval works or not with __FILE__ and basename
From: djalmaoliveira at gmail dot com
Operating system: Ubuntu
PHP version: 5.2.10
PHP Bug Type: Unknown/Other Function
Bug description: eval works or not with __FILE__ and basename
Description:
When I execute this code, the first eval() works, but the second breaks.
It's a bug?
Reproduce code:
---
eval('echo dirname(__FILE__);');
echo "";
eval('echo basename(__FILE__);');
Expected result:
The second eval() works.
Actual result:
--
The second eval(): eval()'d code
--
Edit bug report at http://bugs.php.net/?id=49455&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49455&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49455&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49455&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49455&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49455&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49455&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49455&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49455&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49455&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49455&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49455&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49455&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49455&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49455&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49455&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49455&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49455&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49455&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49455&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49455&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49455&r=mysqlcfg
#46814 [Com]: Relative includes from symlinked directories fail
ID: 46814 Comment by: michele dot manzato at gmail dot com Reported By: dennis dot birkholz at nexxes dot net Status: No Feedback Bug Type: Scripting Engine problem Operating System: Gentoo/Linux PHP Version: 5.2.8 New Comment: I confirm this bug. Here is the simplest reproduce code that I was able to make up: ~$ cd /tmp /tmp$ mkdir a /tmp$ mkdir b /tmp$ echo '' > a/test.php /tmp$ echo '' > b/inc.php /tmp$ ln -s /tmp/a b/c /tmp$ cd b/c/ /tmp/b/c$ php -f test.php /tmp/a Warning: require(../inc.php): failed to open stream: No such file or directory in /tmp/a/test.php on line 1 As one can see, the script's CWD is /tmp/a although the script was run from /tmp/b/c. As a result the following require() instruction fails because it can't find /inc.php (which should have been /tmp/b/inc.php instead). The problem here is not the require(). It is that the CWD is converted to the real path when, instead, it should remain the symlinked path. Previous Comments: [2008-12-29 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2008-12-21 13:12:11] j...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. [2008-12-18 21:28:43] dennis dot birkholz at nexxes dot net No, you did not read my initial post correctly: a file/directory starting with a / (like /test1) means it is in the root-directory. All example pathnames where absolute pathnames, not relative. Here comes my listing for you: /htdocs/: total 12 drwxr-xr-x 3 root root 4096 Dec 18 22:23 ./ drwxr-xr-x 22 root root 4096 Dec 18 22:23 ../ drwxr-xr-x 2 root root 4096 Dec 18 22:23 docs/ lrwxrwxrwx 1 root root6 Dec 18 22:23 test2 -> /test1/ /htdocs/docs/: insgesamt 8 drwxr-xr-x 2 root root 4096 18. Dez 22:23 ./ drwxr-xr-x 3 root root 4096 18. Dez 22:23 ../ -rw-r--r-- 1 root root0 18. Dez 22:23 docs.inc.php /test1/: total 8 drwxr-xr-x 2 root root 4096 18. Dez 22:24 ./ drwxr-xr-x 22 root root 4096 18. Dez 22:23 ../ -rw-r--r-- 1 root root0 18. Dez 22:24 index.php Please note that test1 and test2 are not on the same directory level! [2008-12-18 09:05:37] php at degoulet dot net I don't realy understand your problem ?! [r...@pix sdv]# ls -alR .: total 16 drwxr-xr-x 4 root root4096 Dec 17 17:44 . drwxrwxrwx 3 via ftponly 4096 Dec 17 17:44 .. drwxr-xr-x 2 root root4096 Dec 17 17:45 docs drwxr-xr-x 2 root root4096 Dec 17 17:46 test1 lrwxrwxrwx 1 root root 5 Dec 17 17:44 test2 -> test1 ./docs: total 12 drwxr-xr-x 2 root root 4096 Dec 17 17:45 . drwxr-xr-x 4 root root 4096 Dec 17 17:44 .. -rw-r--r-- 1 root root 24 Dec 17 17:45 docs.inc.php ./test1: total 12 drwxr-xr-x 2 root root 4096 Dec 17 17:46 . drwxr-xr-x 4 root root 4096 Dec 17 17:44 .. -rw-r--r-- 1 root root 50 Dec 17 17:46 index.php [r...@pix sdv]# cat test1/index.php [r...@pix sdv]# cat docs/docs.inc.php No problem when i try this with apache : http://www..com/sdv/test1/index.php http://www..com/sdv/test2/index.php ==> same output : docs ok if you try this in command line. 3 cases : - pwd= test1 : php index.php => output docs ok - pwd= test2 : php index.php => output docs ok - pwd= anywhere else : php ./test1/index.php : include(): Unable to access ../docs/docs.inc.php which is quite normal the include path is relative to the current directory where php is executed not relative to the php script which is executed ... isn't it ? [2008-12-17 22:35:25] dennis dot birkholz at nexxes dot net This IS a bug: in Linux (and Unix like systems) beeing in a symlinked directory should behave exactly like beeing in a directory with the same content. To use my example: If I use a shell and change to the folder /htdocs/test2 (which is a symlink to /test1), ls ../docs/docs.inc.php will show me the file "/htdocs/docs/docs.inc.php" and NOT "/docs/docs.inc.php". The remainder of the comments for t
#49383 [Bgs->Ana]: Lots of empty fstat() calls slow performance
ID: 49383 Updated by: ras...@php.net Reported By: olga at metacafe dot com -Status: Bogus +Status: Analyzed Bug Type: Performance problem Operating System: Red Hat 3.4.6-10 PHP Version: 5.3, 6 New Comment: Still surprised these fstats take that long on your system. Note also that if you install APC, they completely go away. If you are down to caring about performance at the syscall level like that and you are not running a decent opcode cache, you are kind of confused. Here is a backtrace of those 3 fstats: #1 0x0137642f in do_fstat () #2 0x0137768f in _php_stream_fopen () #3 0x013719ba in _php_stream_open_wrapper_ex () #4 0x0135a1a3 in php_stream_open_for_zend_ex () #5 0x0135a2e0 in php_stream_open_for_zend () #6 0x013ca05f in zend_stream_fixup () #7 0x01383ae7 in open_file_for_scanning () #8 0x01383c8d in compile_file () #9 0x011eb8f7 in phar_compile_file () #10 0x013b4fa7 in zend_execute_scripts () #11 0x0135be38 in php_execute_script () #1 0x0137642f in do_fstat () #2 0x01376ee1 in php_stdiop_stat () #3 0x0135a148 in php_zend_stream_fsizer () #4 0x0135a206 in php_stream_open_for_zend_ex () #5 0x0135a2e0 in php_stream_open_for_zend () #6 0x013ca05f in zend_stream_fixup () #7 0x01383ae7 in open_file_for_scanning () #8 0x01383c8d in compile_file () #9 0x011eb8f7 in phar_compile_file () #10 0x013b4fa7 in zend_execute_scripts () #11 0x0135be38 in php_execute_script () #1 0x0137642f in do_fstat () #2 0x01377189 in php_stdiop_set_option () #3 0x0136fc8e in _php_stream_set_option () #4 0x0137dcec in _php_stream_mmap_range () #5 0x0135a295 in php_stream_open_for_zend_ex () #6 0x0135a2e0 in php_stream_open_for_zend () #7 0x013ca05f in zend_stream_fixup () #8 0x01383ae7 in open_file_for_scanning () #9 0x01383c8d in compile_file () #10 0x011eb8f7 in phar_compile_file () #11 0x013b4fa7 in zend_execute_scripts () #12 0x0135be38 in php_execute_script () The do_fstat() function has a cache, but those 3 calls set the 'force' flag to ignore the cached stat struct. We need to track down whether it is possible to not force these. It seems like it should be possible to get rid of at least one of those, if not 2. But again, install an opcode cache, and this stops being a problem. Previous Comments: [2009-09-03 12:59:44] olga at metacafe dot com Turning all messages on/off didn't change the behavior. We tend eliminate the notices on the development stage. Can you please look at the system calls summary below? fstat() takes 25% of the total time. This doesn't happen in PHP 5.2.9. % time seconds usecs/call callserrors syscall -- --- --- - - 24.85 33.820248 256131908 fstat 13.54 18.431644 263 7000266 lstat 9.81 13.346466 259 51520 mmap 9.72 13.223388 258 51175 munmap 9.39 12.775102 264 48450 192 stat 8.83 12.014341 265 4538310 open 8.72 11.866944 257 46154 close 3.474.724639 255 18530 396 read 3.264.430927 256 17297 lseek 1.882.557480 244 10477 poll 1.592.170520 261 8326 recvfrom 1.522.073135 259 7994 sendto ... -- --- --- - - 100.00 136.108580526555 1324 total In 5.2.9 fstat() takes about 8% of total time. [2009-09-01 18:27:31] ras...@php.net You need to do proper profiling to determine that. Start by turning on all warning messages. If you are throwing warnings or notices, even if you are not displaying or logging them anywhere, it is going to slow you down and there are a bunch of new ones in 5.3. Set your error reporting to something like 16777215 (0xff) which will catch all current and future error levels and fix anything you see. Then check your performance again. [2009-09-01 18:13:05] olga at metacafe dot com When I compare 5.2.9 with 5.3, I see that (a) 5.3 is slower. According to release notes, I was expecting performance improvement, or at least the same performance as in previous version. (b) top 5 system calls in 5.3 take more time that in 5.2.9 lstat() calls are reduced, but fstat(), mmap() and munmap() are used much more than before. Maybe I'm wrong about fstat(), but that's the only difference I found so far. What else could have caused this performance problem? [2009-09-01 15:01:17] ras...@php.net You suppose it is because of fstat? I seriously doubt that
#46074 [Asn->Csd]: Bus error during running PHP CLI under IRIX 6.5.30
ID: 46074 Updated by: dmi...@php.net Reported By: neko at nekochan dot net -Status: Assigned +Status: Closed Bug Type: Reproducible crash Operating System: IRIX 6.5.30 PHP Version: 5.3.0alpha2 Assigned To: dmitry New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2009-09-03 14:33:12] s...@php.net Automatic comment from SVN on behalf of dmitry Revision: http://svn.php.net/viewvc/?view=revision&revision=287992 Log: Fixed bug #46074 (Bus error during running PHP CLI under IRIX 6.5.30) [2009-09-02 11:24:20] dmi...@php.net Can anyone provide an access to IRIX server, where I can check the patch? (contact me by email) [2009-08-21 20:18:23] dgarciacampos at gmail dot com I just finished compiling and "make test"ing php on a linux-sparc machine. bash-3.2$ uname -a Linux gcars0kq 2.6.27.12-78.2.9.fc9.sparc64.smp #1 SMP Sat Jan 24 22:46:27 EST 2009 sparc64 sparc64 sparc64 GNU/Linux I'd like to point out that the last patch from the e-mail thread below is slightly wrong, thread heading: ([12 Jul 5:20am UTC] pogma at thewrittenword dot com) The changes made to Zend/zend_vm_execute.h a somewhat misleading. If anybody needs a copy of this file or the the other two files mentioned in the patch, i can gladly send them to you, just e-mail me at dgarciacampos at gmail dot com. Thanks, David A. Garcia-Campos [2009-07-14 02:49:51] pogma at thewrittenword dot com Well, even though it built and tested ok, the patch had an error. + sizeof(temp_variable) * op_array->T TSRMLS_CC)); should be + sizeof(temp_variable) * op_array->T) TSRMLS_CC); Seems to be that building php with an apxs that was built with mpm=worker requires this. [2009-07-12 17:56:14] neko at nekochan dot net I've tested the new patch and it is also working well on IRIX. Thanks much! 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/46074 -- Edit this bug report at http://bugs.php.net/?id=46074&edit=1
#49456 [NEW]: Script current working directory converted to real path cause require() errors
From: michele dot manzato at gmail dot com Operating system: Ubuntu/Hardy PHP version: 5.2.11RC1 PHP Bug Type: Scripting Engine problem Bug description: Script current working directory converted to real path cause require() errors Description: PHP script current working directory being converted to the real path cause error in relative files inclusion (see also bug #46814). As one can see in the reproduce code the script's getcwd() says '/tmp/a' although the script was run from '/tmp/b/c'. As a result the require() instruction fails because it can't find any '/inc.php'. '/tmp/b/inc.php' would have been found if the original symlinked path was preserved. Reproduce code: --- ~$ cd /tmp /tmp$ mkdir a /tmp$ mkdir b /tmp$ echo '' > a/test.php /tmp$ echo '' > b/inc.php /tmp$ ln -s /tmp/a b/c /tmp$ cd b/c/ /tmp/b/c$ php -f test.php Expected result: ok Actual result: -- /tmp/a Warning: require(../inc.php): failed to open stream: No such file or directory in /tmp/a/test.php on line 1 Fatal error: require(): Failed opening required '../inc.php' (include_path='.:/usr/share/php:/usr/share/pear') in /tmp/a/test.php on line 1 -- Edit bug report at http://bugs.php.net/?id=49456&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49456&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49456&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49456&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49456&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49456&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49456&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49456&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49456&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49456&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49456&r=support Expected behavior: http://bugs.php.net/fix.php?id=49456&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49456&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49456&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49456&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49456&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49456&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49456&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49456&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49456&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49456&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49456&r=mysqlcfg
#49456 [Opn->Bgs]: Script current working directory converted to real path cause require() errors
ID: 49456 Updated by: sjo...@php.net Reported By: michele dot manzato at gmail dot com -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: Ubuntu/Hardy PHP Version: 5.2.11RC1 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 Note that this behavior is the same as in a shell: cd b/c ls .. It shows the contents of /tmp, not the contents of /tmp/b. This works as it should. Previous Comments: [2009-09-03 14:36:40] michele dot manzato at gmail dot com Description: PHP script current working directory being converted to the real path cause error in relative files inclusion (see also bug #46814). As one can see in the reproduce code the script's getcwd() says '/tmp/a' although the script was run from '/tmp/b/c'. As a result the require() instruction fails because it can't find any '/inc.php'. '/tmp/b/inc.php' would have been found if the original symlinked path was preserved. Reproduce code: --- ~$ cd /tmp /tmp$ mkdir a /tmp$ mkdir b /tmp$ echo '' > a/test.php /tmp$ echo '' > b/inc.php /tmp$ ln -s /tmp/a b/c /tmp$ cd b/c/ /tmp/b/c$ php -f test.php Expected result: ok Actual result: -- /tmp/a Warning: require(../inc.php): failed to open stream: No such file or directory in /tmp/a/test.php on line 1 Fatal error: require(): Failed opening required '../inc.php' (include_path='.:/usr/share/php:/usr/share/pear') in /tmp/a/test.php on line 1 -- Edit this bug report at http://bugs.php.net/?id=49456&edit=1
#49458 [NEW]: passthru is unable to fork
From: RQuadling at GMail dot com
Operating system: Windows XP SP3
PHP version: 5.3SVN-2009-09-03 (SVN)
PHP Bug Type: Filesystem function related
Bug description: passthru is unable to fork
Description:
Unable to fork. As a consequence, phpdoc/configure.php fails on windows
as it is unable to call external scripts.
Run the command below at the command prompt.
This works on PHP 5.3.0 (cli) (built: Jun 29 2009 21:44:56)
Reproduce code:
---
php -n -r "echo passthru('php.exe -v');"
Expected result:
PHP 5.3.1-dev (cli) (built: Sep 3 2009 09:58:01)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies
Actual result:
--
Warning: passthru(): Unable to fork [php.exe -v] in Command line code on
line 1
--
Edit bug report at http://bugs.php.net/?id=49458&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49458&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49458&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49458&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49458&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49458&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49458&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49458&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49458&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49458&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49458&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49458&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49458&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49458&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49458&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49458&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49458&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49458&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49458&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49458&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49458&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49458&r=mysqlcfg
#49455 [Opn->Bgs]: eval works or not with __FILE__ and basename
ID: 49455
Updated by: sjo...@php.net
Reported By: djalmaoliveira at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Unknown/Other Function
Operating System: Ubuntu
PHP Version: 5.2.10
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
Basename does work. However __FILE__ contains the following:
/home/sjoerd/public_html/a.php(2) : eval()'d code
This makes basename(__FILE__) contain:
a.php(2) : eval()'d code
So the behavior is expected.
Previous Comments:
[2009-09-03 13:13:14] djalmaoliveira at gmail dot com
Description:
When I execute this code, the first eval() works, but the second
breaks.
It's a bug?
Reproduce code:
---
eval('echo dirname(__FILE__);');
echo "";
eval('echo basename(__FILE__);');
Expected result:
The second eval() works.
Actual result:
--
The second eval(): eval()'d code
--
Edit this bug report at http://bugs.php.net/?id=49455&edit=1
#49458 [Opn->Fbk]: passthru is unable to fork
ID: 49458
Updated by: paj...@php.net
Reported By: RQuadling at GMail dot com
-Status: Open
+Status: Feedback
Bug Type: Filesystem function related
Operating System: Windows XP SP3
PHP Version: 5.3SVN-2009-09-03 (SVN)
-Assigned To:
+Assigned To: pajoye
New Comment:
Which version do you use? It works here using vc9/x86
Previous Comments:
[2009-09-03 14:46:51] RQuadling at GMail dot com
Description:
Unable to fork. As a consequence, phpdoc/configure.php fails on windows
as it is unable to call external scripts.
Run the command below at the command prompt.
This works on PHP 5.3.0 (cli) (built: Jun 29 2009 21:44:56)
Reproduce code:
---
php -n -r "echo passthru('php.exe -v');"
Expected result:
PHP 5.3.1-dev (cli) (built: Sep 3 2009 09:58:01)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies
Actual result:
--
Warning: passthru(): Unable to fork [php.exe -v] in Command line code
on
line 1
--
Edit this bug report at http://bugs.php.net/?id=49458&edit=1
#49383 [Ana]: Lots of empty fstat() calls slow performance
ID: 49383 User updated by: olga at metacafe dot com Reported By: olga at metacafe dot com Status: Analyzed Bug Type: Performance problem Operating System: Red Hat 3.4.6-10 PHP Version: 5.3, 6 New Comment: Thanks for the quick response. We do work with APC. I tested the new PHP without APC also, to make sure the fstat() calls aren't caused by it. But the statistics I sent to you are from web server that works with APC. You can also see from my first submission that in 5.2.9 fstat() doesn't take much time. Previous Comments: [2009-09-03 14:24:14] ras...@php.net Still surprised these fstats take that long on your system. Note also that if you install APC, they completely go away. If you are down to caring about performance at the syscall level like that and you are not running a decent opcode cache, you are kind of confused. Here is a backtrace of those 3 fstats: #1 0x0137642f in do_fstat () #2 0x0137768f in _php_stream_fopen () #3 0x013719ba in _php_stream_open_wrapper_ex () #4 0x0135a1a3 in php_stream_open_for_zend_ex () #5 0x0135a2e0 in php_stream_open_for_zend () #6 0x013ca05f in zend_stream_fixup () #7 0x01383ae7 in open_file_for_scanning () #8 0x01383c8d in compile_file () #9 0x011eb8f7 in phar_compile_file () #10 0x013b4fa7 in zend_execute_scripts () #11 0x0135be38 in php_execute_script () #1 0x0137642f in do_fstat () #2 0x01376ee1 in php_stdiop_stat () #3 0x0135a148 in php_zend_stream_fsizer () #4 0x0135a206 in php_stream_open_for_zend_ex () #5 0x0135a2e0 in php_stream_open_for_zend () #6 0x013ca05f in zend_stream_fixup () #7 0x01383ae7 in open_file_for_scanning () #8 0x01383c8d in compile_file () #9 0x011eb8f7 in phar_compile_file () #10 0x013b4fa7 in zend_execute_scripts () #11 0x0135be38 in php_execute_script () #1 0x0137642f in do_fstat () #2 0x01377189 in php_stdiop_set_option () #3 0x0136fc8e in _php_stream_set_option () #4 0x0137dcec in _php_stream_mmap_range () #5 0x0135a295 in php_stream_open_for_zend_ex () #6 0x0135a2e0 in php_stream_open_for_zend () #7 0x013ca05f in zend_stream_fixup () #8 0x01383ae7 in open_file_for_scanning () #9 0x01383c8d in compile_file () #10 0x011eb8f7 in phar_compile_file () #11 0x013b4fa7 in zend_execute_scripts () #12 0x0135be38 in php_execute_script () The do_fstat() function has a cache, but those 3 calls set the 'force' flag to ignore the cached stat struct. We need to track down whether it is possible to not force these. It seems like it should be possible to get rid of at least one of those, if not 2. But again, install an opcode cache, and this stops being a problem. [2009-09-03 12:59:44] olga at metacafe dot com Turning all messages on/off didn't change the behavior. We tend eliminate the notices on the development stage. Can you please look at the system calls summary below? fstat() takes 25% of the total time. This doesn't happen in PHP 5.2.9. % time seconds usecs/call callserrors syscall -- --- --- - - 24.85 33.820248 256131908 fstat 13.54 18.431644 263 7000266 lstat 9.81 13.346466 259 51520 mmap 9.72 13.223388 258 51175 munmap 9.39 12.775102 264 48450 192 stat 8.83 12.014341 265 4538310 open 8.72 11.866944 257 46154 close 3.474.724639 255 18530 396 read 3.264.430927 256 17297 lseek 1.882.557480 244 10477 poll 1.592.170520 261 8326 recvfrom 1.522.073135 259 7994 sendto ... -- --- --- - - 100.00 136.108580526555 1324 total In 5.2.9 fstat() takes about 8% of total time. [2009-09-01 18:27:31] ras...@php.net You need to do proper profiling to determine that. Start by turning on all warning messages. If you are throwing warnings or notices, even if you are not displaying or logging them anywhere, it is going to slow you down and there are a bunch of new ones in 5.3. Set your error reporting to something like 16777215 (0xff) which will catch all current and future error levels and fix anything you see. Then check your performance again. [2009-09-01 18:13:05] olga at metacafe dot com When I compare 5.2.9 with 5.3, I see that (a) 5.3 is slower. According to release notes, I was expecting performance improvement, or at least the same performance as in previous version. (b) top 5 system calls in 5.3 take more time that i
#49458 [Com]: passthru is unable to fork
ID: 49458
Comment by: RQuadling at GMail dot com
Reported By: RQuadling at GMail dot com
Status: Feedback
Bug Type: Filesystem function related
Operating System: Windows XP SP3
PHP Version: 5.3SVN-2009-09-03 (SVN)
Assigned To: pajoye
New Comment:
[2009/09/03 16:18:38] [D:\Personal
Files\Downloads\Software\Programming\PHP\Latest Snapshots\php-5.3-nts-
win32-VC6-x86-latest] [] >php -n -v
PHP 5.3.1-dev (cli) (built: Sep 3 2009 10:16:30)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies
[2009/09/03 16:18:40] [D:\Personal
Files\Downloads\Software\Programming\PHP\Latest Snapshots\php-5.3-nts-
win32-VC6-x86-latest] [] >php -n -r "echo passthru('php.exe -n -v');"
Warning: passthru(): Unable to fork [php.exe -v] in Command line code
on line 1
[2009/09/03 16:18:48] [D:\Personal
Files\Downloads\Software\Programming\PHP\Latest Snapshots\php-5.3-nts-
win32-VC6-x86-latest] [] >
Basically, all the latest snapshots from windows.php.net are failing
for me.
All the official releases are working for me.
Checking historical versions ...
PHP 5.3.1-dev (cli) (built: Aug 27 2009 23:21:09) Works
PHP 5.3.1-dev (cli) (built: Aug 28 2009 00:20:34) Works
PHP 5.3.1-dev (cli) (built: Aug 28 2009 01:20:31) Works
I'll get the historical updates and let you know when the failure
started.
Have you got any uncommitted code?
Previous Comments:
[2009-09-03 14:54:12] paj...@php.net
Which version do you use? It works here using vc9/x86
[2009-09-03 14:46:51] RQuadling at GMail dot com
Description:
Unable to fork. As a consequence, phpdoc/configure.php fails on windows
as it is unable to call external scripts.
Run the command below at the command prompt.
This works on PHP 5.3.0 (cli) (built: Jun 29 2009 21:44:56)
Reproduce code:
---
php -n -r "echo passthru('php.exe -v');"
Expected result:
PHP 5.3.1-dev (cli) (built: Sep 3 2009 09:58:01)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies
Actual result:
--
Warning: passthru(): Unable to fork [php.exe -v] in Command line code
on
line 1
--
Edit this bug report at http://bugs.php.net/?id=49458&edit=1
#49458 [Com]: passthru is unable to fork
ID: 49458
Comment by: RQuadling at GoogleMail dot com
Reported By: RQuadling at GMail dot com
Status: Feedback
Bug Type: Filesystem function related
Operating System: Windows XP SP3
PHP Version: 5.3SVN-2009-09-03 (SVN)
Assigned To: pajoye
New Comment:
[2009/09/03 16:18:38] [D:\Personal
Files\Downloads\Software\Programming\PHP\Latest Snapshots\php-5.3-nts-
win32-VC6-x86-latest] [] >php -n -v
PHP 5.3.1-dev (cli) (built: Sep 3 2009 10:16:30)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies
[2009/09/03 16:18:40] [D:\Personal
Files\Downloads\Software\Programming\PHP\Latest Snapshots\php-5.3-nts-
win32-VC6-x86-latest] [] >php -n -r "echo passthru('php.exe -n -v');"
Warning: passthru(): Unable to fork [php.exe -v] in Command line code
on line 1
[2009/09/03 16:18:48] [D:\Personal
Files\Downloads\Software\Programming\PHP\Latest Snapshots\php-5.3-nts-
win32-VC6-x86-latest] [] >
Basically, all the latest snapshots from windows.php.net are failing
for me.
All the official releases are working for me.
Checking historical versions ...
PHP 5.3.1-dev (cli) (built: Aug 27 2009 23:21:09) Works
PHP 5.3.1-dev (cli) (built: Aug 28 2009 00:20:34) Works
PHP 5.3.1-dev (cli) (built: Aug 28 2009 01:20:31) Works
I'll get the historical updates and let you know when the failure
started.
Have you got any uncommitted code?
Previous Comments:
[2009-09-03 15:31:54] RQuadling at GMail dot com
[2009/09/03 16:18:38] [D:\Personal
Files\Downloads\Software\Programming\PHP\Latest Snapshots\php-5.3-nts-
win32-VC6-x86-latest] [] >php -n -v
PHP 5.3.1-dev (cli) (built: Sep 3 2009 10:16:30)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies
[2009/09/03 16:18:40] [D:\Personal
Files\Downloads\Software\Programming\PHP\Latest Snapshots\php-5.3-nts-
win32-VC6-x86-latest] [] >php -n -r "echo passthru('php.exe -n -v');"
Warning: passthru(): Unable to fork [php.exe -v] in Command line code
on line 1
[2009/09/03 16:18:48] [D:\Personal
Files\Downloads\Software\Programming\PHP\Latest Snapshots\php-5.3-nts-
win32-VC6-x86-latest] [] >
Basically, all the latest snapshots from windows.php.net are failing
for me.
All the official releases are working for me.
Checking historical versions ...
PHP 5.3.1-dev (cli) (built: Aug 27 2009 23:21:09) Works
PHP 5.3.1-dev (cli) (built: Aug 28 2009 00:20:34) Works
PHP 5.3.1-dev (cli) (built: Aug 28 2009 01:20:31) Works
I'll get the historical updates and let you know when the failure
started.
Have you got any uncommitted code?
[2009-09-03 14:54:12] paj...@php.net
Which version do you use? It works here using vc9/x86
[2009-09-03 14:46:51] RQuadling at GMail dot com
Description:
Unable to fork. As a consequence, phpdoc/configure.php fails on windows
as it is unable to call external scripts.
Run the command below at the command prompt.
This works on PHP 5.3.0 (cli) (built: Jun 29 2009 21:44:56)
Reproduce code:
---
php -n -r "echo passthru('php.exe -v');"
Expected result:
PHP 5.3.1-dev (cli) (built: Sep 3 2009 09:58:01)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies
Actual result:
--
Warning: passthru(): Unable to fork [php.exe -v] in Command line code
on
line 1
--
Edit this bug report at http://bugs.php.net/?id=49458&edit=1
#49458 [Fbk->Asn]: passthru is unable to fork
ID: 49458
Updated by: paj...@php.net
Reported By: RQuadling at GMail dot com
-Status: Feedback
+Status: Assigned
Bug Type: Filesystem function related
Operating System: Windows XP SP3
PHP Version: 5.3SVN-2009-09-03 (SVN)
Assigned To: pajoye
New Comment:
It works on 2008/Vista/Win7 but fails on XP or 2k3. It seems that
CreateProcessAsUser is more restrictive in these versions than in newer
releass forcing us to check for ERROR_NO_TOKEN.
If the current thread is not impersonated, it has no token assigned.
Can you try this patch please? http://pastie.org/604529
Previous Comments:
[2009-09-03 15:32:16] RQuadling at GoogleMail dot com
[2009/09/03 16:18:38] [D:\Personal
Files\Downloads\Software\Programming\PHP\Latest Snapshots\php-5.3-nts-
win32-VC6-x86-latest] [] >php -n -v
PHP 5.3.1-dev (cli) (built: Sep 3 2009 10:16:30)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies
[2009/09/03 16:18:40] [D:\Personal
Files\Downloads\Software\Programming\PHP\Latest Snapshots\php-5.3-nts-
win32-VC6-x86-latest] [] >php -n -r "echo passthru('php.exe -n -v');"
Warning: passthru(): Unable to fork [php.exe -v] in Command line code
on line 1
[2009/09/03 16:18:48] [D:\Personal
Files\Downloads\Software\Programming\PHP\Latest Snapshots\php-5.3-nts-
win32-VC6-x86-latest] [] >
Basically, all the latest snapshots from windows.php.net are failing
for me.
All the official releases are working for me.
Checking historical versions ...
PHP 5.3.1-dev (cli) (built: Aug 27 2009 23:21:09) Works
PHP 5.3.1-dev (cli) (built: Aug 28 2009 00:20:34) Works
PHP 5.3.1-dev (cli) (built: Aug 28 2009 01:20:31) Works
I'll get the historical updates and let you know when the failure
started.
Have you got any uncommitted code?
[2009-09-03 15:31:54] RQuadling at GMail dot com
[2009/09/03 16:18:38] [D:\Personal
Files\Downloads\Software\Programming\PHP\Latest Snapshots\php-5.3-nts-
win32-VC6-x86-latest] [] >php -n -v
PHP 5.3.1-dev (cli) (built: Sep 3 2009 10:16:30)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies
[2009/09/03 16:18:40] [D:\Personal
Files\Downloads\Software\Programming\PHP\Latest Snapshots\php-5.3-nts-
win32-VC6-x86-latest] [] >php -n -r "echo passthru('php.exe -n -v');"
Warning: passthru(): Unable to fork [php.exe -v] in Command line code
on line 1
[2009/09/03 16:18:48] [D:\Personal
Files\Downloads\Software\Programming\PHP\Latest Snapshots\php-5.3-nts-
win32-VC6-x86-latest] [] >
Basically, all the latest snapshots from windows.php.net are failing
for me.
All the official releases are working for me.
Checking historical versions ...
PHP 5.3.1-dev (cli) (built: Aug 27 2009 23:21:09) Works
PHP 5.3.1-dev (cli) (built: Aug 28 2009 00:20:34) Works
PHP 5.3.1-dev (cli) (built: Aug 28 2009 01:20:31) Works
I'll get the historical updates and let you know when the failure
started.
Have you got any uncommitted code?
[2009-09-03 14:54:12] paj...@php.net
Which version do you use? It works here using vc9/x86
[2009-09-03 14:46:51] RQuadling at GMail dot com
Description:
Unable to fork. As a consequence, phpdoc/configure.php fails on windows
as it is unable to call external scripts.
Run the command below at the command prompt.
This works on PHP 5.3.0 (cli) (built: Jun 29 2009 21:44:56)
Reproduce code:
---
php -n -r "echo passthru('php.exe -v');"
Expected result:
PHP 5.3.1-dev (cli) (built: Sep 3 2009 09:58:01)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies
Actual result:
--
Warning: passthru(): Unable to fork [php.exe -v] in Command line code
on
line 1
--
Edit this bug report at http://bugs.php.net/?id=49458&edit=1
#49458 [Asn->Fbk]: passthru is unable to fork
ID: 49458
Updated by: paj...@php.net
Reported By: RQuadling at GMail dot com
-Status: Assigned
+Status: Feedback
Bug Type: Filesystem function related
Operating System: Windows XP SP3
PHP Version: 5.3SVN-2009-09-03 (SVN)
Assigned To: pajoye
Previous Comments:
[2009-09-03 15:34:56] paj...@php.net
It works on 2008/Vista/Win7 but fails on XP or 2k3. It seems that
CreateProcessAsUser is more restrictive in these versions than in newer
releass forcing us to check for ERROR_NO_TOKEN.
If the current thread is not impersonated, it has no token assigned.
Can you try this patch please? http://pastie.org/604529
[2009-09-03 15:32:16] RQuadling at GoogleMail dot com
[2009/09/03 16:18:38] [D:\Personal
Files\Downloads\Software\Programming\PHP\Latest Snapshots\php-5.3-nts-
win32-VC6-x86-latest] [] >php -n -v
PHP 5.3.1-dev (cli) (built: Sep 3 2009 10:16:30)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies
[2009/09/03 16:18:40] [D:\Personal
Files\Downloads\Software\Programming\PHP\Latest Snapshots\php-5.3-nts-
win32-VC6-x86-latest] [] >php -n -r "echo passthru('php.exe -n -v');"
Warning: passthru(): Unable to fork [php.exe -v] in Command line code
on line 1
[2009/09/03 16:18:48] [D:\Personal
Files\Downloads\Software\Programming\PHP\Latest Snapshots\php-5.3-nts-
win32-VC6-x86-latest] [] >
Basically, all the latest snapshots from windows.php.net are failing
for me.
All the official releases are working for me.
Checking historical versions ...
PHP 5.3.1-dev (cli) (built: Aug 27 2009 23:21:09) Works
PHP 5.3.1-dev (cli) (built: Aug 28 2009 00:20:34) Works
PHP 5.3.1-dev (cli) (built: Aug 28 2009 01:20:31) Works
I'll get the historical updates and let you know when the failure
started.
Have you got any uncommitted code?
[2009-09-03 15:31:54] RQuadling at GMail dot com
[2009/09/03 16:18:38] [D:\Personal
Files\Downloads\Software\Programming\PHP\Latest Snapshots\php-5.3-nts-
win32-VC6-x86-latest] [] >php -n -v
PHP 5.3.1-dev (cli) (built: Sep 3 2009 10:16:30)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies
[2009/09/03 16:18:40] [D:\Personal
Files\Downloads\Software\Programming\PHP\Latest Snapshots\php-5.3-nts-
win32-VC6-x86-latest] [] >php -n -r "echo passthru('php.exe -n -v');"
Warning: passthru(): Unable to fork [php.exe -v] in Command line code
on line 1
[2009/09/03 16:18:48] [D:\Personal
Files\Downloads\Software\Programming\PHP\Latest Snapshots\php-5.3-nts-
win32-VC6-x86-latest] [] >
Basically, all the latest snapshots from windows.php.net are failing
for me.
All the official releases are working for me.
Checking historical versions ...
PHP 5.3.1-dev (cli) (built: Aug 27 2009 23:21:09) Works
PHP 5.3.1-dev (cli) (built: Aug 28 2009 00:20:34) Works
PHP 5.3.1-dev (cli) (built: Aug 28 2009 01:20:31) Works
I'll get the historical updates and let you know when the failure
started.
Have you got any uncommitted code?
[2009-09-03 14:54:12] paj...@php.net
Which version do you use? It works here using vc9/x86
[2009-09-03 14:46:51] RQuadling at GMail dot com
Description:
Unable to fork. As a consequence, phpdoc/configure.php fails on windows
as it is unable to call external scripts.
Run the command below at the command prompt.
This works on PHP 5.3.0 (cli) (built: Jun 29 2009 21:44:56)
Reproduce code:
---
php -n -r "echo passthru('php.exe -v');"
Expected result:
PHP 5.3.1-dev (cli) (built: Sep 3 2009 09:58:01)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies
Actual result:
--
Warning: passthru(): Unable to fork [php.exe -v] in Command line code
on
line 1
--
Edit this bug report at http://bugs.php.net/?id=49458&edit=1
#27051 [Com]: Impersonation with FastCGI does not EXEC process as impersonated user
ID: 27051 Comment by: benadler at gmx dot net Reported By: ghoffer at globalscape dot com Status: Feedback Bug Type: Feature/Change Request Operating System: Windows PHP Version: 4.3.4 Assigned To: pajoye New Comment: I updated to php-5.3-nts-win32-VC9-x86-latest.zip yesterday night. The impersonation problem with iis6 and fastcgi was fixed, but when starting a php-script from the command line/dosbox, I get: Warning: exec(): Unable to fork [imconvert.exe ...] in scriptname.php on line X Using exec() works fine when the scripts are called from IIS, though. The failing scripts have worked fine before updating php. I traced the execution using sysinternals process monitor, and Process Create C:\WINDOWS\system32\cmd.exe cmd.exe /c "imconvert "tif:D:/data/foo.tif[0]" "D:/data/bar.jpg"" shows SUCCESS, but it seems imconvert.exe is never started, as it doesn't show up in the trace. Process Monitor shows that the php script is running as the user who's currently logged in, but I cannot see which user is trying to start convert.exe Can I help with more info? ben. Previous Comments: [2009-09-02 01:59:18] s...@php.net Automatic comment from SVN on behalf of pajoye Revision: http://svn.php.net/viewvc/?view=revision&revision=287958 Log: - #27051, we need the thread token here, not the process [2009-09-01 22:51:47] paj...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-09-01 22:51:31] s...@php.net Automatic comment from SVN on behalf of pajoye Revision: http://svn.php.net/viewvc/?view=revision&revision=287954 Log: - #27051, create process as impersonated user [2009-08-27 22:20:39] paj...@php.net Assigned to me so it will stay in my radar. I can see the src of the bug. [2009-08-27 19:17:38] nathan at andersonsplace dot net Please note this is still occurring in PHP 5.2 branch. 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/27051 -- Edit this bug report at http://bugs.php.net/?id=27051&edit=1
#49459 [NEW]: Use of case changing functions in preg_replace produces unexpected results
From: d dot reade at readesresidential dot com
Operating system: CentOS 5.3 x86
PHP version: 5.2.10
PHP Bug Type: Unknown/Other Function
Bug description: Use of case changing functions in preg_replace produces
unexpected results
Description:
Trying to use preg_replace to change text to uppercase in-between
. However expected result doesn't occur and the text remains
lowercase. No errors are logged. However adding some text after $1 outputs
this text in uppercase, but the text in-between remains as
lowercase.
Reproduce code:
---
my string';
$text = preg_replace('/\(.*)\/', strtoupper('$1'), $text);
echo $text.'';
# Test 2: Add something after $1 which produces expected output
$text = 'this is my string';
$text = preg_replace('/\(.*)\/', strtoupper('$1 cool'),
$text);
echo $text;
?>
Expected result:
# Expected result for test 1
this is MY string
# Expected result for test 2
this is MY COOL string
Actual result:
--
# Actual result for test 1
this is my string
# Actual result for test 2
this is my COOL string
--
Edit bug report at http://bugs.php.net/?id=49459&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49459&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49459&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49459&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49459&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49459&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49459&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49459&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49459&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49459&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49459&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49459&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49459&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49459&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49459&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49459&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49459&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49459&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49459&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49459&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49459&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49459&r=mysqlcfg
#46534 [Opn]: Incorrect usage of SI-prefixes by PHP
ID: 46534 User updated by: alexanderpas at yahoo dot co dot uk Reported By: alexanderpas at yahoo dot co dot uk Status: Open Bug Type: Feature/Change Request Operating System: * -PHP Version: 5.3.0alpha2 +PHP Version: 6 New Comment: Note that even Mac OS X v10.6 is using 1000 bytes per kilobyte. (http://support.apple.com/kb/TS2419) Linux is using it for years already (units(8) manual page) The only operating system still using 1024 for kilo is Microsoft Windows I suggest we use the proper and full kilobyte and kibibyte definitions as soon as possible! Previous Comments: [2009-04-24 00:47:59] kriceslo at gmail dot com This needs to be addressed. We, in the IT field, need to start using the correct units--now standardized and accepted BY LAW in some countries. Great job alexanderpas! [2008-11-10 14:00:16] alexanderpas at yahoo dot co dot uk proper table... decimal value binary valuedifference 1000^1 = 10^3 1024^1 = 2^10 2.4% 1000^2 = 10^6 1024^2 = 2^20 4.9% 1000^3 = 10^9 1024^3 = 2^30 7.4% 1000^4 = 10^12 1024^4 = 2^40 10.0% 1000^5 = 10^15 1024^5 = 2^50 12.6% 1000^6 = 10^18 1024^6 = 2^60 15.3% 1000^7 = 10^21 1024^7 = 2^70 18.1% 1000^8 = 10^24 1024^8 = 2^80 20.9% [2008-11-10 11:12:13] alexanderpas at yahoo dot co dot uk Description: PHP is handling kilo and other SI prefixes as multiples of 1024. The SI prefixes should only be used in the decimal sense: kilobyte and megabyte denote one thousand bytes and one million bytes respectively, while kibibyte and mebibyte denote 1024 bytes and 1,048,576 bytes respectively. This recommendation has been adopted by SI, IEEE, CIPM, NIST, ISO/IEC and some other leading national and international standards, which now state that the prefixes k, M and G should always refer to powers of ten, even in the context of information technology. (reference: ISO/IEC IEC 8-13:2008 ) reduced timeline: 1998: IEC introduces unambigous prefixes for binary multiples (KiB, MiB, GiB etc.), reserving kB, MB, GB and so on for their decimal sense. 2005: IEC prefixes are adopted by the IEEE after a two-year trial period. 2008: NIST guidelines require use of IEC prefixes KiB, MiB ... (and not kB, MB) for binary byte multiples “The names and symbols for the prefixes corresponding to 2 10 , 2 20 , 2 30 , 2 40 , 2 50 , and 2 60 are, respectively: kibi, Ki; mebi, Mi; gibi, Gi; tebi, Ti; pebi, Pi; and exbi, Ei. Thus, for example, one kibibyte would be written: 1 KiB = 2 10 B = 1024 B, where B denotes a byte. Although these prefixes are not part of the SI, they should be used in the field of information technology to avoid the incorrect usage of the SI prefixes.” also remember this: decimal value binary valuedifference 10001 = 103 10241 = 210 2.4% 10002 = 106 10242 = 220 4.9% 10003 = 109 10243 = 230 7.4% 10004 = 101210244 = 240 10.0% 10005 = 101510245 = 250 12.6% 10006 = 101810246 = 260 15.3% 10007 = 102110247 = 270 18.1% 10008 = 102410248 = 280 20.9% also, this has a usability impact, since using the same wording with two different meanings is JUST PLAIN WRONG, and should end RIGHT NOW, Regular users don't know that the units have dual meanings, and we shouldn't continue confusing them in this way. also "man 7 units" on your linux-box ;) (please put in correct category!) Reproduce code: --- http://bugs.php.net/?id=46534&edit=1
#46534 [Opn]: Incorrect usage of SI-prefixes by PHP
ID: 46534 User updated by: alexanderpas at yahoo dot co dot uk Reported By: alexanderpas at yahoo dot co dot uk Status: Open Bug Type: Feature/Change Request Operating System: * PHP Version: 6 New Comment: units(7) manual page ofcourse Previous Comments: [2009-09-03 16:07:17] alexanderpas at yahoo dot co dot uk Note that even Mac OS X v10.6 is using 1000 bytes per kilobyte. (http://support.apple.com/kb/TS2419) Linux is using it for years already (units(8) manual page) The only operating system still using 1024 for kilo is Microsoft Windows I suggest we use the proper and full kilobyte and kibibyte definitions as soon as possible! [2009-04-24 00:47:59] kriceslo at gmail dot com This needs to be addressed. We, in the IT field, need to start using the correct units--now standardized and accepted BY LAW in some countries. Great job alexanderpas! [2008-11-10 14:00:16] alexanderpas at yahoo dot co dot uk proper table... decimal value binary valuedifference 1000^1 = 10^3 1024^1 = 2^10 2.4% 1000^2 = 10^6 1024^2 = 2^20 4.9% 1000^3 = 10^9 1024^3 = 2^30 7.4% 1000^4 = 10^12 1024^4 = 2^40 10.0% 1000^5 = 10^15 1024^5 = 2^50 12.6% 1000^6 = 10^18 1024^6 = 2^60 15.3% 1000^7 = 10^21 1024^7 = 2^70 18.1% 1000^8 = 10^24 1024^8 = 2^80 20.9% [2008-11-10 11:12:13] alexanderpas at yahoo dot co dot uk Description: PHP is handling kilo and other SI prefixes as multiples of 1024. The SI prefixes should only be used in the decimal sense: kilobyte and megabyte denote one thousand bytes and one million bytes respectively, while kibibyte and mebibyte denote 1024 bytes and 1,048,576 bytes respectively. This recommendation has been adopted by SI, IEEE, CIPM, NIST, ISO/IEC and some other leading national and international standards, which now state that the prefixes k, M and G should always refer to powers of ten, even in the context of information technology. (reference: ISO/IEC IEC 8-13:2008 ) reduced timeline: 1998: IEC introduces unambigous prefixes for binary multiples (KiB, MiB, GiB etc.), reserving kB, MB, GB and so on for their decimal sense. 2005: IEC prefixes are adopted by the IEEE after a two-year trial period. 2008: NIST guidelines require use of IEC prefixes KiB, MiB ... (and not kB, MB) for binary byte multiples “The names and symbols for the prefixes corresponding to 2 10 , 2 20 , 2 30 , 2 40 , 2 50 , and 2 60 are, respectively: kibi, Ki; mebi, Mi; gibi, Gi; tebi, Ti; pebi, Pi; and exbi, Ei. Thus, for example, one kibibyte would be written: 1 KiB = 2 10 B = 1024 B, where B denotes a byte. Although these prefixes are not part of the SI, they should be used in the field of information technology to avoid the incorrect usage of the SI prefixes.” also remember this: decimal value binary valuedifference 10001 = 103 10241 = 210 2.4% 10002 = 106 10242 = 220 4.9% 10003 = 109 10243 = 230 7.4% 10004 = 101210244 = 240 10.0% 10005 = 101510245 = 250 12.6% 10006 = 101810246 = 260 15.3% 10007 = 102110247 = 270 18.1% 10008 = 102410248 = 280 20.9% also, this has a usability impact, since using the same wording with two different meanings is JUST PLAIN WRONG, and should end RIGHT NOW, Regular users don't know that the units have dual meanings, and we shouldn't continue confusing them in this way. also "man 7 units" on your linux-box ;) (please put in correct category!) Reproduce code: --- http://bugs.php.net/?id=46534&edit=1
#49383 [Ana]: Lots of empty fstat() calls slow performance
ID: 49383 Updated by: ras...@php.net Reported By: olga at metacafe dot com Status: Analyzed Bug Type: Performance problem Operating System: Red Hat 3.4.6-10 PHP Version: 5.3, 6 New Comment: The only time this code is executed if you are running APC is if the script is not cached. So, either your APC setup is not working, you are constantly trashing your cache (check apc.php and look at the cache-full counter), or something else weird is going on. These fstats are coming from compiler which reads the script from disk and compiles it down to opcodes. It is impossible for this code to execute on an APC-cached script because we point the executor directly at the already compiled opcodes in shared memory. Previous Comments: [2009-09-03 15:06:28] olga at metacafe dot com Thanks for the quick response. We do work with APC. I tested the new PHP without APC also, to make sure the fstat() calls aren't caused by it. But the statistics I sent to you are from web server that works with APC. You can also see from my first submission that in 5.2.9 fstat() doesn't take much time. [2009-09-03 14:24:14] ras...@php.net Still surprised these fstats take that long on your system. Note also that if you install APC, they completely go away. If you are down to caring about performance at the syscall level like that and you are not running a decent opcode cache, you are kind of confused. Here is a backtrace of those 3 fstats: #1 0x0137642f in do_fstat () #2 0x0137768f in _php_stream_fopen () #3 0x013719ba in _php_stream_open_wrapper_ex () #4 0x0135a1a3 in php_stream_open_for_zend_ex () #5 0x0135a2e0 in php_stream_open_for_zend () #6 0x013ca05f in zend_stream_fixup () #7 0x01383ae7 in open_file_for_scanning () #8 0x01383c8d in compile_file () #9 0x011eb8f7 in phar_compile_file () #10 0x013b4fa7 in zend_execute_scripts () #11 0x0135be38 in php_execute_script () #1 0x0137642f in do_fstat () #2 0x01376ee1 in php_stdiop_stat () #3 0x0135a148 in php_zend_stream_fsizer () #4 0x0135a206 in php_stream_open_for_zend_ex () #5 0x0135a2e0 in php_stream_open_for_zend () #6 0x013ca05f in zend_stream_fixup () #7 0x01383ae7 in open_file_for_scanning () #8 0x01383c8d in compile_file () #9 0x011eb8f7 in phar_compile_file () #10 0x013b4fa7 in zend_execute_scripts () #11 0x0135be38 in php_execute_script () #1 0x0137642f in do_fstat () #2 0x01377189 in php_stdiop_set_option () #3 0x0136fc8e in _php_stream_set_option () #4 0x0137dcec in _php_stream_mmap_range () #5 0x0135a295 in php_stream_open_for_zend_ex () #6 0x0135a2e0 in php_stream_open_for_zend () #7 0x013ca05f in zend_stream_fixup () #8 0x01383ae7 in open_file_for_scanning () #9 0x01383c8d in compile_file () #10 0x011eb8f7 in phar_compile_file () #11 0x013b4fa7 in zend_execute_scripts () #12 0x0135be38 in php_execute_script () The do_fstat() function has a cache, but those 3 calls set the 'force' flag to ignore the cached stat struct. We need to track down whether it is possible to not force these. It seems like it should be possible to get rid of at least one of those, if not 2. But again, install an opcode cache, and this stops being a problem. [2009-09-03 12:59:44] olga at metacafe dot com Turning all messages on/off didn't change the behavior. We tend eliminate the notices on the development stage. Can you please look at the system calls summary below? fstat() takes 25% of the total time. This doesn't happen in PHP 5.2.9. % time seconds usecs/call callserrors syscall -- --- --- - - 24.85 33.820248 256131908 fstat 13.54 18.431644 263 7000266 lstat 9.81 13.346466 259 51520 mmap 9.72 13.223388 258 51175 munmap 9.39 12.775102 264 48450 192 stat 8.83 12.014341 265 4538310 open 8.72 11.866944 257 46154 close 3.474.724639 255 18530 396 read 3.264.430927 256 17297 lseek 1.882.557480 244 10477 poll 1.592.170520 261 8326 recvfrom 1.522.073135 259 7994 sendto ... -- --- --- - - 100.00 136.108580526555 1324 total In 5.2.9 fstat() takes about 8% of total time. [2009-09-01 18:27:31] ras...@php.net You need to do proper profiling to determine that. Start by turning on all warning messages. If you are throwing warnings or notices, even if you are not displaying
#49458 [Com]: passthru is unable to fork
ID: 49458
Comment by: raulsalitrero at gmail dot com
Reported By: RQuadling at GMail dot com
Status: Feedback
Bug Type: Filesystem function related
Operating System: Windows XP SP3
PHP Version: 5.3SVN-2009-09-03 (SVN)
Assigned To: pajoye
New Comment:
i have just tested the patch and it seems to work, the output i get
is:
on windows xp sp3 (all patches)
C:\php>php -n -r "echo passthru('php.exe -n -v');"
PHP 5.3.1-dev (cli) (built: Sep 3 2009 10:04:34)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies
before the patch, it fails just like the report using svn version up to
date.
Previous Comments:
[2009-09-03 15:34:56] paj...@php.net
It works on 2008/Vista/Win7 but fails on XP or 2k3. It seems that
CreateProcessAsUser is more restrictive in these versions than in newer
releass forcing us to check for ERROR_NO_TOKEN.
If the current thread is not impersonated, it has no token assigned.
Can you try this patch please? http://pastie.org/604529
[2009-09-03 15:32:16] RQuadling at GoogleMail dot com
[2009/09/03 16:18:38] [D:\Personal
Files\Downloads\Software\Programming\PHP\Latest Snapshots\php-5.3-nts-
win32-VC6-x86-latest] [] >php -n -v
PHP 5.3.1-dev (cli) (built: Sep 3 2009 10:16:30)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies
[2009/09/03 16:18:40] [D:\Personal
Files\Downloads\Software\Programming\PHP\Latest Snapshots\php-5.3-nts-
win32-VC6-x86-latest] [] >php -n -r "echo passthru('php.exe -n -v');"
Warning: passthru(): Unable to fork [php.exe -v] in Command line code
on line 1
[2009/09/03 16:18:48] [D:\Personal
Files\Downloads\Software\Programming\PHP\Latest Snapshots\php-5.3-nts-
win32-VC6-x86-latest] [] >
Basically, all the latest snapshots from windows.php.net are failing
for me.
All the official releases are working for me.
Checking historical versions ...
PHP 5.3.1-dev (cli) (built: Aug 27 2009 23:21:09) Works
PHP 5.3.1-dev (cli) (built: Aug 28 2009 00:20:34) Works
PHP 5.3.1-dev (cli) (built: Aug 28 2009 01:20:31) Works
I'll get the historical updates and let you know when the failure
started.
Have you got any uncommitted code?
[2009-09-03 15:31:54] RQuadling at GMail dot com
[2009/09/03 16:18:38] [D:\Personal
Files\Downloads\Software\Programming\PHP\Latest Snapshots\php-5.3-nts-
win32-VC6-x86-latest] [] >php -n -v
PHP 5.3.1-dev (cli) (built: Sep 3 2009 10:16:30)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies
[2009/09/03 16:18:40] [D:\Personal
Files\Downloads\Software\Programming\PHP\Latest Snapshots\php-5.3-nts-
win32-VC6-x86-latest] [] >php -n -r "echo passthru('php.exe -n -v');"
Warning: passthru(): Unable to fork [php.exe -v] in Command line code
on line 1
[2009/09/03 16:18:48] [D:\Personal
Files\Downloads\Software\Programming\PHP\Latest Snapshots\php-5.3-nts-
win32-VC6-x86-latest] [] >
Basically, all the latest snapshots from windows.php.net are failing
for me.
All the official releases are working for me.
Checking historical versions ...
PHP 5.3.1-dev (cli) (built: Aug 27 2009 23:21:09) Works
PHP 5.3.1-dev (cli) (built: Aug 28 2009 00:20:34) Works
PHP 5.3.1-dev (cli) (built: Aug 28 2009 01:20:31) Works
I'll get the historical updates and let you know when the failure
started.
Have you got any uncommitted code?
[2009-09-03 14:54:12] paj...@php.net
Which version do you use? It works here using vc9/x86
[2009-09-03 14:46:51] RQuadling at GMail dot com
Description:
Unable to fork. As a consequence, phpdoc/configure.php fails on windows
as it is unable to call external scripts.
Run the command below at the command prompt.
This works on PHP 5.3.0 (cli) (built: Jun 29 2009 21:44:56)
Reproduce code:
---
php -n -r "echo passthru('php.exe -v');"
Expected result:
PHP 5.3.1-dev (cli) (built: Sep 3 2009 09:58:01)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies
Actual result:
--
Warning: passthru(): Unable to fork [php.exe -v] in Command line code
on
line 1
--
Edit this bug report at http://bugs.php.net/?id=49458&edit=1
#49458 [Fbk->Bgs]: passthru is unable to fork
ID: 49458
Updated by: paj...@php.net
Reported By: RQuadling at GMail dot com
-Status: Feedback
+Status: Bogus
Bug Type: Filesystem function related
Operating System: Windows XP SP3
PHP Version: 5.3SVN-2009-09-03 (SVN)
Assigned To: pajoye
New Comment:
As this bug is the result of the 1st fix for #27051, I like to continue
to follow it there instead, less confusion.
A commit has been done using the patch pasted here in my previous
comment, using #27051 as reference.
Mark as bogus/duplicate.
Previous Comments:
[2009-09-03 17:27:59] raulsalitrero at gmail dot com
i have just tested the patch and it seems to work, the output i get
is:
on windows xp sp3 (all patches)
C:\php>php -n -r "echo passthru('php.exe -n -v');"
PHP 5.3.1-dev (cli) (built: Sep 3 2009 10:04:34)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies
before the patch, it fails just like the report using svn version up to
date.
[2009-09-03 15:34:56] paj...@php.net
It works on 2008/Vista/Win7 but fails on XP or 2k3. It seems that
CreateProcessAsUser is more restrictive in these versions than in newer
releass forcing us to check for ERROR_NO_TOKEN.
If the current thread is not impersonated, it has no token assigned.
Can you try this patch please? http://pastie.org/604529
[2009-09-03 15:32:16] RQuadling at GoogleMail dot com
[2009/09/03 16:18:38] [D:\Personal
Files\Downloads\Software\Programming\PHP\Latest Snapshots\php-5.3-nts-
win32-VC6-x86-latest] [] >php -n -v
PHP 5.3.1-dev (cli) (built: Sep 3 2009 10:16:30)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies
[2009/09/03 16:18:40] [D:\Personal
Files\Downloads\Software\Programming\PHP\Latest Snapshots\php-5.3-nts-
win32-VC6-x86-latest] [] >php -n -r "echo passthru('php.exe -n -v');"
Warning: passthru(): Unable to fork [php.exe -v] in Command line code
on line 1
[2009/09/03 16:18:48] [D:\Personal
Files\Downloads\Software\Programming\PHP\Latest Snapshots\php-5.3-nts-
win32-VC6-x86-latest] [] >
Basically, all the latest snapshots from windows.php.net are failing
for me.
All the official releases are working for me.
Checking historical versions ...
PHP 5.3.1-dev (cli) (built: Aug 27 2009 23:21:09) Works
PHP 5.3.1-dev (cli) (built: Aug 28 2009 00:20:34) Works
PHP 5.3.1-dev (cli) (built: Aug 28 2009 01:20:31) Works
I'll get the historical updates and let you know when the failure
started.
Have you got any uncommitted code?
[2009-09-03 15:31:54] RQuadling at GMail dot com
[2009/09/03 16:18:38] [D:\Personal
Files\Downloads\Software\Programming\PHP\Latest Snapshots\php-5.3-nts-
win32-VC6-x86-latest] [] >php -n -v
PHP 5.3.1-dev (cli) (built: Sep 3 2009 10:16:30)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies
[2009/09/03 16:18:40] [D:\Personal
Files\Downloads\Software\Programming\PHP\Latest Snapshots\php-5.3-nts-
win32-VC6-x86-latest] [] >php -n -r "echo passthru('php.exe -n -v');"
Warning: passthru(): Unable to fork [php.exe -v] in Command line code
on line 1
[2009/09/03 16:18:48] [D:\Personal
Files\Downloads\Software\Programming\PHP\Latest Snapshots\php-5.3-nts-
win32-VC6-x86-latest] [] >
Basically, all the latest snapshots from windows.php.net are failing
for me.
All the official releases are working for me.
Checking historical versions ...
PHP 5.3.1-dev (cli) (built: Aug 27 2009 23:21:09) Works
PHP 5.3.1-dev (cli) (built: Aug 28 2009 00:20:34) Works
PHP 5.3.1-dev (cli) (built: Aug 28 2009 01:20:31) Works
I'll get the historical updates and let you know when the failure
started.
Have you got any uncommitted code?
[2009-09-03 14:54:12] paj...@php.net
Which version do you use? It works here using vc9/x86
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/49458
--
Edit this bug report at http://bugs.php.net/?id=49458&edit=1
#49458 [Bgs]: passthru is unable to fork
ID: 49458
Updated by: paj...@php.net
Reported By: RQuadling at GMail dot com
Status: Bogus
Bug Type: Filesystem function related
Operating System: Windows XP SP3
PHP Version: 5.3SVN-2009-09-03 (SVN)
Assigned To: pajoye
New Comment:
As this bug is the result of the 1st fix for #27051, I like to continue
to follow it there instead, less confusion.
A commit has been done using the patch pasted here in my previous
comment, using #27051 as reference.
Mark as bogus/duplicate.
Previous Comments:
[2009-09-03 19:18:37] paj...@php.net
As this bug is the result of the 1st fix for #27051, I like to continue
to follow it there instead, less confusion.
A commit has been done using the patch pasted here in my previous
comment, using #27051 as reference.
Mark as bogus/duplicate.
[2009-09-03 17:27:59] raulsalitrero at gmail dot com
i have just tested the patch and it seems to work, the output i get
is:
on windows xp sp3 (all patches)
C:\php>php -n -r "echo passthru('php.exe -n -v');"
PHP 5.3.1-dev (cli) (built: Sep 3 2009 10:04:34)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies
before the patch, it fails just like the report using svn version up to
date.
[2009-09-03 15:34:56] paj...@php.net
It works on 2008/Vista/Win7 but fails on XP or 2k3. It seems that
CreateProcessAsUser is more restrictive in these versions than in newer
releass forcing us to check for ERROR_NO_TOKEN.
If the current thread is not impersonated, it has no token assigned.
Can you try this patch please? http://pastie.org/604529
[2009-09-03 15:32:16] RQuadling at GoogleMail dot com
[2009/09/03 16:18:38] [D:\Personal
Files\Downloads\Software\Programming\PHP\Latest Snapshots\php-5.3-nts-
win32-VC6-x86-latest] [] >php -n -v
PHP 5.3.1-dev (cli) (built: Sep 3 2009 10:16:30)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies
[2009/09/03 16:18:40] [D:\Personal
Files\Downloads\Software\Programming\PHP\Latest Snapshots\php-5.3-nts-
win32-VC6-x86-latest] [] >php -n -r "echo passthru('php.exe -n -v');"
Warning: passthru(): Unable to fork [php.exe -v] in Command line code
on line 1
[2009/09/03 16:18:48] [D:\Personal
Files\Downloads\Software\Programming\PHP\Latest Snapshots\php-5.3-nts-
win32-VC6-x86-latest] [] >
Basically, all the latest snapshots from windows.php.net are failing
for me.
All the official releases are working for me.
Checking historical versions ...
PHP 5.3.1-dev (cli) (built: Aug 27 2009 23:21:09) Works
PHP 5.3.1-dev (cli) (built: Aug 28 2009 00:20:34) Works
PHP 5.3.1-dev (cli) (built: Aug 28 2009 01:20:31) Works
I'll get the historical updates and let you know when the failure
started.
Have you got any uncommitted code?
[2009-09-03 15:31:54] RQuadling at GMail dot com
[2009/09/03 16:18:38] [D:\Personal
Files\Downloads\Software\Programming\PHP\Latest Snapshots\php-5.3-nts-
win32-VC6-x86-latest] [] >php -n -v
PHP 5.3.1-dev (cli) (built: Sep 3 2009 10:16:30)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies
[2009/09/03 16:18:40] [D:\Personal
Files\Downloads\Software\Programming\PHP\Latest Snapshots\php-5.3-nts-
win32-VC6-x86-latest] [] >php -n -r "echo passthru('php.exe -n -v');"
Warning: passthru(): Unable to fork [php.exe -v] in Command line code
on line 1
[2009/09/03 16:18:48] [D:\Personal
Files\Downloads\Software\Programming\PHP\Latest Snapshots\php-5.3-nts-
win32-VC6-x86-latest] [] >
Basically, all the latest snapshots from windows.php.net are failing
for me.
All the official releases are working for me.
Checking historical versions ...
PHP 5.3.1-dev (cli) (built: Aug 27 2009 23:21:09) Works
PHP 5.3.1-dev (cli) (built: Aug 28 2009 00:20:34) Works
PHP 5.3.1-dev (cli) (built: Aug 28 2009 01:20:31) Works
I'll get the historical updates and let you know when the failure
started.
Have you got any uncommitted code?
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/49458
--
Edit this bug report at http://bugs.php.net/?id=49458&edit=1
#49461 [NEW]: parse_ini_file: semicolon in section header
From: sebastian dot schleussner at angstrom dot uu dot se
Operating system: Linux
PHP version: 5.3.0
PHP Bug Type: Feature/Change Request
Bug description: parse_ini_file: semicolon in section header
Description:
This is a follow-up to Bug #49443.
The character breaking parse_ini_file of PHP 5.3.0 with browscap.ini is
actually the comment character ";" inside section headers - not one of the
special characters.
Reproduce code:
---
;sample1.ini
; demonstration of what works in 5.2 and 5.3
[a(b){c}&~![^]
x=y
;sample2.ini
; demonstration of the problem
[a;b];c
x=y
Code:
-
Expected result:
As in PHP 5.2.10 -- the header's square brackets being interpreted as
quoting:
Array
(
[a(b){c}&~![^] => Array
(
[x] => y
)
)
Array
(
[a;b] => Array
(
[x] => y
)
)
Actual result:
--
Array
(
[a(b){c}&~![^] => Array
(
[x] => y
)
)
PHP Warning: syntax error, unexpected $end, expecting ']' in sample2.ini
on line 1
--
Edit bug report at http://bugs.php.net/?id=49461&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49461&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49461&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49461&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49461&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49461&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49461&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49461&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49461&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49461&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49461&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49461&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49461&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49461&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49461&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49461&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49461&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49461&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49461&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49461&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49461&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49461&r=mysqlcfg
#47829 [Com]: Segmentation fault on startup with PDO Firebird compiled in
ID: 47829
Comment by: kuzvesov at list dot ru
Reported By: info at programmiernutte dot net
Status: Open
Bug Type: PDO related
Operating System: Debian Etch x86_64
PHP Version: 5.3.0RC1
New Comment:
I have this bug in the following 32-bit configuration, both using
ibase_* functions and PDO extension, php CLI.
Configuration:
uname:
FreeBSD dbserv 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun Feb 24 19:59:52
UTC 2008 r...@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC
i386
pkg_info:
firebird-client-2.0.3_2 Firebird-2 database client
firebird-server-2.0.3_2 Firebird-2 relational database (server)
php5-5.2.6_2PHP Scripting Language
php5-interbase-5.2.6_2 The interbase shared extension for php
php5-pdo-5.2.6_2The pdo shared extension for php
php5-pdo_firebird-5.2.6_2 The pdo_firebird shared extension for php
After moving to FreeBSD 7.2 amd64, php 5.2.9, the bug is still there.
Previous Comments:
[2009-05-01 07:29:53] info at programmiernutte dot net
Same thing:
localhost:~/php5.2-200905010630/sapi/cli# ./php
Segmentation fault
gdb trace:
(gdb) run
Starting program: /root/php5.2-200905010630/sapi/cli/php
warning: no loadable sections found in added symbol-file system-
supplied DSO at 0x779fe000
[Thread debugging using libthread_db enabled]
[New Thread 47269144047376 (LWP 16865)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47269144047376 (LWP 16865)]
0x0062c1aa in _zend_hash_add_or_update (ht=0xa8f740,
arKey=0x8bbb92 "firebird", nKeyLength=8, pData=0x77995060,
nDataSize=8, pDest=0x0, flag=2) at /root/php5.2-
200905010630/Zend/zend_hash.c:218
218 p = ht->arBuckets[nIndex];
(gdb) where
#0 0x0062c1aa in _zend_hash_add_or_update (ht=0xa8f740,
arKey=0x8bbb92 "firebird", nKeyLength=8,
pData=0x77995060, nDataSize=8, pDest=0x0, flag=2) at
/root/php5.2-200905010630/Zend/zend_hash.c:218
#1 0x0052718f in php_pdo_register_driver (driver=0xa661c0) at
/root/php5.2-200905010630/ext/pdo/pdo.c:184
#2 0x005311c0 in zm_startup_pdo_firebird (type=, module_number=9157530)
at /root/php5.2-200905010630/ext/pdo_firebird/pdo_firebird.c:58
#3 0x006257c3 in zend_startup_module_ex (module=0xae52d0) at
/root/php5.2-200905010630/Zend/zend_API.c:1472
#4 0x0062a995 in zend_hash_apply (ht=0xa93bc0,
apply_func=0x6256c0 )
at /root/php5.2-200905010630/Zend/zend_hash.c:673
#5 0x00623fea in zend_startup_modules () at /root/php5.2-
200905010630/Zend/zend_API.c:1519
#6 0x005deebd in php_module_startup (sf=, additional_modules=0x0, num_additional_modules=0)
at /root/php5.2-200905010630/main/main.c:1843
#7 0x006a171d in php_cli_startup (sapi_module=0x0) at
/root/php5.2-200905010630/sapi/cli/php_cli.c:386
#8 0x006a1e11 in main (argc=1, argv=0x77995688) at
/root/php5.2-200905010630/sapi/cli/php_cli.c:745
[2009-04-30 10:48:27] j...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2009-03-29 21:51:51] info at programmiernutte dot net
I did some more experimenting, and I figured that the Crash does not
occur when PDO Firebird is compiled as a shared module and loaded as
extension. PDO Extension seems to work.
[2009-03-29 16:11:42] info at programmiernutte dot net
Description:
I am getting Segmentation fault on startup, no matter if SAPI apache 2
or CLI. Same Version of PHP and same Firebird Version (2.1.1.) are
running flawlessly on my G4 Mac on Mac OS X 10.4.11, so maybe this is
64bit-related?
I used gdb to track this down to PDO Firebird Initialisation Startup:
(gdb) run
Starting program: /usr/src/php-5.3.0RC1/sapi/cli/php
Failed to read a valid object file image from memory.
[Thread debugging using libthread_db enabled]
[New Thread 47013927445712 (LWP 16824)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47013927445712 (LWP 16824)]
zend_declare_class_constant_long (ce=0x0, name=0xa6a5ef
"FB_ATTR_DATE_FORMAT", name_length=19, value=1000)
at /usr/src/php-5.3.0RC1/Zend/zend_API.c:3210
3210if (ce->type & ZEND_INTERNAL_CLASS) {
(gdb) where
#0 zend_declare_class_constant_long (ce=0x0, name=0xa6a5ef
"FB_ATTR_DATE_FORMAT", name_length=19, value=1000)
at /usr/src/php-5.3.0RC1/Zend/zend_API.c:3210
#1 0x005190c2 in zm_startup_pdo_firebird (type=, module_number=)
at /usr/src/php-5.3.0RC1/ext/pdo_firebird/pdo_firebird.c:58
#2 0x0061cfbe in zend_startup_module_ex (module=0xcafb10) at
/usr/src/php-5.3.0RC1/Zend/zend_API.c:1593
#3 0x0
#49459 [Opn->Bgs]: Use of case changing functions in preg_replace produces unexpected results
ID: 49459
Updated by: j...@php.net
Reported By: d dot reade at readesresidential dot com
-Status: Open
+Status: Bogus
-Bug Type: Unknown/Other Function
+Bug Type: PCRE related
Operating System: CentOS 5.3 x86
PHP Version: 5.2.10
New Comment:
Your forgot to RTFM:
http://www.php.net/manual/en/function.preg-replace.php
Hint: Example #4
Previous Comments:
[2009-09-03 16:00:23] d dot reade at readesresidential dot com
Description:
Trying to use preg_replace to change text to uppercase in-between
. However expected result doesn't occur and the text remains
lowercase. No errors are logged. However adding some text after $1
outputs this text in uppercase, but the text in-between remains
as lowercase.
Reproduce code:
---
my string';
$text = preg_replace('/\(.*)\/', strtoupper('$1'), $text);
echo $text.'';
# Test 2: Add something after $1 which produces expected output
$text = 'this is my string';
$text = preg_replace('/\(.*)\/', strtoupper('$1 cool'),
$text);
echo $text;
?>
Expected result:
# Expected result for test 1
this is MY string
# Expected result for test 2
this is MY COOL string
Actual result:
--
# Actual result for test 1
this is my string
# Actual result for test 2
this is my COOL string
--
Edit this bug report at http://bugs.php.net/?id=49459&edit=1
#27051 [Fbk]: Impersonation with FastCGI does not EXEC process as impersonated user
ID: 27051 Updated by: paj...@php.net Reported By: ghoffer at globalscape dot com Status: Feedback Bug Type: Feature/Change Request Operating System: Windows -PHP Version: 4.3.4 +PHP Version: 5.3 Assigned To: pajoye New Comment: Please (all :) try a snapshot, php 5.3 or 6 (5.3 recommended anyway :). Previous Comments: [2009-09-03 19:16:50] s...@php.net Automatic comment from SVN on behalf of pajoye Revision: http://svn.php.net/viewvc/?view=revision&revision=288004 Log: - #27051, improve fix on xp/2k3 [2009-09-03 19:16:17] s...@php.net Automatic comment from SVN on behalf of pajoye Revision: http://svn.php.net/viewvc/?view=revision&revision=288003 Log: - #27051, improve fix on xp/2k3 [2009-09-03 15:52:24] benadler at gmx dot net I updated to php-5.3-nts-win32-VC9-x86-latest.zip yesterday night. The impersonation problem with iis6 and fastcgi was fixed, but when starting a php-script from the command line/dosbox, I get: Warning: exec(): Unable to fork [imconvert.exe ...] in scriptname.php on line X Using exec() works fine when the scripts are called from IIS, though. The failing scripts have worked fine before updating php. I traced the execution using sysinternals process monitor, and Process Create C:\WINDOWS\system32\cmd.exe cmd.exe /c "imconvert "tif:D:/data/foo.tif[0]" "D:/data/bar.jpg"" shows SUCCESS, but it seems imconvert.exe is never started, as it doesn't show up in the trace. Process Monitor shows that the php script is running as the user who's currently logged in, but I cannot see which user is trying to start convert.exe Can I help with more info? ben. [2009-09-02 01:59:18] s...@php.net Automatic comment from SVN on behalf of pajoye Revision: http://svn.php.net/viewvc/?view=revision&revision=287958 Log: - #27051, we need the thread token here, not the process [2009-09-01 22:51:47] paj...@php.net Please try using this 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/27051 -- Edit this bug report at http://bugs.php.net/?id=27051&edit=1
#49362 [Asn]: Deprecated php.ini options warnings output even with display_errors=off
ID: 49362 Updated by: j...@php.net Reported By: tomas dot hlavacek at firma dot volny dot cz Status: Assigned Bug Type: PHP options/info functions Operating System: * PHP Version: 5.3, 6 Assigned To: kalle New Comment: For 6: change the error reporting to E_ERROR For 5.3: change them to E_DEPRECATED (and only really shown when that is set) Previous Comments: [2009-09-02 16:25:22] romanf at trash dot net Will this be fixed in 5.3? Or only in 6? -Roman [2009-08-26 11:08:41] j...@php.net Correction: E_ERROR of course. :) [2009-08-26 11:08:07] j...@php.net And in HEAD these should be E_FATAL errors. [2009-08-26 09:59:19] tomas dot hlavacek at firma dot volny dot cz Yes, true. What Error Level Constant is used for showing deprecated ini settings then? [2009-08-26 09:52:14] j...@php.net Assigning to Kalle who added these in the obviously wrong place. Deprecated ini settings checks can not happen in place where a check for removed setting is done! 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/49362 -- Edit this bug report at http://bugs.php.net/?id=49362&edit=1
#49459 [Bgs]: Use of case changing functions in preg_replace produces unexpected results
ID: 49459
User updated by: d dot reade at readesresidential dot com
Reported By: d dot reade at readesresidential dot com
Status: Bogus
Bug Type: PCRE related
Operating System: CentOS 5.3 x86
PHP Version: 5.2.10
New Comment:
Ah I see, sorry, my bad.
Previous Comments:
[2009-09-03 21:04:46] j...@php.net
Your forgot to RTFM:
http://www.php.net/manual/en/function.preg-replace.php
Hint: Example #4
[2009-09-03 16:00:23] d dot reade at readesresidential dot com
Description:
Trying to use preg_replace to change text to uppercase in-between
. However expected result doesn't occur and the text remains
lowercase. No errors are logged. However adding some text after $1
outputs this text in uppercase, but the text in-between remains
as lowercase.
Reproduce code:
---
my string';
$text = preg_replace('/\(.*)\/', strtoupper('$1'), $text);
echo $text.'';
# Test 2: Add something after $1 which produces expected output
$text = 'this is my string';
$text = preg_replace('/\(.*)\/', strtoupper('$1 cool'),
$text);
echo $text;
?>
Expected result:
# Expected result for test 1
this is MY string
# Expected result for test 2
this is MY COOL string
Actual result:
--
# Actual result for test 1
this is my string
# Actual result for test 2
this is my COOL string
--
Edit this bug report at http://bugs.php.net/?id=49459&edit=1
#49462 [NEW]: Session variables not saved after redirect, session_write_close(), die() used
From: greg dot solak at profiletwist dot com
Operating system: Linux
PHP version: 5.3.0
PHP Bug Type: Session related
Bug description: Session variables not saved after redirect,
session_write_close(), die() used
Description:
PHP SESSION variable $_SESSION['user_level'] is not saved after the page
is redirected using header(location: ...). Session_write_close()is used
right before redirect. After redirect die() is called. After a second
attempt at login, everything works!
Reproduce code:
---
// Change session properties
$_SESSION['user_level'] = 7;
// Force session to save changes before redirection
session_write_close(); // REQUIRED
// Regenerate session id for security + fix bug in which some session
variables are lost during redirect
session_regenerate_id(true);
// Redirect to Access main page
header('Location: http://www.domain.com/access/main.php');
die();
?>
Expected result:
At the new page (the one the user was redirected to) the
$SESSION['user_level'] should == 7. However, the session variable was not
saved, as the user is redirected back to the login page. After a second
attempt at logging in, everything works as expected.
Actual result:
--
Redirected back to login page, because when php checked if the user had
the proper credentials
if ($_SESSION['user_level'] != 7) {
// redirect back to login page
}
Other improtant information: session_start(); is called on every page.
--
Edit bug report at http://bugs.php.net/?id=49462&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49462&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49462&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49462&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49462&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49462&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49462&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49462&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49462&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49462&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49462&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49462&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49462&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49462&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49462&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49462&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49462&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49462&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49462&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49462&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49462&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49462&r=mysqlcfg
#48761 [Com]: php crashes on start - getaddrinfo could not be located
ID: 48761 Comment by: composer at singers dot org dot nz Reported By: aheckmann at m-s dot de Status: To be documented Bug Type: Reproducible crash Operating System: win32 only - Windows 2000 SP4 PHP Version: 5.3.0 New Comment: I run Small Business Server 2000 and need to set up PHP within IIS to support some services that I need to provide and right now am unable to do so so am "hog tied". Although only a small site being able to provide the services required for the organization is critical.. Win2K SBS has proved very stable and reliable and the owners do not wish to change.. The old adage here.. "If it ain't broke don't fix it and don't screw with it" is what they like. The current environment meets their needs perfectly and has been highly reliable. Now they wanna add an extra service that uses MYSQL and PHP. So installing PHP is critical. Therefore some fix for them is important or at least a practical workaround. So yep there are Win2K servers out there and YEP a "fix" of some sort would be good. Thanks Previous Comments: [2009-08-24 20:26:31] bruce at thinkcorporate dot com Specifically where do I obtain and include the mentioned Ws2tcpip.h and Wspiapi.h files as the "fix" to getaddrinfo on older versions of Windows? Does the PHP.exe need to be recompiled with the mentioned includes? [2009-08-14 23:40:34] bruce at thinkcorporate dot com I run IIS 6 on W2K SP4 and get the same error. I reviewed http://msdn.microsoft.com/en-us/library/ms738520%28VS.85%29.aspx How do I implement the fix? [2009-08-10 11:45:18] paj...@php.net Only 2000 and xp with SP1 (or no SP) are affected. 2003 does work as expected. By the way, I very much doubt that most servers use 2000. Set as "to be documented". [2009-07-29 23:00:21] jon dot harrell at gmail dot com Until this bug is fixed wouldn't it make sense to place a notice warning all potential users that the binary downloads at http://windows.php.net/download/ require XP SP2 or above? [2009-07-17 12:04:31] jet5y at hotmail dot co dot uk However, considering that most servers running it would either be 2000 or 2003 and not XP then a workaround would seem more sensible at the slight detriment for now of XP SP2 systems. 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/48761 -- Edit this bug report at http://bugs.php.net/?id=48761&edit=1
#48761 [Tbd]: php crashes on start - getaddrinfo could not be located
ID: 48761 Updated by: paj...@php.net Reported By: aheckmann at m-s dot de Status: To be documented Bug Type: Reproducible crash Operating System: win32 only - Windows 2000 SP4 PHP Version: 5.3.0 New Comment: PHP 5.2 works just fine in this configuration. So you can follow they lovely adage and keep using 5.2.x with the existing apps :) Previous Comments: [2009-09-03 23:09:48] composer at singers dot org dot nz I run Small Business Server 2000 and need to set up PHP within IIS to support some services that I need to provide and right now am unable to do so so am "hog tied". Although only a small site being able to provide the services required for the organization is critical.. Win2K SBS has proved very stable and reliable and the owners do not wish to change.. The old adage here.. "If it ain't broke don't fix it and don't screw with it" is what they like. The current environment meets their needs perfectly and has been highly reliable. Now they wanna add an extra service that uses MYSQL and PHP. So installing PHP is critical. Therefore some fix for them is important or at least a practical workaround. So yep there are Win2K servers out there and YEP a "fix" of some sort would be good. Thanks [2009-08-24 20:26:31] bruce at thinkcorporate dot com Specifically where do I obtain and include the mentioned Ws2tcpip.h and Wspiapi.h files as the "fix" to getaddrinfo on older versions of Windows? Does the PHP.exe need to be recompiled with the mentioned includes? [2009-08-14 23:40:34] bruce at thinkcorporate dot com I run IIS 6 on W2K SP4 and get the same error. I reviewed http://msdn.microsoft.com/en-us/library/ms738520%28VS.85%29.aspx How do I implement the fix? [2009-08-10 11:45:18] paj...@php.net Only 2000 and xp with SP1 (or no SP) are affected. 2003 does work as expected. By the way, I very much doubt that most servers use 2000. Set as "to be documented". [2009-07-29 23:00:21] jon dot harrell at gmail dot com Until this bug is fixed wouldn't it make sense to place a notice warning all potential users that the binary downloads at http://windows.php.net/download/ require XP SP2 or above? 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/48761 -- Edit this bug report at http://bugs.php.net/?id=48761&edit=1
#49436 [Fbk->Opn]: during query executed, mysql connection lost
ID: 49436
User updated by: november at netsecuretech dot com
Reported By: november at netsecuretech dot com
-Status: Feedback
+Status: Open
Bug Type: MySQLi related
Operating System: windowsXP
PHP Version: 5.3.0
New Comment:
I think this problem isn't related to mysql error.
I modifyed php.ini.
Before : default_socket_timeout = 0
After : default_socket_timeout = -1
I execute php script.
Php script was processed successed.
Default_socket_timeout influence mysqli connection?
I tested below script.
If default_socket_timeout is -1, script isn't ended.
I think mysqli connection timeout and socket timeout managed
separated.
thank you.
connect_error) {
echo "GOOD CATCH\n";
}
echo date('H:i:s ')."End script\n\n";
echo date('H:i:s ')."Start script\n";
ini_set('default_socket_timeout', -1);
echo 'max_execution_time: ' . ini_get('max_execution_time') . "\n";
echo 'default_socket_timeout: ' . ini_get('default_socket_timeout') .
"\n";
$mysqli = new mysqli('localhost', 'does', 'not', 'matter', 1);
if ($mysqli->connect_error) {
echo "GOOD CATCH\n";
}
echo date('H:i:s ')."End script\n\n";
?>
Previous Comments:
[2009-09-03 12:38:30] j...@php.net
Did you check the mysql server error log if it has any clues what
happened?
[2009-09-02 10:07:21] november at netsecuretech dot com
I installed VC9 x86 Thread Safe (2009-Sep-02 11:00:00) verion.
It is not work well.
result is below...
thank you.
C:\php\Script>..\php.exe mysqli_test.php
2009-09-02 19:03:27 => query start...
2006 MySQL server has gone away
2009-09-02 19:04:27 => query end...
C:\php\Script>
[2009-09-02 09:41:45] j...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2009-09-02 04:40:26] november at netsecuretech dot com
mysql query takes 20~30 minutes;
$query = "create table test as select c_ip, count(*) from iis_summary
group by c_ip";
thank you
[2009-09-02 04:37:23] november at netsecuretech dot com
Description:
PHP version : 5.3.0 Windows Binary VC9 x86 Thread Safe (2009-Jun-30
08:52:56)
Mysql version : 5.1.37-community-edition (CentOS 4.7)
I use php CLI SAPI.
PHP cli's default max_execution_time is unlimited.
When I execute php script, mysql connection is lost.
When I use php 5.2.10, mysql query executed well.
What Can I do?
Thank you.
Reproduce code:
---
query start...\r\n";
$query = "create table test as select c_ip, count(*) from iis_summary
group by c_ip";
mysqli_query($db, $query);
if (mysqli_errno($db) != 0) {
echo mysqli_errno($db)." ".mysqli_error($db)."\r\n";
}
echo date("Y-m-d H:i:s")." => query end...\r\n";
mysqli_close($db);
?>
Expected result:
During query, mysql connection lost.
PHP Warning: mysqli_query(): MySQL server has gone away in
C:\php\Script\mysqli
_test.php on line 14
Actual result:
--
C:\php\Script>..\php.exe mysqli_test.php
2009-09-02 13:23:15 => query start...
PHP Warning: mysqli_query(): MySQL server has gone away in
C:\php\Script\mysqli
_test.php on line 14
PHP Warning: mysqli_query(): Error reading result set's header in
C:\php\Script
\mysqli_test.php on line 14
2006 MySQL server has gone away
2009-09-02 13:24:15 => query end...
C:\php\Script>
--
Edit this bug report at http://bugs.php.net/?id=49436&edit=1
#49463 [NEW]: setAttributeNS("http://www.w3.org/2000/xmlns/","xmlns","blah") produces error
From: himajin10 at gmail dot com
Operating system: Windows XP SP3
PHP version: 6SVN-2009-09-04 (snap)
PHP Bug Type: DOM XML related
Bug description:
setAttributeNS("http://www.w3.org/2000/xmlns/","xmlns","blah";) produces error
Description:
STEPS TO REPRODUCE:
1.run the "Reproduce Code"
2.read the DOM Core spec from 'if the qualifiedName or its prefix is
"xmlns"'
http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-ElSetAttrNS
Reproduce code:
---
createElementNS('http://purl.org/rss/1.0/','rdf:RDF');
$root->setAttributeNS("http://www.w3.org/2000/xmlns/","xmlns","http://purl.org/rss/1.0/";
);
?>
Expected result:
No Error.
Actual result:
--
Fatal error: Uncaught exception 'DOMException' with message 'Namespace
Error' in C:\Environment\Users\WWW\OKWave\Q5261193\Q5261193-2.php06:5
Stack trace:
#0 C:\Environment\Users\WWW\OKWave\Q5261193\Q5261193-2.php06(5):
DOMElement->setAttributeNS('http://www.w3.o...', 'xmlns',
'http://purl.org...')
#1 {main}
thrown in C:\Environment\Users\WWW\OKWave\Q5261193\Q5261193-2.php06
on line 5
--
Edit bug report at http://bugs.php.net/?id=49463&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49463&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49463&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49463&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49463&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49463&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49463&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49463&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49463&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49463&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49463&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49463&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49463&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49463&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49463&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49463&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49463&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49463&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49463&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49463&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49463&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49463&r=mysqlcfg
#49443 [Bgs]: Special characters in section name breaks parse_ini_file
ID: 49443
Updated by: j...@php.net
Reported By: eric dot caron at gmail dot com
Status: Bogus
Bug Type: Filesystem function related
Operating System: N/A
PHP Version: 5.3.0
New Comment:
The changes were made exactly to get the browscap.ini parsing to
actually work. It did not and does not work in 5.2 properly. This will
not change.
Previous Comments:
[2009-09-02 20:02:06] eric dot caron at gmail dot com
The logic difficulty is better showcased with "false" values.
*** PHP 5.2 (GOOD) ***
array(2) {
["Ask"]=>
array(1) {
["Crawler"]=>
string(0) ""
}
["Mozilla/?.0 (compatible; Ask Jeeves/Teoma*)"]=>
array(1) {
["Crawler"]=>
string(1) "1"
}
}
*** PHP 5.3 (BAD) ***
array(2) {
["Ask"]=>
array(1) {
["Crawler"]=>
string(5) "false"
}
["Mozilla/?.0 (compatible; Ask Jeeves/Teoma*)"]=>
array(1) {
["Crawler"]=>
string(4) "true"
}
}
[2009-09-02 19:49:13] eric dot caron at gmail dot com
The raw option, though, does not convert the string "true"/"false" to
its boolean.
If you change the print_r in my demo code to a var_dump:
*** PHP 5.2 RESULTS ***
array(2) {
["Ask"]=>
array(1) {
["Crawler"]=>
string(1) "1"
}
["Mozilla/?.0 (compatible; Ask Jeeves/Teoma*)"]=>
array(1) {
["Crawler"]=>
string(1) "1"
}
}
*** PHP 5.3 RESULTS ***
array(2) {
["Ask"]=>
array(1) {
["Crawler"]=>
string(4) "true"
}
["Mozilla/?.0 (compatible; Ask Jeeves/Teoma*)"]=>
array(1) {
["Crawler"]=>
string(4) "true"
}
}
[2009-09-02 19:12:19] j...@php.net
The raw option is just for this and it's NOT a workaround but exactly
the thing you're supposed to use here. No bug here.
[2009-09-02 15:52:10] eric dot caron at gmail dot com
Description:
PHP 5.3 changes to parse_ini_*() functions breaks scripts that have
special characters, {}|&~![()^", in the section titles. (Previous
versions worked, which I assume was proper behavior because section
titles can have those characters according to community understood INI
standards).
There is no documentation stating that special characters can not be
used in section titles. While the INI_SCANNER_RAW parameter provides an
opening for a workaround for this solution, to be useful, the characters
{}|&~![()^" should be usable in section titles (not to be confuse with
keys, where they shouldn't be used).
Reproduce code:
---
Array
(
[Crawler] => 1
)
[Mozilla/?.0 (compatible; Ask Jeeves/Teoma*)] => Array
(
[Crawler] => 1
)
)
Actual result:
--
Warning: parse error, expecting `']'' in FOOFCCA.tmp on line 4 in
parseBug.php on line 10
--
Edit this bug report at http://bugs.php.net/?id=49443&edit=1
#49464 [NEW]: php_sockets build broken
From: raulsalitrero at gmail dot com Operating system: Windows Xp SP3 PHP version: 5.3SVN-2009-09-04 (SVN) PHP Bug Type: Compile Failure Bug description: php_sockets build broken Description: php_sockets.dll build is broken in win vc9, with the next error ext\sockets\sockets.c(327) : error C2491: 'php_sockets_le_socket' : definition of dllimport function not allowed tried building the last svn source with the same result. using vc9 to compile, the error is also observable in the windows sanpshots compile logs the bug was introduced in revision: 287911 - export le_socket from ext/sockets changing files: -/php/php-src/branches/PHP_5_3/ext/sockets/php_sockets.h -/php/php-src/branches/PHP_5_3/ext/sockets/sockets.c Reproduce code: --- use nmake to compile with vc9 compiler Expected result: php_sockets.dll is built Actual result: -- php_sockets.dll is missing from the result build -- Edit bug report at http://bugs.php.net/?id=49464&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49464&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49464&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49464&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49464&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49464&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49464&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49464&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49464&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49464&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49464&r=support Expected behavior: http://bugs.php.net/fix.php?id=49464&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49464&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49464&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49464&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49464&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49464&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49464&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49464&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49464&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49464&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49464&r=mysqlcfg
#42886 [Com]: openssl_x509_checkpurpose returns int(0) on valid public certificate
ID: 42886
Comment by: ryan+phpbugs at sleevi dot com
Reported By: tokul at users dot sourceforge dot net
Status: Assigned
Bug Type: OpenSSL related
Operating System: Linux Debian Etch
PHP Version: 5CVS-2008-11-01
Assigned To: pajoye
New Comment:
The problem is not resolved in PHP 5.2.6, provided you call it
correctly.
openssl_x509_checkpurpose expects to be able to build a full chain of
certificates to verify its purpose. Furthermore, it expects there to be
a trusted certificate as part of the chain.
When invoked as
var_dump(openssl_x509_checkpurpose(file_get_contents('./certfile.pem').
X509_PURPOSE_SMIME_SIGN));
this fails, because a chain cannot properly be built to a trusted
root.
My test case involved:
- Obtaining Using the Thawte intermediate and root certificates,
obtained via http://www.thawte.com/repository/index.html
- Copying the contents of the Thawte Personal Freemail Issuing CA and
Thawte Personal Freemail CA PEM files from that list into a new file,
called 'chain.pem'. The certs were simply appended one after the other
- Setting the system time to be during the validity period of the
certificate (2007-10-10 00:00:00 GMT)
- executing as
var_dump(openssl_x509_checkpurpose(file_get_contents('./certfile.pem').
X509_PURPOSE_SMIME_SIGN, array('./chain.pem'));
- I received int(1) as the result
I do not believe the reporter's initial case should be supported.
Purpose checking requires checking each of the CAs that issued the
certificate to make sure there are no purpose constraints. The absence
of the CA certificates makes this impossible, hence the failure.
If one wishes to obtain any X509 certificate extensions for a single
certificate, openssl_x509_parse is able to provide this information.
However, it should not be treated as authoritative, as it does not
reflect the full chain policy being enforced for that certificate.
My OpenSSL version was 0.9.8f, running Linux kernel 2.6.14.6 and PHP
5.2.6. While these versions do differ from the original submission, with
the above explanation, it should provide enough information to see if
this does resolve the situation with purpose verification.
Previous Comments:
[2008-11-18 10:09:50] paj...@php.net
It seems to be a bug in the openssl directly. I have tried with many
different certs and many failed (including the one available in the
openssl's demo directory).
I have to work on other things now, the fix may require to duplicate
the x509_verify_cert code (partially or completely).
tested with 0.98g and 0.9.8i
[2008-11-01 21:13:07] tokul at users dot sourceforge dot net
php 5.2-200811011530
Test result is the same. It is impossible to verify purpose of
certificate, because function returns integer value which is evaluated
as false even when certificate can be used for SMIME signatures.
I don't know options that Thawte used to generate certificate. I've
accepted default options with 2048-bit encryption for Mozilla
Firefox/Thunderbird.
Here goes already expired certificate used for initial bug report.
-BEGIN CERTIFICATE-
MIIC8DCCAlmgAwIBAgIQS8GxvbV7pghz0FD/I7rVVjANBgkqhkiG9w0BAQUFADBi
MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg
THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg
Q0EwHhcNMDcwMjI0MDYyMzA0WhcNMDgwMjI0MDYyMzA0WjBNMR8wHQYDVQQDExZU
aGF3dGUgRnJlZW1haWwgTWVtYmVyMSowKAYJKoZIhvcNAQkBFht0b2t1bEB1c2Vy
cy5zb3VyY2Vmb3JnZS5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDQALcUK5moBKz5tHqYcquqb8seEKgzDbFJ3Nko8VEyVy1vnwKtHkNeXuMv1mbH
2dhkvI2JtWpNte36bzLErQHzZhnehAdRb3RIlLrASxkn4btidkWasYjqhtMI1sGL
D+7wFdC4rSfdYwRUto8zrB5FeoNakJre8gmljqwm18fh5ZMsiWboXdKVVCa8ALBk
P5dZ7gYElfNj3FJSjqo0Efs5yQn8EsY+uDNTH+y8HE5Sqq0mkuLw/7WIO5PCsQAF
xTsEo2dqnj3us9KGgNGkR4JRp17NPfNofLs26w7H2n3oAmjMaM51U5lpPOSh0Nm7
uwrpsWnE84Jm2I/9WhhuSOEJAgMBAAGjODA2MCYGA1UdEQQfMB2BG3Rva3VsQHVz
ZXJzLnNvdXJjZWZvcmdlLm5ldDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUA
A4GBAJlmrYGSeE00IK7WR+05BT0g6YigfIoKLbeTJu25oVHN8dBLU0Jjx5KZRfZQ
BCt/8CVBNxNwwKRQnQ36M4Hq0YLa+bBYq3pJPbL62Ffj7mLHhDkFvJw/sgQ1I7jH
URvzt58Hw3B34wEHzqnzcsFOPxNZN3aU4BTnbUBTUjkVVpuZ
-END CERTIFICATE-
[2008-10-31 08:49:37] paj...@php.net
Please provide a sample certificate to reproduce this problem or the
values you used to create a similar certificate.
[2007-10-08 10:52:55] tokul at users dot sourceforge dot net
Description:
According to last chapter in openssl_x509_checkpurpose() manual
function should return true, false or int(-1). Synopsis line shows that
function returns integer.
If I check public certificate file with OpenSSL binary (openssl x509
-purpose -in certfile.pem), it shows purposes as
#49267 [Com]: Linking fails for iconv: "Undefined symbols: _libiconv"
ID: 49267 Comment by: jay3ld at yahoo dot com Reported By: s dot rost at ewerk dot com Status: Assigned Bug Type: Compile Failure Operating System: Mac OSX 10.6 Snow Leopard PHP Version: 5.3, 6 (2009-08-18) Assigned To: scottmac New Comment: Has any progress been made towards this with Snow Leopard? I am receiving the same issue with both PHP 5.3 and PHP 6. I don't get the above error. My error occurs during the configure stage. checking for iconv support... yes checking for iconv... no checking for libiconv... no checking for libiconv in -liconv... no checking for iconv in -liconv... no configure: error: Please reinstall the iconv library. I even tried to download and build a custom iconv library and pointed it with "--with-iconv-dir=/home/builds/iconv" and it still fails. Previous Comments: [2009-08-15 16:30:35] scott...@php.net I'll look at the iconv issue once I get access to the snow leopard appleseed. I'd like to investigate a proper fix for this. [2009-08-15 16:27:05] s dot rost at ewerk dot com Right, the DNS stuff works in the snapshot (php5.3-200908151430) The precise linker error for iconv is: Undefined symbols: "_libiconv", referenced from: __php_iconv_strlen in iconv.o _php_iconv_string in iconv.o _php_iconv_string in iconv.o __php_iconv_strpos in iconv.o __php_iconv_appendl in iconv.o __php_iconv_appendl in iconv.o _zif_iconv_substr in iconv.o _zif_iconv_mime_encode in iconv.o _zif_iconv_mime_encode in iconv.o _zif_iconv_mime_encode in iconv.o _zif_iconv_mime_encode in iconv.o _zif_iconv_mime_encode in iconv.o _zif_iconv_mime_encode in iconv.o _php_iconv_stream_filter_append_bucket in iconv.o _php_iconv_stream_filter_append_bucket in iconv.o ld: symbol(s) not found collect2: ld returned 1 exit status make: *** [sapi/cgi/php-cgi] Error 1 [2009-08-15 15:26:39] scott...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ The DNS functions have been fixed in SVN already. The iconv stuff I've not looked at yet. [2009-08-15 13:54:11] s dot rost at ewerk dot com ext/iconv/iconv.c has to be changed to #ifdef HAVE_LIBICONV #define iconv iconv #endif Stupid copy/paste mistake. Also that does of course not really make sense, the #define is not needed at all. so probably the configure script should not detect LIBICONV in the first place, but plain iconv. [2009-08-15 13:51:01] s dot rost at ewerk dot com Description: The linker fails to link the PHP 5.3.0 binaries on Mac OS X 10.6. For two reasons. 1. The configure Script fails to add `-lresolv` to EXTRA_LIBS and MH_BUNDLE_FLAGS in Makefile 2. ext/iconv/iconv.c has to be changed (line 185) from #ifdef HAVE_LIBICONV #define iconv libiconv #endif to #ifdef HAVE_LIBICONV #define iconv libiconv #endif Reproduce code: --- ./configure --with-iconv Expected result: `configure` and `make` work Actual result: -- Unresolved symbols when linking the binaries at the end of the `make` process. -- Edit this bug report at http://bugs.php.net/?id=49267&edit=1
#49419 [Com]: ssl:// wrapper - cannot verify VeriSign certificate chain
ID: 49419 Comment by: ryan+phpbugs at sleevi dot com Reported By: Jacek at jacekk dot info Status: Open Bug Type: OpenSSL related Operating System: Ubuntu PHP Version: 5.3.0 New Comment: I was unable to reproduce the "good" OpenSSL output that you described, using OpenSSL FIPS 1.2. For documentation sake (and because everything I'm about to explain is relative to that, which is equivalent to 0.9.8f code more or less), what version have you linked against with your PHP? Running openssl s_client -connect www.verisign.com:443 -CAfile chain.pem I get CONNECTED(0003) depth=3 /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority verify error:num=19:self signed certificate in certificate chain verify return:0 --- Certificate chain 0 s:/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Delaware/2.5.4.15=V1.0, Clause 5.(b)/serialNumber=2497886/C=US/postalCode=94043/ST=California/L=Mountain View/streetAddress=487 East Middlefield Road/O=VeriSign, Inc./OU=Production Security Services/CN=www.verisign.com i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL SGC CA 1 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL SGC CA i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 2 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority 3 s:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority --- Using the chain file at http://pastebin.com/f16f72c6e and I am able to use the code without the issues you describe (There is an HTTP 500 error with the PayPal site, but that demonstrates the connection is successful). The certificate in this file corresponds to the last certificate in the chain as supplied by both Verisign and Paypal. The explanation of "why" this works follows, and is based on the 0.9.8/OpenSSL FIPS Module 1.2 code. While I cannot be certain that this explanation fully explains your problem, based on those missing pieces of information, it may shed light on the issues and limitations of the 'cafile' and 'capath' arguments. I do not believe that what you want to work will work the way you've described, which is due to OpenSSL limitations. In the chain file you provided, the two certificates you provided are: subject= /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 issuer= /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 and subject= /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL CA issuer= /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 The first certificate in the supplied chain file corresponds to being the issuer of the certificate at index 1 in the above output from OpenSSL. Thus, one would expect the chain to go from index 0 (www.verisign.com) -> index 1 (EV SSL SGC CA) -> chain file 0 (Public Primary CA - G5). As chain file 0 is both a self-signed certificate and in the trusted list, one would presume the connection is now trusted/verified. However, OpenSSL's verify code is set to respect the ordering supplied by the remote server over the preference of a chain file when used for certificate path building. The untrusted list of certs receives precedence when building the chain, with the capath, cafile, and any other lookups only being consulted to complete any missing parts of the chain. This can be found in the OpenSSL sources in crypto/x509/x509_vfy.c X509_verify_cert. The comment in the code states "if we were passed a cert chain, use it first", in reference to the 'untrusted' chain. The Verisign server, above, is supplying a chain that actually terminates at "Class 3 Public Primary Certification Authority" (Index 3) This is the certificate that would need to be contained in chain.pem for verification to happen properly, as this is the certificate that OpenSSL (ergo, by proxy, PHP) expects to find in the trusted store (created by the cafile/capath options). If the Verisign server were instead supplying the (intermediate) certificate "CN=VeriSign Class 3 Public Primary
#42886 [Asn->Bgs]: openssl_x509_checkpurpose returns int(0) on valid public certificate
ID: 42886
Updated by: paj...@php.net
Reported By: tokul at users dot sourceforge dot net
-Status: Assigned
+Status: Bogus
Bug Type: OpenSSL related
Operating System: Linux Debian Etch
PHP Version: 5CVS-2008-11-01
Assigned To: pajoye
New Comment:
@ryan+phpbugs at sleevi dot com
Thanks for the detailed explanation. And you are right about the
conclusions. That's also not something we should try to change from PHP
(if there was a bug), that's openssl's job.
Previous Comments:
[2009-09-04 05:06:16] ryan+phpbugs at sleevi dot com
The problem is not resolved in PHP 5.2.6, provided you call it
correctly.
openssl_x509_checkpurpose expects to be able to build a full chain of
certificates to verify its purpose. Furthermore, it expects there to be
a trusted certificate as part of the chain.
When invoked as
var_dump(openssl_x509_checkpurpose(file_get_contents('./certfile.pem').
X509_PURPOSE_SMIME_SIGN));
this fails, because a chain cannot properly be built to a trusted
root.
My test case involved:
- Obtaining Using the Thawte intermediate and root certificates,
obtained via http://www.thawte.com/repository/index.html
- Copying the contents of the Thawte Personal Freemail Issuing CA and
Thawte Personal Freemail CA PEM files from that list into a new file,
called 'chain.pem'. The certs were simply appended one after the other
- Setting the system time to be during the validity period of the
certificate (2007-10-10 00:00:00 GMT)
- executing as
var_dump(openssl_x509_checkpurpose(file_get_contents('./certfile.pem').
X509_PURPOSE_SMIME_SIGN, array('./chain.pem'));
- I received int(1) as the result
I do not believe the reporter's initial case should be supported.
Purpose checking requires checking each of the CAs that issued the
certificate to make sure there are no purpose constraints. The absence
of the CA certificates makes this impossible, hence the failure.
If one wishes to obtain any X509 certificate extensions for a single
certificate, openssl_x509_parse is able to provide this information.
However, it should not be treated as authoritative, as it does not
reflect the full chain policy being enforced for that certificate.
My OpenSSL version was 0.9.8f, running Linux kernel 2.6.14.6 and PHP
5.2.6. While these versions do differ from the original submission, with
the above explanation, it should provide enough information to see if
this does resolve the situation with purpose verification.
[2008-11-18 10:09:50] paj...@php.net
It seems to be a bug in the openssl directly. I have tried with many
different certs and many failed (including the one available in the
openssl's demo directory).
I have to work on other things now, the fix may require to duplicate
the x509_verify_cert code (partially or completely).
tested with 0.98g and 0.9.8i
[2008-11-01 21:13:07] tokul at users dot sourceforge dot net
php 5.2-200811011530
Test result is the same. It is impossible to verify purpose of
certificate, because function returns integer value which is evaluated
as false even when certificate can be used for SMIME signatures.
I don't know options that Thawte used to generate certificate. I've
accepted default options with 2048-bit encryption for Mozilla
Firefox/Thunderbird.
Here goes already expired certificate used for initial bug report.
-BEGIN CERTIFICATE-
MIIC8DCCAlmgAwIBAgIQS8GxvbV7pghz0FD/I7rVVjANBgkqhkiG9w0BAQUFADBi
MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg
THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vpbmcg
Q0EwHhcNMDcwMjI0MDYyMzA0WhcNMDgwMjI0MDYyMzA0WjBNMR8wHQYDVQQDExZU
aGF3dGUgRnJlZW1haWwgTWVtYmVyMSowKAYJKoZIhvcNAQkBFht0b2t1bEB1c2Vy
cy5zb3VyY2Vmb3JnZS5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDQALcUK5moBKz5tHqYcquqb8seEKgzDbFJ3Nko8VEyVy1vnwKtHkNeXuMv1mbH
2dhkvI2JtWpNte36bzLErQHzZhnehAdRb3RIlLrASxkn4btidkWasYjqhtMI1sGL
D+7wFdC4rSfdYwRUto8zrB5FeoNakJre8gmljqwm18fh5ZMsiWboXdKVVCa8ALBk
P5dZ7gYElfNj3FJSjqo0Efs5yQn8EsY+uDNTH+y8HE5Sqq0mkuLw/7WIO5PCsQAF
xTsEo2dqnj3us9KGgNGkR4JRp17NPfNofLs26w7H2n3oAmjMaM51U5lpPOSh0Nm7
uwrpsWnE84Jm2I/9WhhuSOEJAgMBAAGjODA2MCYGA1UdEQQfMB2BG3Rva3VsQHVz
ZXJzLnNvdXJjZWZvcmdlLm5ldDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUA
A4GBAJlmrYGSeE00IK7WR+05BT0g6YigfIoKLbeTJu25oVHN8dBLU0Jjx5KZRfZQ
BCt/8CVBNxNwwKRQnQ36M4Hq0YLa+bBYq3pJPbL62Ffj7mLHhDkFvJw/sgQ1I7jH
URvzt58Hw3B34wEHzqnzcsFOPxNZN3aU4BTnbUBTUjkVVpuZ
-END CERTIFICATE-
[2008-10-31 08:49:37] paj...@php.net
Please provide a sample certificate to reproduce this problem or the
values you used to create a similar certificate.
[2007-10-08 10:52
