Bug #16994 Updated: Error log reports seg fault and bus error at what seems to be arbitrary moments
ID: 16994
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Scripting Engine problem
Operating System: FreeBSD 4.5
PHP Version: 4.2.0
New Comment:
Hi,
I am having extremely similair failure with PHP-4.2.0 on at least 2
FreeBSD-systems.
May 7 14:27:53 spock /kernel: pid 58939 (httpd), uid 0: exited on
signal 11
I was trying to get a fresh install of Ariadne (a PHP-based CMS
http://ariadne.muze.nl) going when i encountered these problems.
The exact same script (install.php) seems to consitently bomb at the
same location over and over again, though it does so at different
locations depending on wether it's run from Apache or from command-line
php.
I have compiled a command-line version of PHP with --enable-debug and
managed to get the following "Backtrace":
spock# gdb /usr/local/bin/php ./php.core
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i386-unknown-freebsd"...
Core was generated by `php'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libpam.so.1...done.
Reading symbols from /usr/local/lib/libc-client4.so.8...done.
Reading symbols from /usr/local/lib/libsablot.so.67...done.
Reading symbols from /usr/local/lib/libiconv.so.3...done.
Reading symbols from /usr/local/lib/libexpat.so.2...done.
Reading symbols from /usr/lib/libhistory.so.4...done.
Reading symbols from /usr/lib/libreadline.so.4...done.
Reading symbols from /usr/lib/libncurses.so.5...done.
Reading symbols from /usr/local/lib/libpq.so.2...done.
Reading symbols from /usr/local/lib/mysql/libmysqlclient.so.10...done.
Reading symbols from /usr/local/lib/libmhash.so.2...done.
Reading symbols from /usr/local/lib/libmcrypt.so.7...done.
Reading symbols from /usr/local/lib/libltdl.so.1...done.
Reading symbols from /usr/lib/libcrypt.so.2...done.
Reading symbols from /usr/local/lib/libintl.so.2...done.
Reading symbols from /usr/lib/libz.so.2...done.
Reading symbols from /usr/lib/libm.so.2...done.
Reading symbols from /usr/local/lib/libxml2.so.5...done.
Reading symbols from /usr/lib/libssl.so.2...done.
Reading symbols from /usr/lib/libcrypto.so.2...done.
Reading symbols from /usr/local/lib/libcurl.so.2...done.
Reading symbols from /usr/lib/libbz2.so.1...done.
Reading symbols from /usr/lib/libc.so.4...done.
Reading symbols from /usr/libexec/ld-elf.so.1...done.
#0 0x81352c1 in execute (op_array=0x0) at ./zend_execute.c:1602
1602
EX(Ts)[EX(opline)->result.u.var].var.ptr->is_ref = 0;
(gdb) bt
#0 0x81352c1 in execute (op_array=0x0) at ./zend_execute.c:1602
(gdb) print execute_data
$1 = {opline = 0x0, function_state = {function_symbol_table = 0x0,
function = 0x0, reserved = {0x0, 0x0, 0x0, 0x0}}, fbc = 0x0, object =
{ptr = 0x0}, Ts = 0x0, original_in_execution = 0 '\000'}
I realise this is about the shortest backtrace i have ever managed to
get out of any core dump ... but i hope it will be helpful anyhow.
--
Pascal Hofstee <[EMAIL PROTECTED]>
Previous Comments:
[2002-05-06 13:17:49] [EMAIL PROTECTED]
I unfortunately can not rebuild PHP with --enable-debug (no access
privaleges), so I can not debug from httpd. I have built a stand alone
version with debug enabled and tested it on a few scripts.
I have isolated one script that very consistently craps out when run
from httpd or from command line. Httpd error log reports the
following:
[Mon May 6 10:01:45 2002] [notice] child pid 81412 exit signal Bus
error (10)
When the same script is run from command line, no core is dumped. When
running the script with gdb, it ends with no stack:
(gdb) run send.php
Starting program: /usr/home/ise/bin/php send.php
X-Powered-By: PHP/4.2.0
Content-type: text/html
Program exited with code 0377.
(gdb) bt
No stack.
When the script is run from PHP 4.1.2 command line, the output is as
expected: the desired HTML output.
[2002-05-03 10:35:36] [EMAIL PROTECTED]
To properly diagnose this bug, we need a backtrace to see what is
happening behind the scenes. To find out how to generate a backtrace,
please read http://bugs.php.net/bugs-generating-backtrace.php
Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open".
[2002-05-03 10:34:24]
#21547 [NEW]: segfault in _erealloc
From: [EMAIL PROTECTED]
Operating system: Linux Mandrake Cooker
PHP version: 4.3.0
PHP Bug Type: Reproducible crash
Bug description: segfault in _erealloc
This quite heavily recursive script produces a segmentation fault :
Array(-1, 0),
'D'=>Array(1, 0),
'B'=>Array(0, 1),
'H'=>Array(0, -1));
$pieces=Array(
Array(Array(0,0),
Array(0,1)),
Array(Array(0,0),
Array(0,1)),
Array(Array(0,0),
Array(0,1)),
Array(Array(0,0),
Array(0,1)),
Array(Array(0,0),
Array(0,1),
Array(1,0),
Array(1,1)),
Array(Array(0,0)),
Array(Array(0,0)),
Array(Array(0,0)),
Array(Array(0,0)),
Array(Array(0,0),
Array(1,0)));
$init=Array(
Array(0,0),
Array(3,0),
Array(1,3),
Array(2,3),
Array(1,0),
Array(0,3),
Array(0,4),
Array(3,3),
Array(3,4),
Array(1,2));
function is_final($situation){
return(($situation[4][0]==1)&&($situation[4][1]==3));
}
function occupable($situation, $x, $y){
global $pieces;
if($x>3) return false;
if($y>4) return false;
if($x<0) return false;
if($y<0) return false;
foreach($situation as $piece=>$pos){
if($pos=="") continue;
$p = $pieces[$piece];
foreach($p as $case){
if(($case[0]+$pos[0]==$x)&&
($case[1]+$pos[1]==$y)) return false;
}
}
return true;
}
function valide($situation, $piece, $mov){
global $pieces;
$p = $pieces[$piece];
$x = $situation[$piece][0];
$y = $situation[$piece][1];
$situation[$piece]="";
foreach($p as $case){
if(!occupable($situation, $x+$case[0]+$mov[0], $y+$case[1]+$mov[1]))
return false;
}
return true;
}
function resolv($situation){
global $tab, $depls, $pieces, $solution;
$d = $depls;
$p = $pieces;
if(is_final($situation)){
$solution = "";
return;
}
foreach($p as $num=>$piece){
foreach($d as $nom=>$mov){
if(valide($situation, $num, $mov)){
$situation2=serialize($situation);
$s3=$situation;
$situation[$num][0]+=$mov[0];
$situation[$num][1]+=$mov[1];
$s=serialize($situation);
if(isset($tab[$s])){
$situation = $s3;
continue;
}
$tab[$s]="";
//echo $num.' '.$nom."\n";
//print_r($situation);
$tab[$situation2][$s]=Array($num=>$nom);
resolv($situation);
if($tab[$s]=="") unset($tab[$s]);
if(isset($solution)){
$solution=$num.' '.$nom."\n".$solution;
return;
}
$situation = $s3;
}
}
}
}
resolv($init);
print_r($tab);
if(isset($solution)) echo $solution;
?>
(gdb) bt
#0 0x400ed1ee in _erealloc () from /usr/lib/libphp_common.so.430
(gdb)
I tryied it with an older PHP and also got a segfault but somewhere else.
--
Edit bug report at http://bugs.php.net/?id=21547&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21547&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=21547&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=21547&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21547&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=21547&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21547&r=support
Expected behavior: http://bugs.php.net/fix.php?id=21547&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21547&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21547&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=21547&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21547&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=21547&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=21547&r=isapi
Install GNU Sed:
#21547 [Bgs->Opn]: segfault in _erealloc
ID: 21547
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Bogus
+Status: Open
Bug Type: Reproducible crash
Operating System: Linux Mandrake Cooker
PHP Version: 4.3.0
New Comment:
The diagnosis is strange as it crashes using about 20MB while the
memory limit is at 128MB and I have more than 200MB free...
Previous Comments:
[2003-01-09 10:00:04] [EMAIL PROTECTED]
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
Simple, PHP has run out of memory and when it fails to allocate it
exits or if you compiled PHP with --enable-debug dies with SIG11
(segmentation fault).
[2003-01-09 07:59:49] [EMAIL PROTECTED]
This quite heavily recursive script produces a segmentation fault :
Array(-1, 0),
'D'=>Array(1, 0),
'B'=>Array(0, 1),
'H'=>Array(0, -1));
$pieces=Array(
Array(Array(0,0),
Array(0,1)),
Array(Array(0,0),
Array(0,1)),
Array(Array(0,0),
Array(0,1)),
Array(Array(0,0),
Array(0,1)),
Array(Array(0,0),
Array(0,1),
Array(1,0),
Array(1,1)),
Array(Array(0,0)),
Array(Array(0,0)),
Array(Array(0,0)),
Array(Array(0,0)),
Array(Array(0,0),
Array(1,0)));
$init=Array(
Array(0,0),
Array(3,0),
Array(1,3),
Array(2,3),
Array(1,0),
Array(0,3),
Array(0,4),
Array(3,3),
Array(3,4),
Array(1,2));
function is_final($situation){
return(($situation[4][0]==1)&&($situation[4][1]==3));
}
function occupable($situation, $x, $y){
global $pieces;
if($x>3) return false;
if($y>4) return false;
if($x<0) return false;
if($y<0) return false;
foreach($situation as $piece=>$pos){
if($pos=="") continue;
$p = $pieces[$piece];
foreach($p as $case){
if(($case[0]+$pos[0]==$x)&&
($case[1]+$pos[1]==$y)) return false;
}
}
return true;
}
function valide($situation, $piece, $mov){
global $pieces;
$p = $pieces[$piece];
$x = $situation[$piece][0];
$y = $situation[$piece][1];
$situation[$piece]="";
foreach($p as $case){
if(!occupable($situation, $x+$case[0]+$mov[0], $y+$case[1]+$mov[1]))
return false;
}
return true;
}
function resolv($situation){
global $tab, $depls, $pieces, $solution;
$d = $depls;
$p = $pieces;
if(is_final($situation)){
$solution = "";
return;
}
foreach($p as $num=>$piece){
foreach($d as $nom=>$mov){
if(valide($situation, $num, $mov)){
$situation2=serialize($situation);
$s3=$situation;
$situation[$num][0]+=$mov[0];
$situation[$num][1]+=$mov[1];
$s=serialize($situation);
if(isset($tab[$s])){
$situation = $s3;
continue;
}
$tab[$s]="";
//echo $num.' '.$nom."\n";
//print_r($situation);
$tab[$situation2][$s]=Array($num=>$nom);
resolv($situation);
if($tab[$s]=="") unset($tab[$s]);
if(isset($solution)){
$solution=$num.' '.$nom."\n".$solution;
return;
}
$situation = $s3;
}
}
}
}
resolv($init);
print_r($tab);
if(isset($solution)) echo $solution;
?>
(gdb) bt
#0 0x400ed1ee in _erealloc () from /usr/lib/libphp_common.so.430
(gdb)
I tryied it with an older PHP and also got a segfault but somewhere
else.
--
Edit this bug report at http://bugs.php.net/?id=21547&edit=1
#21547 [Fbk->Opn]: segfault in _erealloc
ID: 21547
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: Linux Mandrake Cooker
PHP Version: 4.3.0
New Comment:
Works fine, even with 12500.
With 10 I get
FATAL: emalloc(): Unable to allocate 11 bytes
Previous Comments:
[2003-01-09 16:20:34] [EMAIL PROTECTED]
Perphaps you have a system limit on the amount of memory a process make
try to use. Try the following script and see if it crashes:
[2003-01-09 10:23:39] [EMAIL PROTECTED]
The diagnosis is strange as it crashes using about 20MB while the
memory limit is at 128MB and I have more than 200MB free...
[2003-01-09 10:00:04] [EMAIL PROTECTED]
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
Simple, PHP has run out of memory and when it fails to allocate it
exits or if you compiled PHP with --enable-debug dies with SIG11
(segmentation fault).
[2003-01-09 07:59:49] [EMAIL PROTECTED]
This quite heavily recursive script produces a segmentation fault :
Array(-1, 0),
'D'=>Array(1, 0),
'B'=>Array(0, 1),
'H'=>Array(0, -1));
$pieces=Array(
Array(Array(0,0),
Array(0,1)),
Array(Array(0,0),
Array(0,1)),
Array(Array(0,0),
Array(0,1)),
Array(Array(0,0),
Array(0,1)),
Array(Array(0,0),
Array(0,1),
Array(1,0),
Array(1,1)),
Array(Array(0,0)),
Array(Array(0,0)),
Array(Array(0,0)),
Array(Array(0,0)),
Array(Array(0,0),
Array(1,0)));
$init=Array(
Array(0,0),
Array(3,0),
Array(1,3),
Array(2,3),
Array(1,0),
Array(0,3),
Array(0,4),
Array(3,3),
Array(3,4),
Array(1,2));
function is_final($situation){
return(($situation[4][0]==1)&&($situation[4][1]==3));
}
function occupable($situation, $x, $y){
global $pieces;
if($x>3) return false;
if($y>4) return false;
if($x<0) return false;
if($y<0) return false;
foreach($situation as $piece=>$pos){
if($pos=="") continue;
$p = $pieces[$piece];
foreach($p as $case){
if(($case[0]+$pos[0]==$x)&&
($case[1]+$pos[1]==$y)) return false;
}
}
return true;
}
function valide($situation, $piece, $mov){
global $pieces;
$p = $pieces[$piece];
$x = $situation[$piece][0];
$y = $situation[$piece][1];
$situation[$piece]="";
foreach($p as $case){
if(!occupable($situation, $x+$case[0]+$mov[0], $y+$case[1]+$mov[1]))
return false;
}
return true;
}
function resolv($situation){
global $tab, $depls, $pieces, $solution;
$d = $depls;
$p = $pieces;
if(is_final($situation)){
$solution = "";
return;
}
foreach($p as $num=>$piece){
foreach($d as $nom=>$mov){
if(valide($situation, $num, $mov)){
$situation2=serialize($situation);
$s3=$situation;
$situation[$num][0]+=$mov[0];
$situation[$num][1]+=$mov[1];
$s=serialize($situation);
if(isset($tab[$s])){
$situation = $s3;
continue;
}
$tab[$s]="";
//echo $num.' '.$nom."\n";
//print_r($situation);
$tab[$situation2][$s]=Array($num=>$nom);
resolv($situation);
if($tab[$s]=="") unset($tab[$s]);
if(isset($solution)){
$solution=$num.' '.$nom."\n".$solution;
return;
}
$situation = $s3;
}
Bug #15540: erreo in date calculation with easter_date() for 2002
From: [EMAIL PROTECTED]
Operating system: winNT
PHP version: 4.1.1
PHP Bug Type: Scripting Engine problem
Bug description: erreo in date calculation with easter_date() for 2002
the result of :
-
easter monday : ";
print date("m/d/Y H:i:s", easter_date(2002)+(1*3600*24));
print "easter in 2001 : ";
print date("m/d/Y H:i:s", easter_date(2001));
print "easter monday : ";
print date("m/d/Y H:i:s", easter_date(2001)+(1*3600*24));
print "";
?>
-
gives :
-
easter in 2002 : 03/31/2002 00:00:00
easter monday : 04/01/2002 01:00:00
easter in 2001 : 04/15/2001 00:00:00
easter monday : 04/16/2001 00:00:00
-
as if in 2002 the easter day is only of 23 hours...
--
Edit bug report at http://bugs.php.net/?id=15540&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=15540&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=15540&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=15540&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=15540&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=15540&r=support
Expected behavior: http://bugs.php.net/fix.php?id=15540&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=15540&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=15540&r=submittedtwice
Bug #15540 Updated: error in date calculation with easter_date() for 2002
ID: 15540
Updated by: [EMAIL PROTECTED]
-Summary: erreo in date calculation with easter_date() for 2002
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Scripting Engine problem
Operating System: winNT
PHP Version: 4.1.1
Previous Comments:
[2002-02-13 08:44:12] [EMAIL PROTECTED]
the result of :
-
easter monday : ";
print date("m/d/Y H:i:s", easter_date(2002)+(1*3600*24));
print "easter in 2001 : ";
print date("m/d/Y H:i:s", easter_date(2001));
print "easter monday : ";
print date("m/d/Y H:i:s", easter_date(2001)+(1*3600*24));
print "";
?>
-
gives :
-
easter in 2002 : 03/31/2002 00:00:00
easter monday : 04/01/2002 01:00:00
easter in 2001 : 04/15/2001 00:00:00
easter monday : 04/16/2001 00:00:00
-
as if in 2002 the easter day is only of 23 hours...
--
Edit this bug report at http://bugs.php.net/?id=15540&edit=1
Bug #15540 Updated: erreo in date calculation with easter_date() for 2002
ID: 15540
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: winNT
PHP Version: 4.1.1
New Comment:
>[13 Feb 9:34am] [EMAIL PROTECTED]
>daylight saving time
Quite true ! it's not a bug finally !
Previous Comments:
[2002-02-13 09:34:05] [EMAIL PROTECTED]
daylight saving time
[2002-02-13 08:44:12] [EMAIL PROTECTED]
the result of :
-
easter monday : ";
print date("m/d/Y H:i:s", easter_date(2002)+(1*3600*24));
print "easter in 2001 : ";
print date("m/d/Y H:i:s", easter_date(2001));
print "easter monday : ";
print date("m/d/Y H:i:s", easter_date(2001)+(1*3600*24));
print "";
?>
-
gives :
-
easter in 2002 : 03/31/2002 00:00:00
easter monday : 04/01/2002 01:00:00
easter in 2001 : 04/15/2001 00:00:00
easter monday : 04/16/2001 00:00:00
-
as if in 2002 the easter day is only of 23 hours...
--
Edit this bug report at http://bugs.php.net/?id=15540&edit=1
Bug #16075: Logon fonction (usiong invoke) doesn't work in CGI, but in standalone
From: [EMAIL PROTECTED]
Operating system: WinNT 4
PHP version: 4.1.2
PHP Bug Type: COM related
Bug description: Logon fonction (usiong invoke) doesn't work in CGI, but in standalone
Trying to access Exchange datas using COM objects, something matters, even
if the code is well : impossible to logon on a MAPI Session.
Configuration : NT 4, Apache 1.3.23, PHP 4.1.2 (but before too) in cgi
mode.
the code is :
Version."";
$err=$instance->Logon("Pascal Guimier","",true,false);
$inbox=$instance->Inbox;
$collmsg=$inbox->Messages;
$msg=$collmsg->GetFirst();
while ($msg) {
print "Subject : ". $msg->Subject . "";
$msg=$collmsg->GetNext();
}
?>
And there is always an error message :
"Warning: Invoke() failed: Une exception s'est produite. Source:
Collaboration Data Objects Description: [Collaboration Data Objects -
[MAPI_E_LOGON_FAILED(80040111)]] in
d:\users\group\www\essais\com\mboxlist.php on line 5"
"Une exception s'est produite" means there was an exception.
So I tried in several manners, and what is troubling is that launching the
script at command line (>php d:\users\group\www\essais\com\mboxlist.php)
works well !
That's why I think the bug can be in COM invoke() function, that doesn't
work the shame in two cases.
But it's only a supposition.
So now I only can use my scripts in cron to make a chache in order to
fetch Exchange datas :o)
Thanks
Pascal
--
Edit bug report at http://bugs.php.net/?id=16075&edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=16075&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16075&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=16075&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=16075&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16075&r=support
Expected behavior: http://bugs.php.net/fix.php?id=16075&r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16075&r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16075&r=submittedtwice
Bug #16075 Updated: Logon fonction (usiong invoke) doesn't work in CGI, but in standalone
ID: 16075
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: COM related
Operating System: WinNT 4
PHP Version: 4.1.2
New Comment:
Right !
running Apache in console, and it works ! Before, it just runned as a
service.
I don't know who is the user that runs apache as service. I supposed it
is Admin. So no.
This 'security issue' force me to keep server logged as Admin, to run
apache in console...
Previous Comments:
[2002-03-15 12:31:41] [EMAIL PROTECTED]
this seems to be a security issue. i suppose your apache server runs
under a different user than you are running the cgi executeable.
check if the user has enough rights to access the exchange server.
[2002-03-14 10:59:30] [EMAIL PROTECTED]
Trying to access Exchange datas using COM objects, something matters,
even if the code is well : impossible to logon on a MAPI Session.
Configuration : NT 4, Apache 1.3.23, PHP 4.1.2 (but before too) in cgi
mode.
the code is :
Version."";
$err=$instance->Logon("Pascal Guimier","",true,false);
$inbox=$instance->Inbox;
$collmsg=$inbox->Messages;
$msg=$collmsg->GetFirst();
while ($msg) {
print "Subject : ". $msg->Subject . "";
$msg=$collmsg->GetNext();
}
?>
And there is always an error message :
"Warning: Invoke() failed: Une exception s'est produite. Source:
Collaboration Data Objects Description: [Collaboration Data Objects -
[MAPI_E_LOGON_FAILED(80040111)]] in
d:\users\group\www\essais\com\mboxlist.php on line 5"
"Une exception s'est produite" means there was an exception.
So I tried in several manners, and what is troubling is that launching
the script at command line (>php
d:\users\group\www\essais\com\mboxlist.php) works well !
That's why I think the bug can be in COM invoke() function, that
doesn't work the shame in two cases.
But it's only a supposition.
So now I only can use my scripts in cron to make a chache in order to
fetch Exchange datas :o)
Thanks
Pascal
--
Edit this bug report at http://bugs.php.net/?id=16075&edit=1
#19739 [Com]: php-4.2.3 fails to Install with Apache 2.0.42 on AIX 5.1 ML2
ID: 19739 Comment by: pascal at vmfacility dot fr Reported By: php at thater dot net Status: No Feedback Bug Type: Apache2 related Operating System: AIX 5.1 PHP Version: 4.3.0-dev New Comment: with apache 2.0.44 and php 4.3.2rc2 on the same platform AIX 5.1 ml3 I have a problem with the installation of libphp4.so in the target directory. seems to be a bug in libtool or instdso.sh. my configure is : ./configure \ --with-apxs2=/usr/local/apache2/bin/apxs\ --with-apxs2-filter=/usr/local/apache2/bin/apxs \ --with-apxs2handler=/usr/local/apache2/bin/apxs \ --with-apache2=/usr/local/apache2 \ --with-mysql=/usr/local/mysql \ --with-openssl=/usr/local/ssl \ --with-zlib-dir=/usr/local/src/zlib-1.1.4 \ --with-gd \ --enable-discard-path \ --disable-force-cgi-redirect \ --enable-shared \ --disable-static \ --disable-debug \ --disable-rpath \ --enable-pic \ --enable-inline-optimization \ --enable-memory-limit \ --enable-magic-quotes \ --enable-debugger \ --enable-track-vars \ --with-versioning \ --with-mod_charset \ --with-regex=php \ --with-pear \ --enable-track-vars \ --enable-trans-sid \ --enable-safe-mode \ --enable-ctype \ --enable-ftp \ --enable-posix \ --enable-session \ --enable-sysvsem \ --enable-sysvshm \ --enable-yp \ --without-kerberos make is OK make install does not succeed because libphp4.so is not copied to TARGETDIR : Installing PHP SAPI module /usr/local/apache2/build/instdso.sh SH_LIBTOOL='/usr/local/apache2/build/libtool' libphp4.la /usr/local/apache2/modules + test 3 != 3 + + echo SH_LIBTOOL=/usr/local/apache2/build/libtool + sed -e s/^SH_LIBTOOL=// SH_LIBTOOL=/usr/local/apache2/build/libtool + DSOARCHIVE=libphp4.la + + basename libphp4.la DSOARCHIVE_BASENAME=libphp4.la + TARGETDIR=/usr/local/apache2/modules + + sed -e s/\.la$// + echo libphp4.la DSOBASE=libphp4 + TARGET_NAME=libphp4.so + ls -l /usr/local/apache2/modules total 16 -rw-r--r-- 1 bin bin8035 Mar 17 19:13 httpd.exp + + uname -s SYS=AIX + test AIX = AIX + CMD=rm -f /usr/local/apache2/modules/libphp4.so + echo rm -f /usr/local/apache2/modules/libphp4.so rm -f /usr/local/apache2/modules/libphp4.so + rm -f /usr/local/apache2/modules/libphp4.so + CMD=/usr/local/apache2/build/libtool --mode=install cp libphp4.la /usr/local/apache2/modules/ + echo /usr/local/apache2/build/libtool --mode=install cp libphp4.la /usr/local/apache2/modules/ /usr/local/apache2/build/libtool --mode=install cp libphp4.la /usr/local/apache2/modules/ + /usr/local/apache2/build/libtool --mode=install cp libphp4.la /usr/local/apache2/modules/ cp .libs/libphp4.a /usr/local/apache2/modules/libphp4.a cp .libs/libphp4.lai /usr/local/apache2/modules/libphp4.la libtool: install: warning: remember to run `libtool --finish /usr/local/src/php-4.3.2RC1/libs' + test AIX = OS/2 + + grep ^dlname /usr/local/apache2/modules/libphp4.la + sed -e s/dlname='\([^']*\)'/\1/ DLNAME=libphp4.so + + grep library_names /usr/local/apache2/modules/libphp4.la + sed -e s/dlname='\([^']*\)'/\1/ LIBRARY_NAMES=library_names='libphp4.a libphp4.a' + + echo library_names='libphp4.a libphp4.a' + sed -e s/ *libphp4.so//g LIBRARY_NAMES=library_names='libphp4.a libphp4.a' + test -z libphp4.so + ls -l /usr/local/apache2/modules total 19440 -rw-r--r-- 1 bin bin8035 Mar 17 19:13 httpd.exp -rw-r--r-- 1 root system 9939429 Mar 18 15:19 libphp4.a -rw-r--r-- 1 root system 814 Mar 18 15:19 libphp4.la + test -n library_names='libphp4.a libphp4.a' + rm -f /usr/local/apache2/modules/library_names='libphp4.a + rm -f /usr/local/apache2/modules/libphp4.a' + ls -l /usr/local/apache2/modules total 19440 -rw-r--r-- 1 bin bin8035 Mar 17 19:13 httpd.exp -rw-r--r-- 1 root system 9939429 Mar 18 15:19 libphp4.a -rw-r--r-- 1 root system 814 Mar 18 15:19 libphp4.la + test libphp4.so != libphp4.so + ls -l /usr/local/apache2/modules total 19440 -rw-r--r-- 1 bin bin8035 Mar 17 19:13 httpd.exp -rw-r--r-- 1 root system 9939429 Mar 18 15:19 libphp4.a -rw-r--r-- 1 root system 814 Mar 18 15:19 libphp4.la + rm -f /usr/local/apache2/modules/libphp4.la + rm -f /usr/local/apache2/modules/libphp4.a + rm -f /usr/local/apache2/modules/liblibphp4.a + rm -f /usr/local/apache2/modules/liblibphp4.so + exit 0 chmod 755 /usr/local/apache2/modules/libphp4.so chmod: /usr/local/apache2/modules/libphp4.so: No such file or directory apxs:Error: Command failed with rc=65536 . make: The error code from the last c
Bug #65571 [Com]: Compiling fails with - missing binary operator before token "extern"
Edit report at https://bugs.php.net/bug.php?id=65571&edit=1 ID: 65571 Comment by: pascal at nobus dot be Reported by:tony dot ar dot wright at bt dot com Summary:Compiling fails with - missing binary operator before token "extern" Status: Open Type: Bug Package:Compile Failure Operating System: SuSE 9 PHP Version:5.5.3 Block user comment: N Private report: N New Comment: I had the same problem on php-5.4.19 This on a slackware-10.1 Tried the snapshot (php5.4-201309091030), and it seems to be fixed there? However I have no idea with what change the bug is fixed. Previous Comments: [2013-08-28 09:37:25] tony dot ar dot wright at bt dot com Description: I installed 5.5.2 ok but when I tried to install 5.5.3 I get the error message: In file included from Zend/zend_language_scanner.l:40: Zend/zend_language_parser.h:40:1: missing binary operator before token "extern" make: *** [Zend/zend_language_scanner.lo] Error 1 Configure options used: './configure' '--with-apxs2=/usr/local/apache2/bin/apxs' '--enable-ftp' '--witho ut-ldap' '--enable-sockets' '--with-gd' '--with-freetype-dir' '--without-mcrypt' '--with-zlib-dir' '--with-png-dir' '--with-oci8=/export/oracle/product/10.2.0/d b_1' '--with-openssl' -- Edit this bug report at https://bugs.php.net/bug.php?id=65571&edit=1
Bug #65571 [Com]: Compiling fails with - missing binary operator before token "extern"
Edit report at https://bugs.php.net/bug.php?id=65571&edit=1 ID: 65571 Comment by: pascal at nobus dot be Reported by:tony dot ar dot wright at bt dot com Summary:Compiling fails with - missing binary operator before token "extern" Status: Feedback Type: Bug Package:Compile Failure Operating System: SuSE 9 PHP Version:5.5.3 Block user comment: N Private report: N New Comment: For the slackware-OS: (also php-5.4.20 has this problem) # flex -V flex 2.5.33 # bison -V bison (GNU Bison) 2.3 Previous Comments: [2013-10-01 14:36:01] m...@php.net What are your flex/bison versions? [2013-09-09 12:33:28] pascal at nobus dot be I had the same problem on php-5.4.19 This on a slackware-10.1 Tried the snapshot (php5.4-201309091030), and it seems to be fixed there? However I have no idea with what change the bug is fixed. [2013-08-28 09:37:25] tony dot ar dot wright at bt dot com Description: I installed 5.5.2 ok but when I tried to install 5.5.3 I get the error message: In file included from Zend/zend_language_scanner.l:40: Zend/zend_language_parser.h:40:1: missing binary operator before token "extern" make: *** [Zend/zend_language_scanner.lo] Error 1 Configure options used: './configure' '--with-apxs2=/usr/local/apache2/bin/apxs' '--enable-ftp' '--witho ut-ldap' '--enable-sockets' '--with-gd' '--with-freetype-dir' '--without-mcrypt' '--with-zlib-dir' '--with-png-dir' '--with-oci8=/export/oracle/product/10.2.0/d b_1' '--with-openssl' -- Edit this bug report at https://bugs.php.net/bug.php?id=65571&edit=1
Bug #65571 [Com]: Compiling fails with - missing binary operator before token "extern"
Edit report at https://bugs.php.net/bug.php?id=65571&edit=1 ID: 65571 Comment by: pascal at nobus dot be Reported by:tony dot ar dot wright at bt dot com Summary:Compiling fails with - missing binary operator before token "extern" Status: Suspended Type: Bug Package:Compile Failure Operating System: SuSE 9 PHP Version:5.5.3 Block user comment: N Private report: N New Comment: apologies for my previous post, I was on the wrong server # flex -V flex version 2.5.4 # bison -V bison (GNU Bison) 1.35 I'll try to get a later bison-version Previous Comments: [2013-10-01 15:21:54] m...@php.net Looks like you have to use bison2.4 - 2.7 to build from a source checkout. [2013-10-01 15:05:47] pascal at nobus dot be For the slackware-OS: (also php-5.4.20 has this problem) # flex -V flex 2.5.33 # bison -V bison (GNU Bison) 2.3 [2013-10-01 14:36:01] m...@php.net What are your flex/bison versions? [2013-09-09 12:33:28] pascal at nobus dot be I had the same problem on php-5.4.19 This on a slackware-10.1 Tried the snapshot (php5.4-201309091030), and it seems to be fixed there? However I have no idea with what change the bug is fixed. [2013-08-28 09:37:25] tony dot ar dot wright at bt dot com Description: I installed 5.5.2 ok but when I tried to install 5.5.3 I get the error message: In file included from Zend/zend_language_scanner.l:40: Zend/zend_language_parser.h:40:1: missing binary operator before token "extern" make: *** [Zend/zend_language_scanner.lo] Error 1 Configure options used: './configure' '--with-apxs2=/usr/local/apache2/bin/apxs' '--enable-ftp' '--witho ut-ldap' '--enable-sockets' '--with-gd' '--with-freetype-dir' '--without-mcrypt' '--with-zlib-dir' '--with-png-dir' '--with-oci8=/export/oracle/product/10.2.0/d b_1' '--with-openssl' -- Edit this bug report at https://bugs.php.net/bug.php?id=65571&edit=1
Bug #65571 [Com]: Compiling fails with - missing binary operator before token "extern"
Edit report at https://bugs.php.net/bug.php?id=65571&edit=1 ID: 65571 Comment by: pascal at nobus dot be Reported by:tony dot ar dot wright at bt dot com Summary:Compiling fails with - missing binary operator before token "extern" Status: Suspended Type: Bug Package:Compile Failure Operating System: SuSE 9 PHP Version:5.5.3 Block user comment: N Private report: N New Comment: I updated to bison-1.875 (compiled from source), but this didn't matter indeed. The problem appeared in php-5.4.19 and was not there in php-5.4.18. I could build it just fine from complete source tarball. Previous Comments: [2013-10-01 15:35:25] m...@php.net If you build release tarballs, the bison version should not matter, though. [2013-10-01 15:29:19] pascal at nobus dot be apologies for my previous post, I was on the wrong server # flex -V flex version 2.5.4 # bison -V bison (GNU Bison) 1.35 I'll try to get a later bison-version [2013-10-01 15:21:54] m...@php.net Looks like you have to use bison2.4 - 2.7 to build from a source checkout. ---- [2013-10-01 15:05:47] pascal at nobus dot be For the slackware-OS: (also php-5.4.20 has this problem) # flex -V flex 2.5.33 # bison -V bison (GNU Bison) 2.3 [2013-10-01 14:36:01] m...@php.net What are your flex/bison versions? 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 https://bugs.php.net/bug.php?id=65571 -- Edit this bug report at https://bugs.php.net/bug.php?id=65571&edit=1
Bug #65571 [Com]: Compiling fails with - missing binary operator before token "extern"
Edit report at https://bugs.php.net/bug.php?id=65571&edit=1 ID: 65571 Comment by: pascal at nobus dot be Reported by:tony dot ar dot wright at bt dot com Summary:Compiling fails with - missing binary operator before token "extern" Status: Not a bug Type: Bug Package:Compile Failure Operating System: SuSE 9 PHP Version:5.5.3 Block user comment: N Private report: N New Comment: I couldn't compile 2.7, so tried first the latest from the 1-version. Now I tried 2.4.1, which I could compile. However the problem stays the same. /bin/sh /usr/local/src/php-5.4.20/libtool --silent --preserve-dup-deps -- mode=compile cc -IZend/ -I/usr/local/src/php-5.4.20/Zend/ -DPHP_ATOM_INC - I/usr/local/src/php-5.4.20/include -I/usr/local/src/php-5.4.20/main - I/usr/local/src/php-5.4.20 -I/usr/local/src/php-5.4.20/ext/date/lib - I/usr/local/src/php-5.4.20/ext/ereg/regex -I/usr/include/libxml2 - I/usr/local/include -I/usr/local/include/freetype2 -I/usr/local/src/php- 5.4.20/ext/sqlite3/libsqlite -I/usr/local/src/php-5.4.20/TSRM - I/usr/local/src/php-5.4.20/Zend-I/usr/include -g -O2 -c /usr/local/src/php- 5.4.20/Zend/zend_language_scanner.c -o Zend/zend_language_scanner.lo In file included from Zend/zend_language_scanner.l:40: Zend/zend_language_parser.h:40:1: missing binary operator before token "extern" make: *** [Zend/zend_language_scanner.lo] Error 1 # bison -V bison (GNU Bison) 2.4.1 Previous Comments: [2013-10-01 15:54:53] m...@php.net Sorry for my ignorance, but (for me) 1.875 does not lie between 2.4 and 2.7 ---- [2013-10-01 15:47:58] pascal at nobus dot be I updated to bison-1.875 (compiled from source), but this didn't matter indeed. The problem appeared in php-5.4.19 and was not there in php-5.4.18. I could build it just fine from complete source tarball. [2013-10-01 15:35:25] m...@php.net If you build release tarballs, the bison version should not matter, though. ---- [2013-10-01 15:29:19] pascal at nobus dot be apologies for my previous post, I was on the wrong server # flex -V flex version 2.5.4 # bison -V bison (GNU Bison) 1.35 I'll try to get a later bison-version [2013-10-01 15:21:54] m...@php.net Looks like you have to use bison2.4 - 2.7 to build from a source checkout. 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 https://bugs.php.net/bug.php?id=65571 -- Edit this bug report at https://bugs.php.net/bug.php?id=65571&edit=1
Bug #65571 [Com]: Compiling fails with - missing binary operator before token "extern"
Edit report at https://bugs.php.net/bug.php?id=65571&edit=1 ID: 65571 Comment by: pascal at nobus dot be Reported by:tony dot ar dot wright at bt dot com Summary:Compiling fails with - missing binary operator before token "extern" Status: Not a bug Type: Bug Package:Compile Failure Operating System: SuSE 9 PHP Version:5.5.3 Block user comment: N Private report: N New Comment: That worked! Build complete. I've also tried your trick with the old bison (1.35), and that works also. Previous Comments: [2013-10-01 16:33:30] ni...@php.net @pascal: Could you try to do a `touch Zend/zend_language_parser.y` and then run `make` again? Likely the parser is not being regenerated, because it didn't change in the meantime. ---- [2013-10-01 16:27:01] pascal at nobus dot be I couldn't compile 2.7, so tried first the latest from the 1-version. Now I tried 2.4.1, which I could compile. However the problem stays the same. /bin/sh /usr/local/src/php-5.4.20/libtool --silent --preserve-dup-deps -- mode=compile cc -IZend/ -I/usr/local/src/php-5.4.20/Zend/ -DPHP_ATOM_INC - I/usr/local/src/php-5.4.20/include -I/usr/local/src/php-5.4.20/main - I/usr/local/src/php-5.4.20 -I/usr/local/src/php-5.4.20/ext/date/lib - I/usr/local/src/php-5.4.20/ext/ereg/regex -I/usr/include/libxml2 - I/usr/local/include -I/usr/local/include/freetype2 -I/usr/local/src/php- 5.4.20/ext/sqlite3/libsqlite -I/usr/local/src/php-5.4.20/TSRM - I/usr/local/src/php-5.4.20/Zend-I/usr/include -g -O2 -c /usr/local/src/php- 5.4.20/Zend/zend_language_scanner.c -o Zend/zend_language_scanner.lo In file included from Zend/zend_language_scanner.l:40: Zend/zend_language_parser.h:40:1: missing binary operator before token "extern" make: *** [Zend/zend_language_scanner.lo] Error 1 # bison -V bison (GNU Bison) 2.4.1 [2013-10-01 15:54:53] m...@php.net Sorry for my ignorance, but (for me) 1.875 does not lie between 2.4 and 2.7 ---- [2013-10-01 15:47:58] pascal at nobus dot be I updated to bison-1.875 (compiled from source), but this didn't matter indeed. The problem appeared in php-5.4.19 and was not there in php-5.4.18. I could build it just fine from complete source tarball. [2013-10-01 15:35:25] m...@php.net If you build release tarballs, the bison version should not matter, though. 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 https://bugs.php.net/bug.php?id=65571 -- Edit this bug report at https://bugs.php.net/bug.php?id=65571&edit=1
#39041 [NEW]: mail() not working?
From: pascal at tweakers dot net Operating system: FC4 PHP version: 5.1.6 PHP Bug Type: Mail related Bug description: mail() not working? Description: http://www.exim.org/bugzilla/show_bug.cgi?id=384 Here is all the info. Reproduce code: --- mail($email, $subject, $message, from); Expected result: Mail sended :) Actual result: -- http://directadmin.com/forum/showthread.php?s=&threadid=15175 -- Edit bug report at http://bugs.php.net/?id=39041&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39041&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39041&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39041&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39041&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39041&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39041&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39041&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39041&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39041&r=support Expected behavior:http://bugs.php.net/fix.php?id=39041&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39041&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39041&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39041&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39041&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39041&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39041&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39041&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39041&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39041&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39041&r=mysqlcfg
#39416 [NEW]: Milliseconds in date()
From: pascal at tweakers dot net Operating system: Fedora 4 PHP version: 5.2.0 PHP Bug Type: Feature/Change Request Bug description: Milliseconds in date() Description: I'm missing the option for milliseconds in the date()-function and others. Especially while generating unique identifiers for files it's very handy. Is it possible to integrate this option to the date()-method? Expected result: 2006-11-07 20:24:40:992 or someting like that? -- Edit bug report at http://bugs.php.net/?id=39416&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39416&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39416&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39416&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39416&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39416&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39416&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39416&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39416&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39416&r=support Expected behavior:http://bugs.php.net/fix.php?id=39416&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39416&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39416&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39416&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39416&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39416&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39416&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39416&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39416&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39416&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39416&r=mysqlcfg
#37201 [NEW]: *** glibc detected *** corrupted double-linked list: 0x08fe6750 ***
From: pascal at tweakers dot net Operating system: Fedora 3 PHP version: 4.4.2 PHP Bug Type: *Compile Issues Bug description: *** glibc detected *** corrupted double-linked list: 0x08fe6750 *** Description: Build complete. (It is safe to ignore warnings about tempnam and tmpnam). Make Complete Copying php.ini.. /usr/local/lib/php.ini already exists, skipping. Enabling register_globals... Increasing memory limit to 20M... Installing php... Installing PHP SAPI module: apache2handler /var/www/build/instdso.sh SH_LIBTOOL='/var/www/build/libtool' libphp4.la /usr/lib/apache /var/www/build/libtool --mode=install cp libphp4.la /usr/lib/apache/ cp .libs/libphp4.so /usr/lib/apache/libphp4.so cp .libs/libphp4.lai /usr/lib/apache/libphp4.la libtool: install: warning: remember to run `libtool --finish /usr/local/directadmin/customapache/php-4.4.2/libs' chmod 755 /usr/lib/apache/libphp4.so [activating module `php4' in /etc/httpd/conf/httpd.conf] Installing PHP CLI binary:/usr/local/bin/ Installing PHP CLI man page: /usr/local/man/man1/ Installing PEAR environment: /usr/local/lib/php/ [PEAR] Archive_Tar- already installed: 1.3.1 [PEAR] Console_Getopt - already installed: 1.2 [PEAR] HTML_Template_IT- already installed: 1.1.4 [PEAR] Net_UserAgent_Detect- already installed: 2.2.0 [PEAR] PEAR - already installed: 1.4.9 Wrote PEAR system config file at: /usr/local/etc/pear.conf You may want to add: /usr/local/lib/php to your php.ini include_path *** glibc detected *** corrupted double-linked list: 0x08fe6750 *** make[1]: *** [install-pear-packages] Aborted make: *** [install-pear] Error 2 The biggest problem is that fopen and fsockopen functions dont work. Reproduce code: --- #!/bin/sh ./configure \ --with-apxs2 \ --with-curl \ --with-curl-dir=/usr/local/lib \ --with-gd \ --with-gd-dir=/usr/local/lib \ --with-gettext \ --with-freetype-dir=/usr/include/freetype2 \ --with-jpeg-dir=/usr/local/lib \ --with-kerberos \ --with-mcrypt \ --with-mhash \ --with-mysql=/usr \ --with-png-dir=/usr/local/lib \ --with-xml \ --with-openssl \ --with-dom \ --with-pear \ --with-zlib \ --with-zlib-dir=/usr/local/lib \ --with-zip \ --with-imap \ --with-imap-ssl \ --enable-exif \ --enable-bcmath \ --enable-calendar \ --enable-ftp \ --enable-magic-quotes \ --enable-sockets \ --enable-track-vars \ --enable-mbstring \ --enable-memory-limit Apache/2.0.55 (Unix) mod_perl/1.99_17-dev Perl/v5.8.5 mod_ssl/2.0.55 OpenSSL/0.9.7a PHP/4.4.2 FrontPage/5.0.2.2634 Expected result: No error :) -- Edit bug report at http://bugs.php.net/?id=37201&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=37201&r=trysnapshot44 Try a CVS snapshot (PHP 5.1): http://bugs.php.net/fix.php?id=37201&r=trysnapshot51 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=37201&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=37201&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=37201&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=37201&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=37201&r=needscript Try newer version:http://bugs.php.net/fix.php?id=37201&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=37201&r=support Expected behavior:http://bugs.php.net/fix.php?id=37201&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=37201&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=37201&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=37201&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37201&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=37201&r=dst IIS Stability:http://bugs.php.net/fix.php?id=37201&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=37201&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=37201&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=37201&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=37201&r=mysqlcfg
#37201 [Fbk->Opn]: *** glibc detected *** corrupted double-linked list: 0x08fe6750 ***
ID: 37201 User updated by: pascal at tweakers dot net Reported By: pascal at tweakers dot net -Status: Feedback +Status: Open Bug Type: *Compile Issues Operating System: Fedora 3 PHP Version: 4.4.2 New Comment: I tryed the snapshot and no succes... Even gave 4.4.1 a try and boom, same error. Then removed some extensions and this is the latest build command: './configure' '--with-apxs2' '--with-curl' '--with-curl-dir=/usr/local/lib' '--with-gd' '--with-gd-dir=/usr/local/lib' '--with-gettext' '--with-jpeg-dir=/usr/local/lib' '--with-kerberos' '--with-mcrypt' '--with-mhash' '--with-mysql=/usr' '--with-png-dir=/usr/local/lib' '--with-xml' '--with-pear' '--with-zlib' '--with-zlib-dir=/usr/local/lib' '--with-zip' '--with-imap' '--with-imap-ssl' '--enable-exif' '--enable-bcmath' '--enable-calendar' '--enable-ftp' '--enable-magic-quotes' '--enable-sockets' '--enable-track-vars' '--enable-mbstring' '--enable-memory-limit' Still fopen and fsockopen failes... failed to open stream: HTTP request failed! PHP release: 4.4.2 Allow_url_fopen is set to: "1" The list of disabled functions is "" Previous Comments: ---- [2006-04-25 16:06:11] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2006-04-25 15:57:42] pascal at tweakers dot net Description: Build complete. (It is safe to ignore warnings about tempnam and tmpnam). Make Complete Copying php.ini.. /usr/local/lib/php.ini already exists, skipping. Enabling register_globals... Increasing memory limit to 20M... Installing php... Installing PHP SAPI module: apache2handler /var/www/build/instdso.sh SH_LIBTOOL='/var/www/build/libtool' libphp4.la /usr/lib/apache /var/www/build/libtool --mode=install cp libphp4.la /usr/lib/apache/ cp .libs/libphp4.so /usr/lib/apache/libphp4.so cp .libs/libphp4.lai /usr/lib/apache/libphp4.la libtool: install: warning: remember to run `libtool --finish /usr/local/directadmin/customapache/php-4.4.2/libs' chmod 755 /usr/lib/apache/libphp4.so [activating module `php4' in /etc/httpd/conf/httpd.conf] Installing PHP CLI binary:/usr/local/bin/ Installing PHP CLI man page: /usr/local/man/man1/ Installing PEAR environment: /usr/local/lib/php/ [PEAR] Archive_Tar- already installed: 1.3.1 [PEAR] Console_Getopt - already installed: 1.2 [PEAR] HTML_Template_IT- already installed: 1.1.4 [PEAR] Net_UserAgent_Detect- already installed: 2.2.0 [PEAR] PEAR - already installed: 1.4.9 Wrote PEAR system config file at: /usr/local/etc/pear.conf You may want to add: /usr/local/lib/php to your php.ini include_path *** glibc detected *** corrupted double-linked list: 0x08fe6750 *** make[1]: *** [install-pear-packages] Aborted make: *** [install-pear] Error 2 The biggest problem is that fopen and fsockopen functions dont work. Reproduce code: --- #!/bin/sh ./configure \ --with-apxs2 \ --with-curl \ --with-curl-dir=/usr/local/lib \ --with-gd \ --with-gd-dir=/usr/local/lib \ --with-gettext \ --with-freetype-dir=/usr/include/freetype2 \ --with-jpeg-dir=/usr/local/lib \ --with-kerberos \ --with-mcrypt \ --with-mhash \ --with-mysql=/usr \ --with-png-dir=/usr/local/lib \ --with-xml \ --with-openssl \ --with-dom \ --with-pear \ --with-zlib \ --with-zlib-dir=/usr/local/lib \ --with-zip \ --with-imap \ --with-imap-ssl \ --enable-exif \ --enable-bcmath \ --enable-calendar \ --enable-ftp \ --enable-magic-quotes \ --enable-sockets \ --enable-track-vars \ --enable-mbstring \ --enable-memory-limit Apache/2.0.55 (Unix) mod_perl/1.99_17-dev Perl/v5.8.5 mod_ssl/2.0.55 OpenSSL/0.9.7a PHP/4.4.2 FrontPage/5.0.2.2634 Expected result: No error :) -- Edit this bug report at http://bugs.php.net/?id=37201&edit=1
[PHP-BUG] Bug #63286 [NEW]: in_array returns false on the $_COOKIE array when the cookie name exists
From: pascal at niele dot nl Operating system: debian PHP version: Irrelevant Package: Arrays related Bug Type: Bug Bug description:in_array returns false on the $_COOKIE array when the cookie name exists Description: --- >From manual page: http://www.php.net/function.setcookie --- The in_array($cookieName, $_COOKIE) always returns false even if the $cookieName exists in the $_COOKIE array Test script: --- Note: When checking if a cookie exist, the in_array() does not work on the $_COOKIE array, you should isset() to check if the cookie exists. string(9) "testValue" } var_dump(isset($_COOKIE[$name])); // output: bool(true) var_dump(in_array($name, $_COOKIE)); // does not work as aspected !!! // ouput: bool(false) echo $_COOKIE[$name]; // output: testValue ?> Expected result: return true on the in_array($cookieName, $_COOKIE) if the $cookieName exists in the $_COOKIE array -- Edit bug report at https://bugs.php.net/bug.php?id=63286&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63286&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63286&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63286&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63286&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63286&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63286&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63286&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63286&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63286&r=support Expected behavior: https://bugs.php.net/fix.php?id=63286&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63286&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63286&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63286&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63286&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63286&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63286&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63286&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63286&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63286&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63286&r=mysqlcfg
#26286 [Com]: Parent: child process exited with status 3221225477 -- Restarting
ID: 26286 Comment by: pascal dot court at bluewin dot ch Reported By: igg10 at alu dot ua dot es Status: No Feedback Bug Type: Apache2 related Operating System: Windows 2000 PHP Version: 4.3.4 New Comment: I have exactly the same problem. I use Windows XP French SP2 Apache 2.0.52 PHP 4.3.9 Previous Comments: [2004-11-16 12:38:10] php_bug at cklowe dot com There is a syndrome of bugs here. http://www.google.com/search?q=+site:bugs.php.net+3221225477 reports 47 hits. 3221225477 equates to 0xC005 . Could this be Zend bailing out? [2004-11-08 17:22:27] cpuidle at gmx dot de Same issue for me, happend when running Mantis 0.19.0 against PHP 5.0.1: [Mon Nov 08 17:18:56 2004] [notice] Parent: Created child process 3080 [Mon Nov 08 17:18:58 2004] [notice] Child 3080: Child process is running [Mon Nov 08 17:18:58 2004] [notice] Child 3080: Acquired the start mutex. [Mon Nov 08 17:18:58 2004] [notice] Child 3080: Starting 20 worker threads. [Mon Nov 08 17:19:07 2004] [notice] Parent: child process exited with status 3221225477 -- Restarting. [2004-10-15 14:52:00] jonathan at schwarzelan dot de As said for bug 25570, to me it seems they are kind of related - having a large 2d-array, just filling it with data (140x4 each about 100chars) results to Apache2.0.50 to crash (php 5.0.2, aswell as 5.1.0-dev) on W2k and WXP Trying outputting the generated Data leads to bug 25570 - [2004-10-06 20:29:54] daukan at thelastgate dot com winxp pro sp2 apache 2 php 5.0.0 After I change all the bcpow() functions to pow() it hasn't crashed. example: if(rand(1,10)+bcpow($pstat,2) > rand(1,8)+bpow($estat,2)) to if(rand(1,10)+pow($pstat,2) > rand(1,8)+pow($estat,2)) [2004-09-26 17:24:25] ordghio at trava dot lv Two Win2k servers with Apache 2.0.50 and PHP 5.0.2 after function getmicrotime() call - error with this string in error.log: Parent: child process exited with status 3221225477 -- Restarting back to 4.3.9 - all works fine 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/26286 -- Edit this bug report at http://bugs.php.net/?id=26286&edit=1
[PHP-BUG] Bug #65361 [NEW]: Transliteration has uppercase problems with letter J in Serbian
From: pascal dot chevrel at free dot fr Operating system: Linux PHP version: 5.5.1 Package: Unicode Engine related Bug Type: Bug Bug description:Transliteration has uppercase problems with letter J in Serbian Description: The transliterator class does not work well when converting from Cyrillic Serbian to Latin Script Serbian. All the j letters in cyrillic are systematically converted to uppercase J in latin-script serbian while it should be lowercase j inside a word. Online conversion tools probably also based on ICU don't have this bug and do the conversion correctly. I am attaching a code sample that shows that bug. I tested that the bug exists in both PHP 5.4 and 5.5 Thanks! Test script: --- ' . 'Cyrillic source: ' . $source . '' . 'Expected transliteration: Najgledaniji sajtovi' . 'Actual transliteration: ' . $t->transliterate($source) . '' . ''; Expected result: This string : ÐаÑгледаниÑи ÑаÑÑови Should be transliterated to: Najgledaniji sajtovi Actual result: -- But PHP transliterates it to: NaJgledaniJi saJtovi -- Edit bug report at https://bugs.php.net/bug.php?id=65361&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65361&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65361&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65361&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65361&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65361&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65361&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65361&r=needscript Try newer version: https://bugs.php.net/fix.php?id=65361&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65361&r=support Expected behavior: https://bugs.php.net/fix.php?id=65361&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65361&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65361&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65361&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65361&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65361&r=dst IIS Stability: https://bugs.php.net/fix.php?id=65361&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65361&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65361&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65361&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65361&r=mysqlcfg
Bug #65361 [Fbk->Opn]: Transliteration has uppercase problems with letter J in Serbian
Edit report at https://bugs.php.net/bug.php?id=65361&edit=1 ID: 65361 User updated by:pascal dot chevrel at free dot fr Reported by:pascal dot chevrel at free dot fr Summary:Transliteration has uppercase problems with letter J in Serbian -Status: Feedback +Status: Open Type: Bug Package:Unicode Engine related Operating System: Linux PHP Version:5.5.1 Block user comment: N Private report: N New Comment: All my sources are in utf8, I rechecked with the isutf8 bash command. Previous Comments: [2013-07-30 16:43:45] a...@php.net Is your source cyrillic string UTF-8 encoded? No idea how to encode otherwise, but with UTF-8 source it gives the translit you expect. So that might be the key. [2013-07-30 14:44:15] pascal dot chevrel at free dot fr Description: The transliterator class does not work well when converting from Cyrillic Serbian to Latin Script Serbian. All the j letters in cyrillic are systematically converted to uppercase J in latin-script serbian while it should be lowercase j inside a word. Online conversion tools probably also based on ICU don't have this bug and do the conversion correctly. I am attaching a code sample that shows that bug. I tested that the bug exists in both PHP 5.4 and 5.5 Thanks! Test script: --- ' . 'Cyrillic source: ' . $source . '' . 'Expected transliteration: Najgledaniji sajtovi' . 'Actual transliteration: ' . $t->transliterate($source) . '' . ''; Expected result: This string : ÐаÑгледаниÑи ÑаÑÑови Should be transliterated to: Najgledaniji sajtovi Actual result: -- But PHP transliterates it to: NaJgledaniJi saJtovi -- Edit this bug report at https://bugs.php.net/bug.php?id=65361&edit=1
Bug #65361 [Fbk->Opn]: Transliteration has uppercase problems with letter J in Serbian
Edit report at https://bugs.php.net/bug.php?id=65361&edit=1 ID: 65361 User updated by:pascal dot chevrel at free dot fr Reported by:pascal dot chevrel at free dot fr Summary:Transliteration has uppercase problems with letter J in Serbian -Status: Feedback +Status: Open Type: Bug Package:Unicode Engine related Operating System: Linux PHP Version:5.5.1 Block user comment: N Private report: N New Comment: "but with UTF-8 source it gives the translit you expect" That's not the case for me, do you have an example online showing my example working? A gist on github for example. Previous Comments: [2013-07-30 17:16:30] a...@php.net Ok, then it has to be ICU itself. I was testing on windows previously which has ICU 50, but ubuntu 13.04 ships with ICU 48 and I can repro what you say there. Which ICU version do you use? Most linux distros have 48 at the time. May be you could try a newer ICU, even 51? But even now from what I can see it's unlikely a PHP bug. Thanks. ---- [2013-07-30 16:49:20] pascal dot chevrel at free dot fr All my sources are in utf8, I rechecked with the isutf8 bash command. [2013-07-30 16:43:45] a...@php.net Is your source cyrillic string UTF-8 encoded? No idea how to encode otherwise, but with UTF-8 source it gives the translit you expect. So that might be the key. ---- [2013-07-30 14:44:15] pascal dot chevrel at free dot fr Description: The transliterator class does not work well when converting from Cyrillic Serbian to Latin Script Serbian. All the j letters in cyrillic are systematically converted to uppercase J in latin-script serbian while it should be lowercase j inside a word. Online conversion tools probably also based on ICU don't have this bug and do the conversion correctly. I am attaching a code sample that shows that bug. I tested that the bug exists in both PHP 5.4 and 5.5 Thanks! Test script: --- ' . 'Cyrillic source: ' . $source . '' . 'Expected transliteration: Najgledaniji sajtovi' . 'Actual transliteration: ' . $t->transliterate($source) . '' . ''; Expected result: This string : ÐаÑгледаниÑи ÑаÑÑови Should be transliterated to: Najgledaniji sajtovi Actual result: -- But PHP transliterates it to: NaJgledaniJi saJtovi -- Edit this bug report at https://bugs.php.net/bug.php?id=65361&edit=1
Bug #65361 [Opn]: Transliteration has uppercase problems with letter J in Serbian
Edit report at https://bugs.php.net/bug.php?id=65361&edit=1 ID: 65361 User updated by:pascal dot chevrel at free dot fr Reported by:pascal dot chevrel at free dot fr Summary:Transliteration has uppercase problems with letter J in Serbian Status: Open Type: Bug Package:Unicode Engine related Operating System: Linux PHP Version:5.5.1 Block user comment: N Private report: N New Comment: >Ok, then it has to be ICU itself. I was testing on windows previously which >has ICU 50, but ubuntu 13.04 ships with ICU 48 and I can repro what you say >there. > Which ICU version do you use? Most linux distros have 48 at the time. May be > you could try a newer ICU, even 51? But even now from what I can see it's > unlikely a PHP bug. Phpinfo() indicates that the ICU version is 4.8.1.1, I confess I don't know how to upgrade it to a newer version to test. Previous Comments: -------- [2013-07-30 17:17:16] pascal dot chevrel at free dot fr "but with UTF-8 source it gives the translit you expect" That's not the case for me, do you have an example online showing my example working? A gist on github for example. [2013-07-30 17:16:30] a...@php.net Ok, then it has to be ICU itself. I was testing on windows previously which has ICU 50, but ubuntu 13.04 ships with ICU 48 and I can repro what you say there. Which ICU version do you use? Most linux distros have 48 at the time. May be you could try a newer ICU, even 51? But even now from what I can see it's unlikely a PHP bug. Thanks. -------- [2013-07-30 16:49:20] pascal dot chevrel at free dot fr All my sources are in utf8, I rechecked with the isutf8 bash command. [2013-07-30 16:43:45] a...@php.net Is your source cyrillic string UTF-8 encoded? No idea how to encode otherwise, but with UTF-8 source it gives the translit you expect. So that might be the key. -------- [2013-07-30 14:44:15] pascal dot chevrel at free dot fr Description: The transliterator class does not work well when converting from Cyrillic Serbian to Latin Script Serbian. All the j letters in cyrillic are systematically converted to uppercase J in latin-script serbian while it should be lowercase j inside a word. Online conversion tools probably also based on ICU don't have this bug and do the conversion correctly. I am attaching a code sample that shows that bug. I tested that the bug exists in both PHP 5.4 and 5.5 Thanks! Test script: --- ' . 'Cyrillic source: ' . $source . '' . 'Expected transliteration: Najgledaniji sajtovi' . 'Actual transliteration: ' . $t->transliterate($source) . '' . ''; Expected result: This string : ÐаÑгледаниÑи ÑаÑÑови Should be transliterated to: Najgledaniji sajtovi Actual result: -- But PHP transliterates it to: NaJgledaniJi saJtovi -- Edit this bug report at https://bugs.php.net/bug.php?id=65361&edit=1
Bug #65361 [Com]: Transliteration has uppercase problems with letter J in Serbian
Edit report at https://bugs.php.net/bug.php?id=65361&edit=1 ID: 65361 Comment by: pascal dot chevrel at free dot fr Reported by:pascal dot chevrel at free dot fr Summary:Transliteration has uppercase problems with letter J in Serbian Status: Not a bug Type: Bug Package:Unicode Engine related Operating System: Linux PHP Version:5.5.1 Block user comment: N Private report: N New Comment: I compiled the ICU library with 51.2 source and indeed the bug is no longer there. Too bad Linux distros don't ship a newer version as it makes the transliteration feature a no go in practice. Thanks a lot for your time on this! Previous Comments: [2013-07-30 17:44:27] a...@php.net Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. I've just tried with ICU51 on Ubuntu and it works correct. So this is ICU48, and I'd expect ICU50 to work, too. You'll need to compile ICU yourself and then link PHP with it. Or maybe get the PECL variant, build it with newer ICU and use with your regular PHP. That should work. [2013-07-30 17:26:57] a...@php.net I didn't say source, but "source cyrillic string UTF-8 encoded" ... well, that might be nearly the same :) I'm not going to expose my dev laptop on the net, anyway the snippet you've posted is all i've tried anyway. Windows ICU50 works as you expect to be correct, ubuntu ICU48 the erroneous behaviour you describe is reproduceable. So please try never ICU, that could be it. ---- [2013-07-30 17:22:02] pascal dot chevrel at free dot fr >Ok, then it has to be ICU itself. I was testing on windows previously which >has ICU 50, but ubuntu 13.04 ships with ICU 48 and I can repro what you say >there. > Which ICU version do you use? Most linux distros have 48 at the time. May be > you could try a newer ICU, even 51? But even now from what I can see it's > unlikely a PHP bug. Phpinfo() indicates that the ICU version is 4.8.1.1, I confess I don't know how to upgrade it to a newer version to test. ---- [2013-07-30 17:17:16] pascal dot chevrel at free dot fr "but with UTF-8 source it gives the translit you expect" That's not the case for me, do you have an example online showing my example working? A gist on github for example. [2013-07-30 17:16:30] a...@php.net Ok, then it has to be ICU itself. I was testing on windows previously which has ICU 50, but ubuntu 13.04 ships with ICU 48 and I can repro what you say there. Which ICU version do you use? Most linux distros have 48 at the time. May be you could try a newer ICU, even 51? But even now from what I can see it's unlikely a PHP bug. Thanks. 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 https://bugs.php.net/bug.php?id=65361 -- Edit this bug report at https://bugs.php.net/bug.php?id=65361&edit=1
[PHP-BUG] Req #62700 [NEW]: have the console output 'Listening on http://localhost:8000' (note http://)
From: pascal dot chevrel at free dot fr Operating system: Linux Ubuntu 12.04 PHP version: 5.4.5 Package: Built-in web server Bug Type: Feature/Change Request Bug description:have the console output 'Listening on http://localhost:8000' (note http://) Description: Currently when you launch the built-in web server (which is great btw!), the console outputs something like: $ php -S localhost:8000 PHP 5.4.4-1~precise+1 Development Server started at Tue Jul 31 09:51:09 2012 Listening on localhost:8000 Document root is /home/pascalc/junk/transvision/web2 Press Ctrl-C to quit. There is no http:// before localhost:8000, which means that my console is not converting that into a clickable link, it would be nice to have the http:// added like Python does. Thanks -- Edit bug report at https://bugs.php.net/bug.php?id=62700&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62700&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62700&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62700&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62700&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62700&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62700&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62700&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62700&r=needscript Try newer version: https://bugs.php.net/fix.php?id=62700&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62700&r=support Expected behavior: https://bugs.php.net/fix.php?id=62700&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62700&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62700&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62700&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62700&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62700&r=dst IIS Stability: https://bugs.php.net/fix.php?id=62700&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=62700&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=62700&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=62700&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=62700&r=mysqlcfg
Req #62700 [Com]: have the console output 'Listening on http://localhost:8000' (note http://)
Edit report at https://bugs.php.net/bug.php?id=62700&edit=1 ID: 62700 Comment by: pascal dot chevrel at free dot fr Reported by:pascal dot chevrel at free dot fr Summary:have the console output 'Listening on http://localhost:8000' (note http://) Status: Assigned Type: Feature/Change Request Package:Built-in web server Operating System: Linux Ubuntu 12.04 PHP Version:5.4.5 Assigned To:laruence Block user comment: N Private report: N New Comment: I attached a patch that may solve the issue Previous Comments: [2012-07-31 08:03:03] pascal dot chevrel at free dot fr Description: Currently when you launch the built-in web server (which is great btw!), the console outputs something like: $ php -S localhost:8000 PHP 5.4.4-1~precise+1 Development Server started at Tue Jul 31 09:51:09 2012 Listening on localhost:8000 Document root is /home/pascalc/junk/transvision/web2 Press Ctrl-C to quit. There is no http:// before localhost:8000, which means that my console is not converting that into a clickable link, it would be nice to have the http:// added like Python does. Thanks -- Edit this bug report at https://bugs.php.net/bug.php?id=62700&edit=1
#43280 [NEW]: apache segfault on php as module and doesnt serve content correctly
From: pascal dot tempier at laposte dot net Operating system: gentoo PHP version: 5.2.5 PHP Bug Type: Reproducible crash Bug description: apache segfault on php as module and doesnt serve content correctly Description: apache segfault when php is used as module , not when used in cli or as cgi. same result , at least for the crash on 3 different php5 versions i tried including 5.2.5, including 5.2.5 with the bar minimum of features/modules enabled and all debug i could enabled as well. the issue doesn t happen when the php module isn t loaded there s bug that sounds a bit like mine but i tried APACHE2_OPTS="-D DEFAULT_VHOST -D PHP5 -D USERDIR" instead of APACHE2_OPTS="-D USERDIR -D SUEXEC -D DEFAULT_VHOST -D INFO -D LANGUAGE -D SSL -D SSL_DEFAULT_VHOST -D PHP5" and it still crashed Reproduce code: --- just try to access any php file via apache to get a crash try to access any other file to get some error Expected result: i wanted my page to be displayed ? Actual result: -- [Tue Nov 13 21:59:44 2007] [notice] child pid 8799 exit signal Segmentation fault (11) [Tue Nov 13 21:59:45 2007] [notice] child pid 8800 exit signal Segmentation fault (11) [Tue Nov 13 21:59:50 2007] [notice] child pid 8801 exit signal Segmentation fault (11) [Tue Nov 13 21:59:58 2007] [notice] child pid 8802 exit signal Segmentation fault (11) # Load the module first LoadModule php5_modulemodules/libphp5.so # Set it to handle the files AddType application/x-httpd-php .php AddType application/x-httpd-php .phtml AddType application/x-httpd-php .php3 AddType application/x-httpd-php .php4 AddType application/x-httpd-php .php5 AddType application/x-httpd-php-source .phps AddDirectoryIndex index.php index.phtml APACHE2_OPTS="-D USERDIR -D SUEXEC -D DEFAULT_VHOST -D INFO -D LANGUAGE -D SSL -D SSL_DEFAULT_VHOST -D PHP5" Reading symbols from /usr/lib/libgnutls.so.13...done. Loaded symbols for /usr/lib/libgnutls.so.13 Reading symbols from /usr/lib/libtasn1.so.3...done. Loaded symbols for /usr/lib/libtasn1.so.3 Failed to read a valid object file image from memory. 0xe410 in ?? () (gdb) continue Continuing. Program received signal SIGSEGV, Segmentation fault. 0xb73bc65d in php_handler (r=0x83e23d0) at /var/tmp/portage/dev-lang/php-5.2.5/work/php-5.2.5/sapi/apache2handler/sapi_apache2.c:512 512 conf = ap_get_module_config(r->per_dir_config, &php5_module) Loaded symbols for /lib/libgpm.so.1 Reading symbols from /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libstdc++.so.6...done. Loaded symbols for /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libstdc++.so.6 Reading symbols from /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgcc_s.so.1...done. Loaded symbols for /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgcc_s.so.1 Reading symbols from /usr/lib/libkrb5support.so.0...done. Loaded symbols for /usr/lib/libkrb5support.so.0 Reading symbols from /usr/lib/libgnutls.so.13...done. Loaded symbols for /usr/lib/libgnutls.so.13 Reading symbols from /usr/lib/libtasn1.so.3...done. Loaded symbols for /usr/lib/libtasn1.so.3 Failed to read a valid object file image from memory. 0xe410 in ?? () (gdb) continue Continuing. Program received signal SIGSEGV, Segmentation fault. 0xb745265d in php_handler (r=0x83e23d0) at /var/tmp/portage/dev-lang/php-5.2.5/work/php-5.2.5/sapi/apache2handler/sapi_apache2.c:512 512 /var/tmp/portage/dev-lang/php-5.2.5/work/php-5.2.5/sapi/apache2handler/sapi_apache2.c: No such file or directory. in /var/tmp/portage/dev-lang/php-5.2.5/work/php-5.2.5/sapi/apache2handler/sapi_apache2.c (gdb) bt #0 0xb745265d in php_handler (r=0x83e23d0) at /var/tmp/portage/dev-lang/php-5.2.5/work/php-5.2.5/sapi/apache2handler/sapi_apache2.c:512 #1 0x080791f7 in ap_run_handler (r=0x83e23d0) at config.c:157 #2 0x0807c357 in ap_invoke_handler (r=0x83e23d0) at config.c:372 #3 0x08087148 in ap_process_request (r=0x83e23d0) at http_request.c:258 #4 0x080843db in ap_process_http_connection (c=0x83dc380) at http_core.c:184 #5 0x08080067 in ap_run_process_connection (c=0x83dc380) at connection.c:43 #6 0x0808b280 in child_main (child_num_arg=) at prefork.c:640 #7 0x0808b573 in make_child (s=0x80a5f48, slot=0) at prefork.c:736 #8 0x0808b622 in startup_children (number_to_start=1) at prefork.c:754 #9 0x0808c49a in ap_mpm_run (_pconf=0x80a40a8, plog=0x80d2160, s=0x80a5f48) at prefork.c:975 #10 0x08066e1c in main (argc=134881440, argv=0x83da1a8) at main.c:730 -- Edit bug report at http://bugs.php.net/?id=43280&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43280&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43280&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://
#43280 [Opn]: apache segfault on php as module and doesnt serve content correctly
ID: 43280 User updated by: pascal dot tempier at laposte dot net Reported By: pascal dot tempier at laposte dot net Status: Open Bug Type: Reproducible crash Operating System: gentoo PHP Version: 5.2.5 New Comment: The first bt i had #8 0x in ?? () #9 0x in ?? () #10 0xbfd4f704 in ?? () #11 0xbfd4f700 in ?? () #12 0x in ?? () (gdb) continue Continuing. Program received signal SIGSEGV, Segmentation fault. 0xb73fb65d in php_handler (r=0x83e53e0) at /var/tmp/portage/dev-lang/php-5.2.5/work/php-5.2.5/sapi/apache2handler/sapi_apache2.c:512 512 /var/tmp/portage/dev-lang/php-5.2.5/work/php-5.2.5/sapi/apache2handler/sapi_apache2.c: No such file or directory. in /var/tmp/portage/dev-lang/php-5.2.5/work/php-5.2.5/sapi/apache2handler/sapi_apache2.c (gdb) bt #0 0xb73fb65d in php_handler (r=0x83e53e0) at /var/tmp/portage/dev-lang/php-5.2.5/work/php-5.2.5/sapi/apache2handler/sapi_apache2.c:512 #1 0x08078e07 in ap_run_handler () #2 0x0807bef7 in ap_invoke_handler () #3 0x08086ac8 in ap_process_request () #4 0x08083dab in ?? () #5 0x083e53e0 in ?? () #6 0x0004 in ?? () #7 0x083e53e0 in ?? () #8 0x in ?? () Previous Comments: [2007-11-13 21:26:37] pascal dot tempier at laposte dot net Description: apache segfault when php is used as module , not when used in cli or as cgi. same result , at least for the crash on 3 different php5 versions i tried including 5.2.5, including 5.2.5 with the bar minimum of features/modules enabled and all debug i could enabled as well. the issue doesn t happen when the php module isn t loaded there s bug that sounds a bit like mine but i tried APACHE2_OPTS="-D DEFAULT_VHOST -D PHP5 -D USERDIR" instead of APACHE2_OPTS="-D USERDIR -D SUEXEC -D DEFAULT_VHOST -D INFO -D LANGUAGE -D SSL -D SSL_DEFAULT_VHOST -D PHP5" and it still crashed Reproduce code: --- just try to access any php file via apache to get a crash try to access any other file to get some error Expected result: i wanted my page to be displayed ? Actual result: -- [Tue Nov 13 21:59:44 2007] [notice] child pid 8799 exit signal Segmentation fault (11) [Tue Nov 13 21:59:45 2007] [notice] child pid 8800 exit signal Segmentation fault (11) [Tue Nov 13 21:59:50 2007] [notice] child pid 8801 exit signal Segmentation fault (11) [Tue Nov 13 21:59:58 2007] [notice] child pid 8802 exit signal Segmentation fault (11) # Load the module first LoadModule php5_modulemodules/libphp5.so # Set it to handle the files AddType application/x-httpd-php .php AddType application/x-httpd-php .phtml AddType application/x-httpd-php .php3 AddType application/x-httpd-php .php4 AddType application/x-httpd-php .php5 AddType application/x-httpd-php-source .phps AddDirectoryIndex index.php index.phtml APACHE2_OPTS="-D USERDIR -D SUEXEC -D DEFAULT_VHOST -D INFO -D LANGUAGE -D SSL -D SSL_DEFAULT_VHOST -D PHP5" Reading symbols from /usr/lib/libgnutls.so.13...done. Loaded symbols for /usr/lib/libgnutls.so.13 Reading symbols from /usr/lib/libtasn1.so.3...done. Loaded symbols for /usr/lib/libtasn1.so.3 Failed to read a valid object file image from memory. 0xe410 in ?? () (gdb) continue Continuing. Program received signal SIGSEGV, Segmentation fault. 0xb73bc65d in php_handler (r=0x83e23d0) at /var/tmp/portage/dev-lang/php-5.2.5/work/php-5.2.5/sapi/apache2handler/sapi_apache2.c:512 512 conf = ap_get_module_config(r->per_dir_config, &php5_module) Loaded symbols for /lib/libgpm.so.1 Reading symbols from /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libstdc++.so.6...done. Loaded symbols for /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libstdc++.so.6 Reading symbols from /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgcc_s.so.1...done. Loaded symbols for /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgcc_s.so.1 Reading symbols from /usr/lib/libkrb5support.so.0...done. Loaded symbols for /usr/lib/libkrb5support.so.0 Reading symbols from /usr/lib/libgnutls.so.13...done. Loaded symbols for /usr/lib/libgnutls.so.13 Reading symbols from /usr/lib/libtasn1.so.3...done. Loaded symbols for /usr/lib/libtasn1.so.3 Failed to read a valid object file image from memory. 0xe410 in ?? () (gdb) continue Continuing. Program received signal SIGSEGV, Segmentation fault. 0xb745265d in php_handler (r=0x83e23d0) at /var/tmp/portage/dev-lang/php-5.2.5/work/php-5.2.5/sapi/apache2handler/sapi_apache2.c:512 512 /var/tmp/portage/dev-lang/php-5.2.5/work/php-5.2.5/sapi/apache2handler/sapi_apache2.c: No such file or directory. in /var/tmp/portage/dev-lang/php-5.2.5/work/php-5.2.5/sapi/apache2handler/sapi_apache2.c (gdb) b
#39299 [NEW]: xsl:key macth attribute fails with $variable
From: pascal dot heus at gmail dot com Operating system: GNU/Linux PHP version: 5.1.6 PHP Bug Type: XSLT related Bug description: xsl:key macth attribute fails with $variable Description: The following xsl code works fine with the Sablotron engine under pHp4 or with XMLSpy: When using libxslt under pHp 5, it fails to execute. The problem comes form the $program-id variable used in the match= attribute. If I replace it with a hard coded value, the XSLT works fine: This is under pHp 5.0.4 running on an institutional server, I don't have the authority to upgrade that system for further testing. Reproduce code: --- You can retrieve the xslt and xml file at: http://scs.gmu.edu/~rgomez/qc/xml/gmu_program_schedule_bug.xslt http://scs.gmu.edu/~rgomez/qc/xml/gmu.xml -- Edit bug report at http://bugs.php.net/?id=39299&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39299&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39299&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39299&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39299&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39299&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39299&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39299&r=needscript Try newer version:http://bugs.php.net/fix.php?id=39299&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39299&r=support Expected behavior:http://bugs.php.net/fix.php?id=39299&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39299&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39299&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39299&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39299&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39299&r=dst IIS Stability:http://bugs.php.net/fix.php?id=39299&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39299&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39299&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39299&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39299&r=mysqlcfg
#39299 [Fbk->Opn]: xsl:key macth attribute fails with $variable
ID: 39299
User updated by: pascal dot heus at gmail dot com
Reported By: pascal dot heus at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: XSLT related
Operating System: GNU/Linux
PHP Version: 5.1.6
New Comment:
load('http://scs.gmu.edu/~rgomez/qc/xml/gmu.xml');
$xslDom = new DomDocument();
// Comment/uncomment lines below to select XSLT file
$xsl =
'http://scs.gmu.edu/~rgomez/qc/xml/gmu_program_schedule_bug_fails.xslt';
//$xsl =
'http://scs.gmu.edu/~rgomez/qc/xml/gmu_program_schedule_bug_works.xslt';
echo "Using $xsl";
$xslDom->load($xsl);
$proc = new XsltProcessor();
$xslDom = $proc->importStylesheet($xslDom);
$outputDom = $proc->transformToDoc($xmlDom);
echo $outputDom->saveHTML();
?>
Previous Comments:
[2006-10-29 17:18:46] [EMAIL PROTECTED]
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.
----
[2006-10-29 15:24:51] pascal dot heus at gmail dot com
Description:
The following xsl code works fine with the Sablotron engine under pHp4
or with XMLSpy:
When using libxslt under pHp 5, it fails to execute.
The problem comes form the $program-id variable used in the match=
attribute. If I replace it with a hard coded value, the XSLT works
fine:
This is under pHp 5.0.4 running on an institutional server, I don't
have the authority to upgrade that system for further testing.
Reproduce code:
---
You can retrieve the xslt and xml file at:
http://scs.gmu.edu/~rgomez/qc/xml/gmu_program_schedule_bug.xslt
http://scs.gmu.edu/~rgomez/qc/xml/gmu.xml
--
Edit this bug report at http://bugs.php.net/?id=39299&edit=1
#39299 [Opn]: Using a xsl variable in a xsl:key macth attribute does not work
ID: 39299
User updated by: pascal dot heus at gmail dot com
-Summary: xsl:key macth attribute fails with $variable
Reported By: pascal dot heus at gmail dot com
Status: Open
Bug Type: XSLT related
Operating System: GNU/Linux
PHP Version: 5.1.6
New Comment:
I guess we're both individuals with little time and varying moods.
Agree it's actually likely to be a libxslt problem, I may try to report
it there.
If someone else ever reports something like this not working:
you know where it comes from: can't use a $variable in the match=""
attribute.
Have a nice day/night and thanks for making pHp such great product.
Previous Comments:
[2006-10-30 08:13:04] [EMAIL PROTECTED]
I don't even know, what's your expected output and I'm not in the mood
(nor do i have the time) to analyse your xslt.
Please provide a as small as possible script/xslts and tell me, what
your expected output is and what you get.
But at the end, I doubt it's a php issue, but a libxslt one, so you may
better go there directly (try with the commandline tool xsltproc, if you
get the wrong result there as well, it's defintively not a php issue...)
----
[2006-10-30 02:23:46] pascal dot heus at gmail dot com
load('http://scs.gmu.edu/~rgomez/qc/xml/gmu.xml');
$xslDom = new DomDocument();
// Comment/uncomment lines below to select XSLT file
$xsl =
'http://scs.gmu.edu/~rgomez/qc/xml/gmu_program_schedule_bug_fails.xslt';
//$xsl =
'http://scs.gmu.edu/~rgomez/qc/xml/gmu_program_schedule_bug_works.xslt';
echo "Using $xsl";
$xslDom->load($xsl);
$proc = new XsltProcessor();
$xslDom = $proc->importStylesheet($xslDom);
$outputDom = $proc->transformToDoc($xmlDom);
echo $outputDom->saveHTML();
?>
[2006-10-29 17:18:46] [EMAIL PROTECTED]
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.
[2006-10-29 15:24:51] pascal dot heus at gmail dot com
Description:
The following xsl code works fine with the Sablotron engine under pHp4
or with XMLSpy:
When using libxslt under pHp 5, it fails to execute.
The problem comes form the $program-id variable used in the match=
attribute. If I replace it with a hard coded value, the XSLT works
fine:
This is under pHp 5.0.4 running on an institutional server, I don't
have the authority to upgrade that system for further testing.
Reproduce code:
---
You can retrieve the xslt and xml file at:
http://scs.gmu.edu/~rgomez/qc/xml/gmu_program_schedule_bug.xslt
http://scs.gmu.edu/~rgomez/qc/xml/gmu.xml
--
Edit this bug report at http://bugs.php.net/?id=39299&edit=1
[PHP-BUG] Req #63242 [NEW]: Default error page in PHP built-in web server uses outdated html/css
From: pascal dot chevrel at free dot fr Operating system: Linux PHP version: 5.4.7 Package: Built-in web server Bug Type: Feature/Change Request Bug description:Default error page in PHP built-in web server uses outdated html/css Description: The default error page in the built-in webserver is very ugly. Looking at the history of the file in the git repository, these styles and html were copied from the phpinfo styling created in 2002 with CSS selectors that had Netscape 4/IE4 compatibility in mind. Appearances matter :) It makes this new PHP feature look already outdated. I am going to attach a patch that: * will make it look a bit more modern and works in responsive mode too * will remove unused css rules from the code * will add an html5 doctype to the error page * will remove unnecesary html attributes in html5 (I noticed that there are 2 tests in the sapi/cli/tests folder that reproduce some of this html, I don't know how tests work for php but I can give a shot at updating the expected results of the tests in the patch if required) -- Edit bug report at https://bugs.php.net/bug.php?id=63242&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63242&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63242&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63242&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63242&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63242&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63242&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63242&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63242&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63242&r=support Expected behavior: https://bugs.php.net/fix.php?id=63242&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63242&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63242&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63242&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63242&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63242&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63242&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63242&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63242&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63242&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63242&r=mysqlcfg
Req #63242 [Com]: Default error page in PHP built-in web server uses outdated html/css
Edit report at https://bugs.php.net/bug.php?id=63242&edit=1 ID: 63242 Comment by: pascal dot chevrel at free dot fr Reported by:pascal dot chevrel at free dot fr Summary:Default error page in PHP built-in web server uses outdated html/css Status: Open Type: Feature/Change Request Package:Built-in web server Operating System: Linux PHP Version:5.4.7 Block user comment: N Private report: N New Comment: Here is a after/before screenshot: http://chevrel.org/images/phpbugs/bug63242.png Note that I chose yellow for the error header instead of blue because this is the color used in the terminal for such errors, blue is not usually an error associated to errors. Previous Comments: [2012-10-08 17:41:00] pascal dot chevrel at free dot fr Description: The default error page in the built-in webserver is very ugly. Looking at the history of the file in the git repository, these styles and html were copied from the phpinfo styling created in 2002 with CSS selectors that had Netscape 4/IE4 compatibility in mind. Appearances matter :) It makes this new PHP feature look already outdated. I am going to attach a patch that: * will make it look a bit more modern and works in responsive mode too * will remove unused css rules from the code * will add an html5 doctype to the error page * will remove unnecesary html attributes in html5 (I noticed that there are 2 tests in the sapi/cli/tests folder that reproduce some of this html, I don't know how tests work for php but I can give a shot at updating the expected results of the tests in the patch if required) -- Edit this bug report at https://bugs.php.net/bug.php?id=63242&edit=1
Req #63242 [Opn]: Default error page in PHP built-in web server uses outdated html/css
Edit report at https://bugs.php.net/bug.php?id=63242&edit=1 ID: 63242 User updated by:pascal dot chevrel at free dot fr Reported by:pascal dot chevrel at free dot fr Summary:Default error page in PHP built-in web server uses outdated html/css Status: Open Type: Feature/Change Request Package:Built-in web server Operating System: Linux PHP Version:5.4.7 Block user comment: N Private report: N New Comment: Reeze, not sure I understand what you mean. For sure, I am in no way saying that the integrated web server should be used in production. You seem to be of the opinion that since it is not targetting production, it is ok that it is using obsolete HTML/CSS and looks like a 404 page from the 90's, I disagree, there is no reason to use complex sub-quality HTML/CSS, especially since it gives poor visual result. My patch simplifies the code used (less lines of code) while making the error page a bit more decent in terms of layout. I am happy to make compromises on this patch and revert the color to use the same blue color as before if you wish, using correct typography/alignment and simpler html/css code in the source code would already be a win for both consumers (web developpers that see this page during their developement) and the code base I think. Previous Comments: [2012-10-09 05:12:41] re...@php.net It's nice to have modern, but the appearance should be consist on PHP itself(VI). PHP use the BLUE a lot, kind of the color of PHP. as the color yellow, It looks like an error page of django :) and the built-in server is just for testing purpose, If possible, I'd PHP redesign its Visual Identity System to be more modern. And, yes there is a PHP.net alpha there: http://www.php.net/my.php (enable it at the bottom). but seems didn't active for a long time. ---- [2012-10-08 17:53:00] pascal dot chevrel at free dot fr Here is a after/before screenshot: http://chevrel.org/images/phpbugs/bug63242.png Note that I chose yellow for the error header instead of blue because this is the color used in the terminal for such errors, blue is not usually an error associated to errors. ---- [2012-10-08 17:41:00] pascal dot chevrel at free dot fr Description: The default error page in the built-in webserver is very ugly. Looking at the history of the file in the git repository, these styles and html were copied from the phpinfo styling created in 2002 with CSS selectors that had Netscape 4/IE4 compatibility in mind. Appearances matter :) It makes this new PHP feature look already outdated. I am going to attach a patch that: * will make it look a bit more modern and works in responsive mode too * will remove unused css rules from the code * will add an html5 doctype to the error page * will remove unnecesary html attributes in html5 (I noticed that there are 2 tests in the sapi/cli/tests folder that reproduce some of this html, I don't know how tests work for php but I can give a shot at updating the expected results of the tests in the patch if required) -- Edit this bug report at https://bugs.php.net/bug.php?id=63242&edit=1
Req #63242 [Opn]: Default error page in PHP built-in web server uses outdated html/css
Edit report at https://bugs.php.net/bug.php?id=63242&edit=1 ID: 63242 User updated by:pascal dot chevrel at free dot fr Reported by:pascal dot chevrel at free dot fr Summary:Default error page in PHP built-in web server uses outdated html/css Status: Open Type: Feature/Change Request Package:Built-in web server Operating System: Linux PHP Version:5.4.7 Block user comment: N Private report: N New Comment: @laruence Thanks, I will do that this afternoon. Is that ok if I just add back the blue background color of do you want the page to remain strictly identical to what it is now? (currently the title and paragraph are not aligned, the title also has no padding and sticks to the blue border /ex). Previous Comments: [2012-10-09 09:34:33] larue...@php.net sorry, should be: it will be better if you can improve the skeleton, but keep the "looks" [2012-10-09 09:34:02] larue...@php.net @pascal, thanks it will be better if you can improve the skeleton keep the "looks" ---- [2012-10-09 08:37:57] pascal dot chevrel at free dot fr Reeze, not sure I understand what you mean. For sure, I am in no way saying that the integrated web server should be used in production. You seem to be of the opinion that since it is not targetting production, it is ok that it is using obsolete HTML/CSS and looks like a 404 page from the 90's, I disagree, there is no reason to use complex sub-quality HTML/CSS, especially since it gives poor visual result. My patch simplifies the code used (less lines of code) while making the error page a bit more decent in terms of layout. I am happy to make compromises on this patch and revert the color to use the same blue color as before if you wish, using correct typography/alignment and simpler html/css code in the source code would already be a win for both consumers (web developpers that see this page during their developement) and the code base I think. [2012-10-09 05:12:41] re...@php.net It's nice to have modern, but the appearance should be consist on PHP itself(VI). PHP use the BLUE a lot, kind of the color of PHP. as the color yellow, It looks like an error page of django :) and the built-in server is just for testing purpose, If possible, I'd PHP redesign its Visual Identity System to be more modern. And, yes there is a PHP.net alpha there: http://www.php.net/my.php (enable it at the bottom). but seems didn't active for a long time. -------- [2012-10-08 17:53:00] pascal dot chevrel at free dot fr Here is a after/before screenshot: http://chevrel.org/images/phpbugs/bug63242.png Note that I chose yellow for the error header instead of blue because this is the color used in the terminal for such errors, blue is not usually an error associated to errors. 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 https://bugs.php.net/bug.php?id=63242 -- Edit this bug report at https://bugs.php.net/bug.php?id=63242&edit=1
Req #63242 [Com]: Default error page in PHP built-in web server uses outdated html/css
Edit report at https://bugs.php.net/bug.php?id=63242&edit=1 ID: 63242 Comment by: pascal dot chevrel at free dot fr Reported by:pascal dot chevrel at free dot fr Summary:Default error page in PHP built-in web server uses outdated html/css Status: Open Type: Feature/Change Request Package:Built-in web server Operating System: Linux PHP Version:5.4.7 Block user comment: N Private report: N New Comment: I just attached an updated patch that restores the blue color. You can see the result here: http://chevrel.org/images/phpbugs/bug63242v2.png I also compiled php locally and ran the tests, there were 2 tests failing because of the new patch, I updated these two tests in my patch. Tell me if you need updates to this patch, thanks. Previous Comments: [2012-10-09 09:40:50] pascal dot chevrel at free dot fr @laruence Thanks, I will do that this afternoon. Is that ok if I just add back the blue background color of do you want the page to remain strictly identical to what it is now? (currently the title and paragraph are not aligned, the title also has no padding and sticks to the blue border /ex). [2012-10-09 09:34:33] larue...@php.net sorry, should be: it will be better if you can improve the skeleton, but keep the "looks" [2012-10-09 09:34:02] larue...@php.net @pascal, thanks it will be better if you can improve the skeleton keep the "looks" ---- [2012-10-09 08:37:57] pascal dot chevrel at free dot fr Reeze, not sure I understand what you mean. For sure, I am in no way saying that the integrated web server should be used in production. You seem to be of the opinion that since it is not targetting production, it is ok that it is using obsolete HTML/CSS and looks like a 404 page from the 90's, I disagree, there is no reason to use complex sub-quality HTML/CSS, especially since it gives poor visual result. My patch simplifies the code used (less lines of code) while making the error page a bit more decent in terms of layout. I am happy to make compromises on this patch and revert the color to use the same blue color as before if you wish, using correct typography/alignment and simpler html/css code in the source code would already be a win for both consumers (web developpers that see this page during their developement) and the code base I think. [2012-10-09 05:12:41] re...@php.net It's nice to have modern, but the appearance should be consist on PHP itself(VI). PHP use the BLUE a lot, kind of the color of PHP. as the color yellow, It looks like an error page of django :) and the built-in server is just for testing purpose, If possible, I'd PHP redesign its Visual Identity System to be more modern. And, yes there is a PHP.net alpha there: http://www.php.net/my.php (enable it at the bottom). but seems didn't active for a long time. 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 https://bugs.php.net/bug.php?id=63242 -- Edit this bug report at https://bugs.php.net/bug.php?id=63242&edit=1
[PHP-BUG] Bug #63249 [NEW]: built-in webserver does not work with Opera browser
From: pascal dot chevrel at free dot fr Operating system: Linux PHP version: 5.4.7 Package: Built-in web server Bug Type: Bug Bug description:built-in webserver does not work with Opera browser Description: If I launch the php built in web server on any port (php -S localhost:8002), it works in Firefox and Chrome but not in Opera (12.10) which doesn't find any server and displays its internal error page. If I launch a python server on the same port, it works in Opera. I am not seeing any request from Opera in the console while the server is running. I tried to debug the problem with an Opera employee and we couldn't find the problem on Opera side, it seems that the problem is on PHP side. (I will forward this bug number to him so as that he can get in touch with you in case you need to interact with Opera directly). Test script: --- php -S localhost:8002 Expected result: Server works in Opera browser Actual result: -- Server not working in Opera browser -- Edit bug report at https://bugs.php.net/bug.php?id=63249&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63249&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63249&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63249&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63249&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63249&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63249&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63249&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63249&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63249&r=support Expected behavior: https://bugs.php.net/fix.php?id=63249&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63249&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63249&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63249&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63249&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63249&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63249&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63249&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63249&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63249&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63249&r=mysqlcfg
Bug #63249 [Fbk->Opn]: built-in webserver does not work with Opera browser
Edit report at https://bugs.php.net/bug.php?id=63249&edit=1 ID: 63249 User updated by:pascal dot chevrel at free dot fr Reported by:pascal dot chevrel at free dot fr Summary:built-in webserver does not work with Opera browser -Status: Feedback +Status: Open Type: Bug Package:Built-in web server Operating System: Linux PHP Version:5.4.7 Block user comment: N Private report: N New Comment: good guess : http://[::1]:8002/ works my /etc/hosts lists localhost as 127.0.0.1 Previous Comments: [2012-10-09 16:38:23] johan...@php.net As a guess: Might this be an IPv6 issue? Can you try loading http://127.0.0.1:8002/ and http://[::1]:8002/ Please also checks whether your /etc/hosts lists "localhost" as ::1 or 127.0.0.1 [2012-10-09 15:25:25] larue...@php.net sounds very weird, maybe you can debug it with tcpdump, to check whether the request really arrived. [2012-10-09 15:10:31] pascal dot chevrel at free dot fr Description: If I launch the php built in web server on any port (php -S localhost:8002), it works in Firefox and Chrome but not in Opera (12.10) which doesn't find any server and displays its internal error page. If I launch a python server on the same port, it works in Opera. I am not seeing any request from Opera in the console while the server is running. I tried to debug the problem with an Opera employee and we couldn't find the problem on Opera side, it seems that the problem is on PHP side. (I will forward this bug number to him so as that he can get in touch with you in case you need to interact with Opera directly). Test script: --- php -S localhost:8002 Expected result: Server works in Opera browser Actual result: -- Server not working in Opera browser -- Edit this bug report at https://bugs.php.net/bug.php?id=63249&edit=1
Req #63242 [Opn]: Default error page in PHP built-in web server uses outdated html/css
Edit report at https://bugs.php.net/bug.php?id=63242&edit=1 ID: 63242 User updated by:pascal dot chevrel at free dot fr Reported by:pascal dot chevrel at free dot fr Summary:Default error page in PHP built-in web server uses outdated html/css Status: Open Type: Feature/Change Request Package:Built-in web server Operating System: Linux PHP Version:5.4.7 Block user comment: N Private report: N New Comment: btw, I attached a patch to the bug but in case you prefer a Pull Request on github, just tell me. I don't know what process is preferred today for PHP patches. Previous Comments: [2012-10-09 14:50:01] re...@php.net @Pascal, I like the idea to make it more modern, I just think the color you choose it not well consist with PHP's blue color and visual identity. [2012-10-09 12:02:24] pascal dot chevrel at free dot fr I just attached an updated patch that restores the blue color. You can see the result here: http://chevrel.org/images/phpbugs/bug63242v2.png I also compiled php locally and ran the tests, there were 2 tests failing because of the new patch, I updated these two tests in my patch. Tell me if you need updates to this patch, thanks. [2012-10-09 09:40:50] pascal dot chevrel at free dot fr @laruence Thanks, I will do that this afternoon. Is that ok if I just add back the blue background color of do you want the page to remain strictly identical to what it is now? (currently the title and paragraph are not aligned, the title also has no padding and sticks to the blue border /ex). [2012-10-09 09:34:33] larue...@php.net sorry, should be: it will be better if you can improve the skeleton, but keep the "looks" [2012-10-09 09:34:02] larue...@php.net @pascal, thanks it will be better if you can improve the skeleton keep the "looks" 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 https://bugs.php.net/bug.php?id=63242 -- Edit this bug report at https://bugs.php.net/bug.php?id=63242&edit=1
Req #63242 [Com]: Default error page in PHP built-in web server uses outdated html/css
Edit report at https://bugs.php.net/bug.php?id=63242&edit=1 ID: 63242 Comment by: pascal dot chevrel at free dot fr Reported by:pascal dot chevrel at free dot fr Summary:Default error page in PHP built-in web server uses outdated html/css Status: Open Type: Feature/Change Request Package:Built-in web server Operating System: Linux PHP Version:5.4.7 Block user comment: N Private report: N New Comment: Ok, here is an updated patch, it only updates the structure and tests and it reproduces the styles copied from the 2002 file. To make it absolutely identical, I had to add a margin-top:0 rule to h1 so as to emulate quirks mode in browsers for html3 documents. Previous Comments: [2012-10-10 03:46:16] larue...@php.net I think we can split this into two patch: 1. keep the looks unchanged, and improve the skeleton 2. improve the looks the first one could easy to be accepted. [2012-10-09 20:28:56] pascal dot chevrel at free dot fr btw, I attached a patch to the bug but in case you prefer a Pull Request on github, just tell me. I don't know what process is preferred today for PHP patches. [2012-10-09 14:50:01] re...@php.net @Pascal, I like the idea to make it more modern, I just think the color you choose it not well consist with PHP's blue color and visual identity. [2012-10-09 12:02:24] pascal dot chevrel at free dot fr I just attached an updated patch that restores the blue color. You can see the result here: http://chevrel.org/images/phpbugs/bug63242v2.png I also compiled php locally and ran the tests, there were 2 tests failing because of the new patch, I updated these two tests in my patch. Tell me if you need updates to this patch, thanks. [2012-10-09 09:40:50] pascal dot chevrel at free dot fr @laruence Thanks, I will do that this afternoon. Is that ok if I just add back the blue background color of do you want the page to remain strictly identical to what it is now? (currently the title and paragraph are not aligned, the title also has no padding and sticks to the blue border /ex). 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 https://bugs.php.net/bug.php?id=63242 -- Edit this bug report at https://bugs.php.net/bug.php?id=63242&edit=1
Req #63242 [Csd]: Default error page in PHP built-in web server uses outdated html/css
Edit report at https://bugs.php.net/bug.php?id=63242&edit=1 ID: 63242 User updated by:pascal dot chevrel at free dot fr Reported by:pascal dot chevrel at free dot fr Summary:Default error page in PHP built-in web server uses outdated html/css Status: Closed Type: Feature/Change Request Package:Built-in web server Operating System: Linux PHP Version:5.4.7 Assigned To:laruence Block user comment: N Private report: N New Comment: Should I open a separate bug for a visual redesign of the 404 page now that this bug is closed? Or is there a discussion mailing list for such issues that I should propose the change? Previous Comments: [2012-10-10 09:27:58] larue...@php.net weird, no auto-commit log comments... the commit log is here: https://github.com/php/php-src/commit/ea441bd08dc1d9f5bd167f3f495321c5225909b6 [2012-10-10 09:25:43] larue...@php.net The fix for this bug has been committed. 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/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. thanks for your help. and you can open a new entry about improve the looks, :) thanks [2012-10-10 07:15:00] pascal dot chevrel at free dot fr Ok, here is an updated patch, it only updates the structure and tests and it reproduces the styles copied from the 2002 file. To make it absolutely identical, I had to add a margin-top:0 rule to h1 so as to emulate quirks mode in browsers for html3 documents. [2012-10-10 03:46:16] larue...@php.net I think we can split this into two patch: 1. keep the looks unchanged, and improve the skeleton 2. improve the looks the first one could easy to be accepted. [2012-10-09 20:28:56] pascal dot chevrel at free dot fr btw, I attached a patch to the bug but in case you prefer a Pull Request on github, just tell me. I don't know what process is preferred today for PHP patches. 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 https://bugs.php.net/bug.php?id=63242 -- Edit this bug report at https://bugs.php.net/bug.php?id=63242&edit=1
[PHP-BUG] Req #63255 [NEW]: 404 page looks amateur
From: pascal dot chevrel at free dot fr Operating system: all PHP version: master-Git-2012-10-10 (Git) Package: Built-in web server Bug Type: Feature/Change Request Bug description:404 page looks amateur Description: This is a followup to https://bugs.php.net/bug.php?id=63242 where I provided a patch to have html5 syntax and simpler html/css to the 404 page The 404 page uses styles that were copy/pasted from a 2002 commit for phpinfo styling. It looks amateurish, title and text are not aligned, the blue background sticks to the title text and it depends partly on the browser default html rules, which means that there are differences in display across browsers for that page. I propose a slight change of the css used that will result in something a bit leaner while keeping the same blue colour that represents PHP, here is a before/after screenshot: http://chevrel.org/images/phpbugs/bug63242v2_compare.png This is a simple patch that passes all tests, I will attach it here later today. -- Edit bug report at https://bugs.php.net/bug.php?id=63255&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63255&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63255&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63255&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63255&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63255&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63255&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63255&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63255&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63255&r=support Expected behavior: https://bugs.php.net/fix.php?id=63255&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63255&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63255&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63255&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63255&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63255&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63255&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63255&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63255&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63255&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63255&r=mysqlcfg
[PHP-BUG] Req #63263 [NEW]: phpinfo() function generates old html/css
From: pascal dot chevrel at free dot fr Operating system: all PHP version: 5.3Git-2012-10-11 (Git) Package: PHP options/info functions Bug Type: Feature/Change Request Bug description:phpinfo() function generates old html/css Description: The phpinfo() function does not use recent html and abuses classes attributes and css for semantics (like using for a cell header instead of I am attaching a patch that simplifies the html generated, makes it an html5 compliant (and hence simplifies the code used to generate this html) while keeping the same layout and visual appearance. The html goes from 64KB to 40KB just by removing redundant html. There is one change to php_info_print_table_row_internal() to remove a variable, that function is not used anywhere else in the code base. I didn't get any test failure with this patch. Thanks -- Edit bug report at https://bugs.php.net/bug.php?id=63263&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63263&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63263&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63263&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63263&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63263&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63263&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63263&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63263&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63263&r=support Expected behavior: https://bugs.php.net/fix.php?id=63263&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63263&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63263&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63263&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63263&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63263&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63263&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63263&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63263&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63263&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63263&r=mysqlcfg
Req #63242 [Csd]: Default error page in PHP built-in web server uses outdated html/css
Edit report at https://bugs.php.net/bug.php?id=63242&edit=1 ID: 63242 User updated by:pascal dot chevrel at free dot fr Reported by:pascal dot chevrel at free dot fr Summary:Default error page in PHP built-in web server uses outdated html/css Status: Closed Type: Feature/Change Request Package:Built-in web server Operating System: Linux PHP Version:5.4.7 Assigned To:laruence Block user comment: N Private report: N New Comment: Looking at Github branches and 5.4.8 release notes, I am not seeing the git commit on master for this bug included into the 5.4.8 release, any reason for that? Previous Comments: [2012-10-10 10:01:38] larue...@php.net yeah, if you wish, you can open a new entry about that. [2012-10-10 09:43:23] pascal dot chevrel at free dot fr Should I open a separate bug for a visual redesign of the 404 page now that this bug is closed? Or is there a discussion mailing list for such issues that I should propose the change? [2012-10-10 09:27:58] larue...@php.net weird, no auto-commit log comments... the commit log is here: https://github.com/php/php-src/commit/ea441bd08dc1d9f5bd167f3f495321c5225909b6 [2012-10-10 09:25:43] larue...@php.net The fix for this bug has been committed. 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/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. thanks for your help. and you can open a new entry about improve the looks, :) thanks [2012-10-10 07:15:00] pascal dot chevrel at free dot fr Ok, here is an updated patch, it only updates the structure and tests and it reproduces the styles copied from the 2002 file. To make it absolutely identical, I had to add a margin-top:0 rule to h1 so as to emulate quirks mode in browsers for html3 documents. 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 https://bugs.php.net/bug.php?id=63242 -- Edit this bug report at https://bugs.php.net/bug.php?id=63242&edit=1
Req #63242 [Csd]: Default error page in PHP built-in web server uses outdated html/css
Edit report at https://bugs.php.net/bug.php?id=63242&edit=1 ID: 63242 User updated by:pascal dot chevrel at free dot fr Reported by:pascal dot chevrel at free dot fr Summary:Default error page in PHP built-in web server uses outdated html/css Status: Closed Type: Feature/Change Request Package:Built-in web server Operating System: Linux PHP Version:5.4.7 Assigned To:laruence Block user comment: N Private report: N New Comment: Awesome, thanks :) Previous Comments: [2012-10-19 07:47:56] ahar...@php.net The fix was committed after 5.4.8 had been branched from the main 5.4 branch. (In general, fixes are only committed to release branches after RC1 for security issues or major bugs.) It will be in 5.4.9. [2012-10-19 07:41:54] pascal dot chevrel at free dot fr Looking at Github branches and 5.4.8 release notes, I am not seeing the git commit on master for this bug included into the 5.4.8 release, any reason for that? [2012-10-10 10:01:38] larue...@php.net yeah, if you wish, you can open a new entry about that. [2012-10-10 09:43:23] pascal dot chevrel at free dot fr Should I open a separate bug for a visual redesign of the 404 page now that this bug is closed? Or is there a discussion mailing list for such issues that I should propose the change? [2012-10-10 09:27:58] larue...@php.net weird, no auto-commit log comments... the commit log is here: https://github.com/php/php-src/commit/ea441bd08dc1d9f5bd167f3f495321c5225909b6 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 https://bugs.php.net/bug.php?id=63242 -- Edit this bug report at https://bugs.php.net/bug.php?id=63242&edit=1
Bug #60471 [Com]: Random "Invalid request (unexpected EOF)" using a router script
Edit report at https://bugs.php.net/bug.php?id=60471&edit=1 ID: 60471 Comment by: pascal dot chevrel at free dot fr Reported by:lolautruche at gmail dot com Summary:Random "Invalid request (unexpected EOF)" using a router script Status: Assigned Type: Bug Package:Built-in web server Operating System: Mac OS X 10.7.2 (Lion) PHP Version:5.4.0RC2 Assigned To:laruence Block user comment: N Private report: N New Comment: Just in case it matters, I am seeing the same bug on Linux with Firefox (both Firefox releases and Nightly builds) Previous Comments: [2012-02-25 15:15:24] michal dot pipa dot xsolve at gmail dot com I've attached a patch that disables "Unexpected EOF" error message from built-in server. [2012-02-23 18:45:53] michal dot pipa dot xsolve at gmail dot com I've noticed these messages and did some network traffic analysis. I've tested this on Ubuntu and Chromium. What I've found is that Chromium has feature called "Predict network actions to improve page load performance" and it's enabled by default. It works this way, that if HTML page has links to some resources, than Chromium opens about 10 TCP connections in advance. And then if browser has less than 10 resources to fetch, unused connections times out after 10 seconds. And this (empty payload) causes PHP server to display "Invalid request (unexpected EOF)" message. See: http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/sapi/cli/php_cli_server.c?revision=322966&view=markup#l1591 When you disable this Chromium's feature it doesn't open TCP connections in advance and this error message disappears. I'm wondering if we really need this error message (maybe it was used for some debugging purposes). [2012-02-16 18:29:02] ras...@php.net The patch is here: http://svn.php.net/viewvc/php/php-src/trunk/sapi/cli/php_cli_server.c? r1=323078&r2=323077&pathrev=323078&view=patch if someone could test it, please. [2012-02-16 18:24:54] ras...@php.net Could this simply be caused by the "Connection: closed" message instead of the correct "Connection: close" message the built-in server spits out? This is fixed in trunk but hasn't been merged to 5.4 yet. [2012-02-12 17:06:17] rbrunius at gmail dot com I'm am having the same thing happen and I Googled error code it and found this thread. I tried various ways to terminate the file but none solved it. php 5.4 RC7 development server on Windows 7 Chrome browser has brings the issue but Firefox does not. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=60471 -- Edit this bug report at https://bugs.php.net/bug.php?id=60471&edit=1
Req #63255 [Com]: 404 page looks amateur
Edit report at https://bugs.php.net/bug.php?id=63255&edit=1 ID: 63255 Comment by: pascal dot chevrel at free dot fr Reported by:pascal dot chevrel at free dot fr Summary:404 page looks amateur Status: Open Type: Feature/Change Request Package:Built-in web server Operating System: all PHP Version:master-Git-2012-10-10 (Git) Block user comment: N Private report: N New Comment: Can somebody have a look at this simple patch? I saw that 5.4.9RC1 is released and I believe it contains my html fix for the 404 page (https://bugs.php.net/bug.php?id=63242), it would have been nice to have the css part included as well. Previous Comments: [2012-10-10 15:00:15] pascal dot chevrel at free dot fr Description: This is a followup to https://bugs.php.net/bug.php?id=63242 where I provided a patch to have html5 syntax and simpler html/css to the 404 page The 404 page uses styles that were copy/pasted from a 2002 commit for phpinfo styling. It looks amateurish, title and text are not aligned, the blue background sticks to the title text and it depends partly on the browser default html rules, which means that there are differences in display across browsers for that page. I propose a slight change of the css used that will result in something a bit leaner while keeping the same blue colour that represents PHP, here is a before/after screenshot: http://chevrel.org/images/phpbugs/bug63242v2_compare.png This is a simple patch that passes all tests, I will attach it here later today. -- Edit this bug report at https://bugs.php.net/bug.php?id=63255&edit=1
#47491 [NEW]: Crash when executing a PDO/MYSQL query
From: pascal dot fellerich at ses-engineering dot com
Operating system: Win XP Pro SP3
PHP version: 5.2.8
PHP Bug Type: Reproducible crash
Bug description: Crash when executing a PDO/MYSQL query
Description:
PHP crashes when executing a query using PDO/Mysql.
PHP is running as an Apache 2.0 handler.
In the Apache error log, this line appears:
[notice] Parent: child process exited with status 3221225477 --
Restarting.
Sometimes, even the new PDO() call crashes already, but to reproduce the
bug easily, just do a SELECT * FROM mysql.user - voila.
Set up: XAMPP 1.7.0 with Apache 2.2.11, PHP 5.2.8, MySQL 5.1.30.
The same crash could be reproduced in a 'bastardized' XAMPP setup with
MySQL 5.0.67.
Conversely, the setup Apache 2.2.11, PHP 5.2.6, MySQL 5.1.30 was OK. No
crashes here.
Reproduce code:
---
$pdo = new PDO("mysql:host=localhost; dbname=mysql", 'root',
$mypassword);
$pdo->exec("SET NAMES 'utf8'");
$result = $pdo->query($sql, PDO::FETCH_NUM);
//...bye bye!
Expected result:
Obvious.
Actual result:
--
Apache Error Log:
[notice] Parent: child process exited with status 3221225477 --
Restarting.
Nothing more available.
--
Edit bug report at http://bugs.php.net/?id=47491&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47491&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47491&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47491&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47491&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47491&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47491&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47491&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47491&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47491&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47491&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47491&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47491&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47491&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47491&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47491&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47491&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47491&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47491&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47491&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47491&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47491&r=mysqlcfg
#47491 [Fbk->Opn]: Crash when executing a PDO/MYSQL query
ID: 47491
User updated by: pascal dot fellerich at ses-engineering dot com
Reported By: pascal dot fellerich at ses-engineering dot com
-Status: Feedback
+Status: Open
Bug Type: Reproducible crash
Operating System: Win XP Pro SP3
PHP Version: 5.2.8
New Comment:
One line of code was missing
$sql = "SELECT * FROM users";
--- yes, with MySQL 5.1. But the crash also happens when I revert to
MySQL 5.0.67
Previous Comments:
[2009-02-24 13:32:50] paj...@php.net
And you use mysql 5.1 right?
[2009-02-24 13:30:03] pascal dot fellerich at ses-engineering dot com
Description:
PHP crashes when executing a query using PDO/Mysql.
PHP is running as an Apache 2.0 handler.
In the Apache error log, this line appears:
[notice] Parent: child process exited with status 3221225477 --
Restarting.
Sometimes, even the new PDO() call crashes already, but to reproduce
the bug easily, just do a SELECT * FROM mysql.user - voila.
Set up: XAMPP 1.7.0 with Apache 2.2.11, PHP 5.2.8, MySQL 5.1.30.
The same crash could be reproduced in a 'bastardized' XAMPP setup with
MySQL 5.0.67.
Conversely, the setup Apache 2.2.11, PHP 5.2.6, MySQL 5.1.30 was OK. No
crashes here.
Reproduce code:
---
$pdo = new PDO("mysql:host=localhost; dbname=mysql", 'root',
$mypassword);
$pdo->exec("SET NAMES 'utf8'");
$result = $pdo->query($sql, PDO::FETCH_NUM);
//...bye bye!
Expected result:
Obvious.
Actual result:
--
Apache Error Log:
[notice] Parent: child process exited with status 3221225477 --
Restarting.
Nothing more available.
--
Edit this bug report at http://bugs.php.net/?id=47491&edit=1
#33806 [NEW]: Access to protected functions from static function in base class
From: pascal dot parietti at fh-aargau dot ch
Operating system: Linux, 2.6.11
PHP version: 5.0.4
PHP Bug Type: Class/Object related
Bug description: Access to protected functions from static function in base
class
Description:
A static function in the base class (A) can execute a protected function
in a derived class (B).
If the same function is called from outside of class A the PHP Fatal error
occurs as excepted.
The error also occurs with the CVS Snapshot php5-STABLE-200507211237
compiled with ./configure && make
Reproduce code:
---
test2(); # why does this work?
}
}
class B extends A {
protected function test2() {
echo "B: test2 \n";
}
}
A::test();
$b = new B();
# call a protected function -> PHP Fatal error as excepted:
$b->test2();
?>
Expected result:
PHP Fatal error: Call to protected method B::test2() on line 5
--
Edit bug report at http://bugs.php.net/?id=33806&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33806&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33806&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33806&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33806&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33806&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33806&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33806&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33806&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33806&r=support
Expected behavior: http://bugs.php.net/fix.php?id=33806&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33806&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33806&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33806&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33806&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33806&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33806&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33806&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33806&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33806&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33806&r=mysqlcfg
#33806 [Bgs]: Access to protected functions from static function in base class
ID: 33806
User updated by: pascal dot parietti at fh-aargau dot ch
Reported By: pascal dot parietti at fh-aargau dot ch
Status: Bogus
Bug Type: Class/Object related
Operating System: Linux, 2.6.11
PHP Version: 5.0.4
New Comment:
As in the manual is written:
'...Protected limits access to inherited classes (and to the class that
defines the item)...'
I assume that it is not possible to access this protected function from
outside the class or inherited classes?
Previous Comments:
[2005-07-21 15:32:58] [EMAIL PROTECTED]
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
[2005-07-21 15:25:31] pascal dot parietti at fh-aargau dot ch
Description:
A static function in the base class (A) can execute a protected
function in a derived class (B).
If the same function is called from outside of class A the PHP Fatal
error occurs as excepted.
The error also occurs with the CVS Snapshot php5-STABLE-200507211237
compiled with ./configure && make
Reproduce code:
---
test2(); # why does this work?
}
}
class B extends A {
protected function test2() {
echo "B: test2 \n";
}
}
A::test();
$b = new B();
# call a protected function -> PHP Fatal error as excepted:
$b->test2();
?>
Expected result:
PHP Fatal error: Call to protected method B::test2() on line 5
--
Edit this bug report at http://bugs.php.net/?id=33806&edit=1
