[PHP-BUG] Req #53351 [NEW]: Autoload should not cancel if called for same class twice
From:
Operating system: Ubuntu 10.04
PHP version: 5.3.3
Package: SPL related
Bug Type: Feature/Change Request
Bug description:Autoload should not cancel if called for same class twice
Description:
hi,
currently i am using a require-all-script in my system that just plain
require-once's all files with correct ending (".class.php";".mdl.php";...)
it can find.
This happens inside of an autoload-method,
calling itself again when a depency (e.g. inheritance) occours.
when called again, it will skip all already called includes, since they are
require-_once_. Whith this loader i can just add a class file and it will
be loaded automaticly without needing me to register it somewhere
manually.
But it seems i have misunderstood the documentation,
because i now have noticed that when two classes extends the same class,
it will fail at the second child-class complaining that the parent-class is
missing instead of just calling autoload again for the same class,
which i thought will happen.
now i have to build the initial-loader much more complex, holding a cached
depency-list of classes or looking into the source-code when called.
Test script:
---
Expected result:
Actual result:
--
--
Edit bug report at http://bugs.php.net/bug.php?id=53351&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53351&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53351&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53351&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53351&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53351&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53351&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53351&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53351&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53351&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53351&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53351&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53351&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53351&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53351&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53351&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53351&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53351&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53351&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53351&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53351&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53351&r=mysqlcfg
[PHP-BUG] Bug #53352 [NEW]: open_basedir does not pass through files with matching path
From: Operating system: Windows 7 PHP version: 5.3SVN-2010-11-19 (SVN) Package: Safe Mode/open_basedir Bug Type: Bug Bug description:open_basedir does not pass through files with matching path Description: Right after installing PHP 5.3.4RC1 i get the following error: [19-Nov-2010 08:47:47] PHP Warning: Unknown: open_basedir restriction in effect. File(C:\Users\Dmitry\Repo\InnoForce\AMD\trunc\01_Code\public_html\index.php) is not within the allowed path(s): (C:/Users/Dmitry/Repo/InnoForce/AMD/trunc/01_Code/;C:/Windows/Temp) in Unknown on line 0 [19-Nov-2010 08:47:47] PHP Warning: Unknown: failed to open stream: Operation not permitted in Unknown on line 0 [19-Nov-2010 08:47:47] PHP Fatal error: Unknown: Failed opening required 'C:/Users/Dmitry/Repo/InnoForce/AMD/trunc/01_Code/public_html/index.php' (include_path='.;C:\php5\pear') in Unknown on line 0 It was working with PHP 5.3.3. Test script: --- # open_basedir in apache config php_admin_value open_basedir "C:/Users/Dmitry/Repo/InnoForce/AMD/trunc/01_Code/;C:/Windows/Temp" Expected result: No errors Actual result: -- [19-Nov-2010 08:47:47] PHP Warning: Unknown: open_basedir restriction in effect. File(C:\Users\Dmitry\Repo\InnoForce\AMD\trunc\01_Code\public_html\index.php) is not within the allowed path(s): (C:/Users/Dmitry/Repo/InnoForce/AMD/trunc/01_Code/;C:/Windows/Temp) in Unknown on line 0 [19-Nov-2010 08:47:47] PHP Warning: Unknown: failed to open stream: Operation not permitted in Unknown on line 0 [19-Nov-2010 08:47:47] PHP Fatal error: Unknown: Failed opening required 'C:/Users/Dmitry/Repo/InnoForce/AMD/trunc/01_Code/public_html/index.php' (include_path='.;C:\php5\pear') in Unknown on line 0 -- Edit bug report at http://bugs.php.net/bug.php?id=53352&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53352&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53352&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53352&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53352&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53352&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53352&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53352&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53352&r=needscript Try newer version: http://bugs.php.net/fix.php?id=53352&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53352&r=support Expected behavior: http://bugs.php.net/fix.php?id=53352&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53352&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53352&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53352&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53352&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53352&r=dst IIS Stability: http://bugs.php.net/fix.php?id=53352&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53352&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53352&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53352&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53352&r=mysqlcfg
[PHP-BUG] Bug #53353 [NEW]: Error retrieving data from MDB database: column is DOUBLE
From:
Operating system: Windows 7
PHP version: Irrelevant
Package: ODBC related
Bug Type: Bug
Bug description:Error retrieving data from MDB database: column is DOUBLE
Description:
Test environment:
- Windows 7 32bit, PHP 5.2.9 and PHP 5.3.1., MS Access 2002 SP3
- ODBC 'DSN1': Microsoft Access Driver (*.mdb) 6.01.7600.16385
- ODBC 'DSN2': Microsoft Access Driver (*.mdb,*.adccdb) 14.00.4760.1000
- Test to access the database also performed with IDL (www.ittvis.com)
In the access database I have a value -0.0864691123456789 (this is 19
characters long which is important) in a column defined as DOUBLE.
When I connect to the database with 'DSN1' then I get an ASCII 0 back with
PHP 5.2.9 and 5.3.1.
When I connect to the database with 'DSN2' then I get an 'E-2' (the
exponent of the floating point number) back with PHP 5.2.9 and 5.3.1.
When I retrieve the data with IDL from 'DSN1' and 'DSN2' I get the correct
numbers.
When I cut the last character in the access database -0.086469112345678 so
that the cell contains only 18 characters, the correct numbers are
retrieved with PHP.
Row from Access DB
163 12 1 1 x 132.449361609318 14.714402153458 75 3.08241316815042
-4.2982786671882 -8.64691123456789E-02 0
Test script:
---
$conn = odbc_connect("'DSN1' or 'DSN2', '', '')
or die ("Could not connect to database.");
$sql = "SELECT * FROM table;";
$res = odbc_exec($conn, $sql);
while ($x = odbc_fetch_array($res)){
var_dump($x);
if(!is_numeric($x['column'])) {
var_dump(ord($x['column']));
}
}
odbc_free_result($res);
odbc_close($conn);
Expected result:
array
'ID' => string '163' (length=3)
'CC' => string '12' (length=2)
'Z3' => string '1' (length=1)
'LFIREG' => string '1' (length=1)
'orgBoden' => string 'x' (length=1)
'cl' => string '132.449361609318' (length=16)
'cd' => string '14.714402153458' (length=15)
'cs' => string '75.0' (length=4)
'incr_cl' => string '3.08241316815042' (length=16)
'decr_cl' => string '-4.2982786671882' (length=16)
'd_cd' => string '-0.0864691123456789' (length=19)
'd_cs' => string '0.0' (length=3)
Actual result:
--
array
'ID' => string '163' (length=3)
'CC' => string '12' (length=2)
'Z3' => string '1' (length=1)
'LFIREG' => string '1' (length=1)
'orgBoden' => string 'x' (length=1)
'cl' => string '132.449361609318' (length=16)
'cd' => string '14.714402153458' (length=15)
'cs' => string '75.0' (length=4)
'incr_cl' => string '3.08241316815042' (length=16)
'decr_cl' => string '-4.2982786671882' (length=16)
'd_cd' => string '�' (length=1)
'd_cs' => string '0.0' (length=3)
int 0
--
Edit bug report at http://bugs.php.net/bug.php?id=53353&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53353&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53353&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53353&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53353&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53353&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53353&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53353&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53353&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53353&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53353&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53353&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53353&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53353&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53353&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53353&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53353&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53353&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53353&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53353&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53353&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53353&r=mysqlcfg
Bug #53353 [Opn]: Error retrieving data from MDB database: column is DOUBLE
Edit report at http://bugs.php.net/bug.php?id=53353&edit=1
ID: 53353
User updated by:stefan dot mueller at meteotest dot ch
Reported by:stefan dot mueller at meteotest dot ch
Summary:Error retrieving data from MDB database: column is
DOUBLE
Status: Open
Type: Bug
Package:ODBC related
Operating System: Windows 7
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
Changing the Testenvironment to:
Windows XP with Microsoft Access Driver (*.mdb) 4.x
It works as expected with PHP 5.2.9 and 5.3.1.
Previous Comments:
[2010-11-19 10:10:42] stefan dot mueller at meteotest dot ch
Description:
Test environment:
- Windows 7 32bit, PHP 5.2.9 and PHP 5.3.1., MS Access 2002 SP3
- ODBC 'DSN1': Microsoft Access Driver (*.mdb) 6.01.7600.16385
- ODBC 'DSN2': Microsoft Access Driver (*.mdb,*.adccdb) 14.00.4760.1000
- Test to access the database also performed with IDL (www.ittvis.com)
In the access database I have a value -0.0864691123456789 (this is 19
characters long which is important) in a column defined as DOUBLE.
When I connect to the database with 'DSN1' then I get an ASCII 0 back
with PHP 5.2.9 and 5.3.1.
When I connect to the database with 'DSN2' then I get an 'E-2' (the
exponent of the floating point number) back with PHP 5.2.9 and 5.3.1.
When I retrieve the data with IDL from 'DSN1' and 'DSN2' I get the
correct numbers.
When I cut the last character in the access database -0.086469112345678
so that the cell contains only 18 characters, the correct numbers are
retrieved with PHP.
Row from Access DB
163 12 1 1 x 132.449361609318 14.714402153458 75 3.08241316815042
-4.2982786671882 -8.64691123456789E-02 0
Test script:
---
$conn = odbc_connect("'DSN1' or 'DSN2', '', '')
or die ("Could not connect to database.");
$sql = "SELECT * FROM table;";
$res = odbc_exec($conn, $sql);
while ($x = odbc_fetch_array($res)){
var_dump($x);
if(!is_numeric($x['column'])) {
var_dump(ord($x['column']));
}
}
odbc_free_result($res);
odbc_close($conn);
Expected result:
array
'ID' => string '163' (length=3)
'CC' => string '12' (length=2)
'Z3' => string '1' (length=1)
'LFIREG' => string '1' (length=1)
'orgBoden' => string 'x' (length=1)
'cl' => string '132.449361609318' (length=16)
'cd' => string '14.714402153458' (length=15)
'cs' => string '75.0' (length=4)
'incr_cl' => string '3.08241316815042' (length=16)
'decr_cl' => string '-4.2982786671882' (length=16)
'd_cd' => string '-0.0864691123456789' (length=19)
'd_cs' => string '0.0' (length=3)
Actual result:
--
array
'ID' => string '163' (length=3)
'CC' => string '12' (length=2)
'Z3' => string '1' (length=1)
'LFIREG' => string '1' (length=1)
'orgBoden' => string 'x' (length=1)
'cl' => string '132.449361609318' (length=16)
'cd' => string '14.714402153458' (length=15)
'cs' => string '75.0' (length=4)
'incr_cl' => string '3.08241316815042' (length=16)
'decr_cl' => string '-4.2982786671882' (length=16)
'd_cd' => string '�' (length=1)
'd_cs' => string '0.0' (length=3)
int 0
--
Edit this bug report at http://bugs.php.net/bug.php?id=53353&edit=1
Bug #44626 [Com]: call_user_func_array pass arguments by reference
Edit report at http://bugs.php.net/bug.php?id=44626&edit=1
ID: 44626
Comment by: chat dot noir at arcor dot de
Reported by:HACGIS at gmail dot com
Summary:call_user_func_array pass arguments by reference
Status: Bogus
Type: Bug
Package:Variables related
Operating System: Windows XP SP2
PHP Version:5.3CVS-2008-04-03 (snap)
Block user comment: N
Private report: N
New Comment:
Why is this a warning?
CONTINUING EXECUTION AFTER IGNORED CALLS IS EVIL
Sorry for the caps, but I really mean it. Please make this at least an
exception or fatal error until it is finally fixed.
Previous Comments:
[2008-04-03 11:08:25] j...@php.net
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
[2008-04-03 09:47:59] HACGIS at gmail dot com
Description:
When a user function has some arguments which pass by reference, and use
call_user_func_array to call the function, I find a bug.
In PHP 5.2 the code doesn't have any warning, But in PHP 5.3 snap I get
a warning.
Reproduce code:
---
function test(&$arg){
echo $arg;
}
$arg = 'OK';
$arg_array1 = array(&$arg);
$arg_array2 = array($arg);
call_user_func_array('test', $arg_array1); // OK
call_user_func_array('test', $arg_array2); // get Warning
Expected result:
OK
OK
Actual result:
--
OK
Warning: Parameter 1 to test() expected to be a reference, value given
in D:\DevWeb.bak\UserDir\test\index.php on line 9
--
Edit this bug report at http://bugs.php.net/bug.php?id=44626&edit=1
Bug #53347 [Fbk->Opn]: Segfault in zend_is_inconsistent()
Edit report at http://bugs.php.net/bug.php?id=53347&edit=1
ID: 53347
Updated by: sebast...@php.net
Reported by:sebast...@php.net
Summary:Segfault in zend_is_inconsistent()
-Status: Feedback
+Status: Open
Type: Bug
Package:Reproducible crash
Operating System: Linux
PHP Version:trunk-SVN-2010-11-18 (SVN)
Block user comment: N
Private report: N
New Comment:
The following script reproduces the issue:
30 );
public static function isValidFormatCode( $type, $key )
{
return isset( self::${$type}[$key] );
}
}
var_dump( ezcConsoleOutput::isValidFormatCode( 'color', 'gray' ) );
?>
This does not print bool(true) but instead segfaults. Works fine with
PHP_5_3, btw.
s...@thinkpad ~ % USE_ZEND_ALLOC=0 valgrind --leak-check=full php
53347.php
==22840== Memcheck, a memory error detector
==22840== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et
al.
==22840== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for
copyright info
==22840== Command: php 53347.php
==22840==
==22840== Invalid read of size 4
==22840==at 0x92C021: _zend_is_inconsistent (zend_hash.c:54)
==22840==by 0x92EDAE: zend_hash_quick_find (zend_hash.c:929)
==22840==by 0xA49488: zend_fetch_var_address_helper_SPEC_CV_UNUSED
(zend_vm_execute.h:33194)
==22840==by 0xA49DEF: ZEND_FETCH_IS_SPEC_CV_UNUSED_HANDLER
(zend_vm_execute.h:33294)
==22840==by 0x957F02: execute (zend_vm_execute.h:410)
==22840==by 0x91CD93: zend_execute_scripts (zend.c:1195)
==22840==by 0x89661E: php_execute_script (main.c:2341)
==22840==by 0xA57D89: main (php_cli.c:1254)
==22840== Address 0x44 is not stack'd, malloc'd or (recently) free'd
==22840==
==22840==
==22840== Process terminating with default action of signal 11
(SIGSEGV)
==22840== Access not within mapped region at address 0x44
==22840==at 0x92C021: _zend_is_inconsistent (zend_hash.c:54)
==22840==by 0x92EDAE: zend_hash_quick_find (zend_hash.c:929)
==22840==by 0xA49488: zend_fetch_var_address_helper_SPEC_CV_UNUSED
(zend_vm_execute.h:33194)
==22840==by 0xA49DEF: ZEND_FETCH_IS_SPEC_CV_UNUSED_HANDLER
(zend_vm_execute.h:33294)
==22840==by 0x957F02: execute (zend_vm_execute.h:410)
==22840==by 0x91CD93: zend_execute_scripts (zend.c:1195)
==22840==by 0x89661E: php_execute_script (main.c:2341)
==22840==by 0xA57D89: main (php_cli.c:1254)
==22840== If you believe this happened as a result of a stack
==22840== overflow in your program's main thread (unlikely but
==22840== possible), you can try to increase the size of the
==22840== main thread stack using the --main-stacksize= flag.
==22840== The main thread stack size used in this run was 8388608.
==22840==
==22840== HEAP SUMMARY:
==22840== in use at exit: 3,289,698 bytes in 16,177 blocks
==22840== total heap usage: 19,718 allocs, 3,541 frees, 3,484,743
bytes allocated
==22840==
==22840== LEAK SUMMARY:
==22840==definitely lost: 0 bytes in 0 blocks
==22840==indirectly lost: 0 bytes in 0 blocks
==22840== possibly lost: 0 bytes in 0 blocks
==22840==still reachable: 3,289,698 bytes in 16,177 blocks
==22840== suppressed: 0 bytes in 0 blocks
==22840== Reachable blocks (those to which a pointer was found) are not
shown.
==22840== To see them, rerun with: --leak-check=full
--show-reachable=yes
==22840==
==22840== For counts of detected and suppressed errors, rerun with: -v
==22840== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from
4)
zsh: segmentation fault USE_ZEND_ALLOC=0 valgrind --leak-check=full php
53347.php
s...@thinkpad ~ % gdb php
GNU gdb (GDB) 7.2-ubuntu
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show
copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
Bug #50921 [Com]: '200 OK' HTTP status despite PHP error
Edit report at http://bugs.php.net/bug.php?id=50921&edit=1 ID: 50921 Comment by: dean at deansas dot org Reported by:phpbug at starurl dot com Summary:'200 OK' HTTP status despite PHP error Status: Bogus Type: Bug Package:HTTP related Operating System: * PHP Version:5.2.12 Block user comment: N Private report: N New Comment: > The reason why display errors needs to be turned of, is because > displayed errors generate output, and output causes the headers > to be send out. I'm afraid we can't do much about this. Can't PHPs error handling first set a 500 header and then output error messages as appropriate? It doesn't seem to me like this is something that can never ever be fixed Previous Comments: [2010-08-12 15:40:32] tyra3l at gmail dot com It's seems that this is a known bug in the xdebug, see: http://bugs.xdebug.org/view.php?id=587 but couldn't fix it without making some changes in php itself: "Before I can address this, there need to be some changes in PHP itself. It doesn't expose some required information to extensions yet that I will need." I hope this get fixed soon. Tyrael [2010-08-12 15:35:41] tyra3l at gmail dot com I can reproduce the problem. I found out, that if I enable xdebug, then I get header 200, if I disable it, then it's 500. Will report it to Derick. Tyrael [2010-03-12 08:37:24] anzenews at volja dot net I am also having huge problems with this - haproxy health checks do not work reliably because of this bug. Please consider reopening it - it is not bogus. PHP doesn't return HTTP error code, even if display_errors is set to 0. One example: This returns an empty page with status code 200: - HTTP/1.1 200 OK DateFri, 12 Mar 2010 07:27:15 GMT Server Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny6 with Suhosin-Patch X-Powered-ByPHP/5.2.6-1+lenny6 VaryAccept-Encoding Content-Encodinggzip Content-Length 20 Keep-Alive timeout=15, max=100 Connection Keep-Alive Content-Typetext/html - Content-Length is 20, probably because of gzip? There are no spaces around PHP block in source code. I have checked phpinfo() and display_errors is set to Off, so there is no error there. Also, I have tried setting it in php.ini - no change. Another problem: parse errors are also not handled correctly (even if display_errors is set to 0 in php.ini). See previous poster's example. Thanks! [2010-02-03 19:03:56] der...@php.net The reason why display errors needs to be turned of, is because displayed errors generate output, and output causes the headers to be send out. I'm afraid we can't do much about this. [2010-02-03 18:01:37] phpbug at starurl dot com Thank you for the swift response Jani. I can confirm that the 500 status code works for the following (runtime error): But fails for parse errors (because the "disply_errors" line doesn't get executed): Firstly, is this dependency really necessary? Just because we have 'display_errors' enabled doesn't mean we want fatal errors to go unlogged and unnoticed because a "200 OK" status is incorrectly returned. Secondly, the majority of PHP developers out there use shared hosting, on which 'display_errors' is normally true and is impossible to change globally - are we saying they're stuck with incorrect HTTP status codes when parse errors occur? The restriction that headers must not already have been sent is of course understandable as it is unavoidable. Not overriding an explicitly set HTTP status code also makes sense. But why not set the status code as "500 Internal Server Error" when any fatal parse/runtime error occurs, regardless of the value of 'display_errors'? This would be consistent with the HTTP spec, which recommends a 5XX response if an error occurs, and is followed by just about every other web server language out there (e.g., ASP, .NET). Many thanks, BJ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=50921 -- Edit this bug report at http://bugs.php.net/bug.php?id=50921&edit=1
Req #49638 [Com]: mbstring default behaviour is unexpected
Edit report at http://bugs.php.net/bug.php?id=49638&edit=1
ID: 49638
Comment by: olivier at oxeva dot fr
Reported by:olivier at oxeva dot fr
Summary:mbstring default behaviour is unexpected
Status: Feedback
Type: Feature/Change Request
Package:*General Issues
Operating System: Linux
PHP Version:5.3SVN-2009-09-23 (snap)
Block user comment: N
Private report: N
New Comment:
Hi,
Test has been restored :)
Olivier
Previous Comments:
[2010-11-19 01:46:55] cataphr...@php.net
The test file is no longer online. Can you provide it?
[2009-09-23 14:11:25] olivier at oxeva dot fr
Just to be clear :
When I said "file is converted to latin1" (bug description), I did not
mean the file is rewritten on disk. I'm saying the _output_ is in
latin1.
[2009-09-23 09:43:04] olivier at oxeva dot fr
Description:
Default behaviour of mbstring concerning php files encoding is
unexpected: If the source file is in UTF-8 (with BOM), the file is
converted to latin1 (mbstring.internal_encoding has default value).
Reproduce code:
---
Here are all tests done on a file named "testmbstring.php"
http://www.ajeux.com/phptests/testmbstring.phps (md5sum:
e663d28964a20ec404e68226effc27d0)
1/ PHP 5.3.0 WITHOUT mbstring
'./configure' '--enable-zend-multibyte'
(on a file without the var_dump())
Hexdump:
31 32 33 c3 a9 31 32 33 e2 82 ac 31 32 33
|123..123...123|
000e
=> result is OK, non-latin1 chars are coded on 2 bytes and 3 bytes
2/ PHP 5.3.0 WITH mbstring
'./configure' '--enable-zend-multibyte' '--enable-mbstring'
a) no specific parameters on .ini
php -i returned the following:
mbstring.detect_order => no value => no value
mbstring.encoding_translation => Off => Off
mbstring.func_overload => 0 => 0
mbstring.http_input => pass => pass
mbstring.http_output => pass => pass
mbstring.http_output_conv_mimetypes => ^(text/|application/xhtml\+xml)
=> ^(text/|application/xhtml\+xml)
mbstring.internal_encoding => no value => no value
mbstring.language => neutral => neutral
mbstring.script_encoding => no value => no value
mbstring.strict_detection => Off => Off
mbstring.substitute_character => no value => no value
Hexdump:
73 74 72 69 6e 67 28 31 30 29 20 22 49 53 4f 2d |string(10)
"ISO-|
0010 38 38 35 39 2d 31 22 0a 31 32 33 e9 31 32 33 3f
|8859-1".123.123?|
0020 31 32 33 |123|
0023
=> Default behaviour is to have latin1 as internal_encoding. Characters
are no longer UTF-8
b) With mbstring.internal_encoding="UTF-8"
php -i returned the following:
mbstring.detect_order => no value => no value
mbstring.encoding_translation => Off => Off
mbstring.func_overload => 0 => 0
mbstring.http_input => pass => pass
mbstring.http_output => pass => pass
mbstring.http_output_conv_mimetypes => ^(text/|application/xhtml\+xml)
=> ^(text/|application/xhtml\+xml)
mbstring.internal_encoding => UTF-8 => UTF-8
mbstring.language => neutral => neutral
mbstring.script_encoding => no value => no value
mbstring.strict_detection => Off => Off
mbstring.substitute_character => no value => no value
Hexdump output:
73 74 72 69 6e 67 28 35 29 20 22 55 54 46 2d 38 |string(5)
"UTF-8|
0010 22 0a 31 32 33 c3 a9 31 32 33 e2 82 ac 31 32 33
|".123..123...123|
0020
=> OK
c) With var_dump(mb_internal_encoding('UTF-8')) on top of file (and
no changes in php.ini)
php -i : output == 2a.
62 6f 6f 6c 28 74 72 75 65 29 0a 73 74 72 69 6e
|bool(true).strin|
0010 67 28 35 29 20 22 55 54 46 2d 38 22 0a 31 32 33 |g(5)
"UTF-8".123|
0020 e9 31 32 33 3f 31 32 33 |.123?123|
0028
=> In spite of the mb_internal_encoding(), the output is not utf-8.
Expected result:
MBString should not change the source file encoding if there is no
default internal_encoding specified by the user
(mbstring.internal_encoding => no value).
If this is expected, at least phpinfo() (php -i) should show to the user
that default internal_encoding is latin1 (ISO-8859-1).
Also, the mb_internal_encoding('UTF-8') function should work on current
file (see test 2c). User should not be forced to change
internal_encoding through php.ini (all users do not have access to it).
Actual result:
--
Versions tested with same behaviour :
- PHP 5.3.0
- PHP 5.3.0 snap 200909230830
- PHP 5.2.3
- PHP 5.2.11
--
Edit this bug report at http://bugs.php.net/bug.php?id=49638&edit=1
Bug #53347 [Opn->Asn]: Segfault in zend_is_inconsistent()
Edit report at http://bugs.php.net/bug.php?id=53347&edit=1
ID: 53347
Updated by: fel...@php.net
Reported by:sebast...@php.net
Summary:Segfault in zend_is_inconsistent()
-Status: Open
+Status: Assigned
Type: Bug
Package:Reproducible crash
Operating System: Linux
PHP Version:trunk-SVN-2010-11-18 (SVN)
-Assigned To:
+Assigned To:dmitry
Block user comment: N
Private report: N
Previous Comments:
[2010-11-19 11:47:47] sebast...@php.net
The following script reproduces the issue:
30 );
public static function isValidFormatCode( $type, $key )
{
return isset( self::${$type}[$key] );
}
}
var_dump( ezcConsoleOutput::isValidFormatCode( 'color', 'gray' ) );
?>
This does not print bool(true) but instead segfaults. Works fine with
PHP_5_3, btw.
s...@thinkpad ~ % USE_ZEND_ALLOC=0 valgrind --leak-check=full php
53347.php
==22840== Memcheck, a memory error detector
==22840== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et
al.
==22840== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for
copyright info
==22840== Command: php 53347.php
==22840==
==22840== Invalid read of size 4
==22840==at 0x92C021: _zend_is_inconsistent (zend_hash.c:54)
==22840==by 0x92EDAE: zend_hash_quick_find (zend_hash.c:929)
==22840==by 0xA49488: zend_fetch_var_address_helper_SPEC_CV_UNUSED
(zend_vm_execute.h:33194)
==22840==by 0xA49DEF: ZEND_FETCH_IS_SPEC_CV_UNUSED_HANDLER
(zend_vm_execute.h:33294)
==22840==by 0x957F02: execute (zend_vm_execute.h:410)
==22840==by 0x91CD93: zend_execute_scripts (zend.c:1195)
==22840==by 0x89661E: php_execute_script (main.c:2341)
==22840==by 0xA57D89: main (php_cli.c:1254)
==22840== Address 0x44 is not stack'd, malloc'd or (recently) free'd
==22840==
==22840==
==22840== Process terminating with default action of signal 11
(SIGSEGV)
==22840== Access not within mapped region at address 0x44
==22840==at 0x92C021: _zend_is_inconsistent (zend_hash.c:54)
==22840==by 0x92EDAE: zend_hash_quick_find (zend_hash.c:929)
==22840==by 0xA49488: zend_fetch_var_address_helper_SPEC_CV_UNUSED
(zend_vm_execute.h:33194)
==22840==by 0xA49DEF: ZEND_FETCH_IS_SPEC_CV_UNUSED_HANDLER
(zend_vm_execute.h:33294)
==22840==by 0x957F02: execute (zend_vm_execute.h:410)
==22840==by 0x91CD93: zend_execute_scripts (zend.c:1195)
==22840==by 0x89661E: php_execute_script (main.c:2341)
==22840==by 0xA57D89: main (php_cli.c:1254)
==22840== If you believe this happened as a result of a stack
==22840== overflow in your program's main thread (unlikely but
==22840== possible), you can try to increase the size of the
==22840== main thread stack using the --main-stacksize= flag.
==22840== The main thread stack size used in this run was 8388608.
==22840==
==22840== HEAP SUMMARY:
==22840== in use at exit: 3,289,698 bytes in 16,177 blocks
==22840== total heap usage: 19,718 allocs, 3,541 frees, 3,484,743
bytes allocated
==22840==
==22840== LEAK SUMMARY:
==22840==definitely lost: 0 bytes in 0 blocks
==22840==indirectly lost: 0 bytes in 0 blocks
==22840== possibly lost: 0 bytes in 0 blocks
==22840==still reachable: 3,289,698 bytes in 16,177 blocks
==22840== suppressed: 0 bytes in 0 blocks
==22840== Reachable blocks (those to which a pointer was found) are not
shown.
==22840== To see them, rerun with: --leak-check=full
--show-reachable=yes
==22840==
==22840== For counts of detected and suppressed errors, rerun with: -v
==22840== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from
4)
zsh: segmentation fault USE_ZEND_ALLOC=0 valgrind --leak-check=full php
53347.php
s...@thinkpad ~ % gdb php
GNU gdb (GDB) 7.2-ubuntu
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show
copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
Req #50662 [Com]: New directive expression_tags
Edit report at http://bugs.php.net/bug.php?id=50662&edit=1 ID: 50662 Comment by: kanenas at comcast dot net Reported by:joseberardo at gmail dot com Summary:New directive expression_tags Status: Open Type: Feature/Change Request Package:Scripting Engine problem Operating System: all PHP Version:6SVN-2010-01-04 (snap) Block user comment: N Private report: N New Comment: Following the discussion on PHP-DEV, everyone likes the idea of unconditionally enabling echo tags. The current "echo_tags-patch" does this. "echo-tags-test" tests it, and "echo-tags-test-2" no longer applies. Patch is now against r305556. Previous Comments: [2010-10-22 13:11:30] kanenas at comcast dot net Here is a patch (off of the PHP 5.3.3 distribution) to add an "echo_tag" configuration option (barely tested) and two tests. It's a good start, for anyone interested. [2010-01-04 22:17:48] joseberardo at gmail dot com Description: The directive short_tags is deprecated and should not be disponible in 6th major version. But, it brings expression tags (http://bugs.php.net/bug.php?id=50662&edit=1
Bug #53352 [Opn->Asn]: open_basedir does not pass through files with matching path
Edit report at http://bugs.php.net/bug.php?id=53352&edit=1 ID: 53352 Updated by: paj...@php.net Reported by:dmitrij at stepanov dot lv Summary:open_basedir does not pass through files with matching path -Status: Open +Status: Assigned Type: Bug Package:Safe Mode/open_basedir Operating System: Windows 7 PHP Version:5.3SVN-2010-11-19 (SVN) -Assigned To: +Assigned To:pajoye Block user comment: N Private report: N Previous Comments: [2010-11-19 09:53:32] dmitrij at stepanov dot lv Description: Right after installing PHP 5.3.4RC1 i get the following error: [19-Nov-2010 08:47:47] PHP Warning: Unknown: open_basedir restriction in effect. File(C:\Users\Dmitry\Repo\InnoForce\AMD\trunc\01_Code\public_html\index.php) is not within the allowed path(s): (C:/Users/Dmitry/Repo/InnoForce/AMD/trunc/01_Code/;C:/Windows/Temp) in Unknown on line 0 [19-Nov-2010 08:47:47] PHP Warning: Unknown: failed to open stream: Operation not permitted in Unknown on line 0 [19-Nov-2010 08:47:47] PHP Fatal error: Unknown: Failed opening required 'C:/Users/Dmitry/Repo/InnoForce/AMD/trunc/01_Code/public_html/index.php' (include_path='.;C:\php5\pear') in Unknown on line 0 It was working with PHP 5.3.3. Test script: --- # open_basedir in apache config php_admin_value open_basedir "C:/Users/Dmitry/Repo/InnoForce/AMD/trunc/01_Code/;C:/Windows/Temp" Expected result: No errors Actual result: -- [19-Nov-2010 08:47:47] PHP Warning: Unknown: open_basedir restriction in effect. File(C:\Users\Dmitry\Repo\InnoForce\AMD\trunc\01_Code\public_html\index.php) is not within the allowed path(s): (C:/Users/Dmitry/Repo/InnoForce/AMD/trunc/01_Code/;C:/Windows/Temp) in Unknown on line 0 [19-Nov-2010 08:47:47] PHP Warning: Unknown: failed to open stream: Operation not permitted in Unknown on line 0 [19-Nov-2010 08:47:47] PHP Fatal error: Unknown: Failed opening required 'C:/Users/Dmitry/Repo/InnoForce/AMD/trunc/01_Code/public_html/index.php' (include_path='.;C:\php5\pear') in Unknown on line 0 -- Edit this bug report at http://bugs.php.net/bug.php?id=53352&edit=1
Bug #48633 [Asn->Csd]: str_pad() with giant lenth value and no memory limit infinite-loops or crashes
Edit report at http://bugs.php.net/bug.php?id=48633&edit=1 ID: 48633 Updated by: il...@php.net Reported by:gwy...@php.net Summary:str_pad() with giant lenth value and no memory limit infinite-loops or crashes -Status: Assigned +Status: Closed Type: Bug Package:Reproducible crash Operating System: Darwin9 (MacOS X 10.5) PHP Version:5.*, 6SVN (2009-07-25) Assigned To:iliaa Block user comment: N Private report: N New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2010-08-09 01:34:21] fel...@php.net It looks be fixed with the Ilia's patch. [2010-05-19 15:57:51] m...@php.net Doesn't do anything harmful for me. [2009-07-18 01:41:59] gwy...@php.net Yes, it happens in all three branches. [2009-07-17 17:40:29] j...@php.net Does this happen with PHP_5_2 and/or HEAD? (if so, update the version properly) [2009-06-22 00:09:12] gwy...@php.net Description: Calling str_pad($anything, PHP_INT_MAX) causes one of four symptoms: 1) If memory_limit is set below 2GB, a fatal error is thrown saying the memory limit is exhausted with an attempt to allocate 2GB. This appears to be the expected result. 2) If memory_limit is set above 2GB, or is unset, PHP (in or out of GDB) enters a massive CPU-eating swap-file-smashing loop. 3) If PHP is being run under valgrind, PHP exits quickly with a memory allocation failure because valgrind's malloc() replacement refuses the "nonsense" allocation request. 4) If PHP is being run under valgrind *and* run-tests.php, PHP crashes with a NULL pointer reference. This is caused by two problems in the str_pad code: 1) The value of num_pad_chars is not bounds-checked in ext/standard/string.c:4830 2) The return value of emalloc() is not checked for NULL on the same line. Reproduce code: --- 1) $ sapi/cli/php ext/standard/tests/string/str_pad_variation5.phpt 2) $ sapi/cli/php -dmemory_limit=1 ext/standard/tests/string/str_pad_variation5.phpt 3) $ valgrind sapi/cli/php -dmemory_limit=1 ext/standard/tests/string/str_pad_variation5.phpt 4) $ PHP_TEST_EXECUTABLE=`pwd`/sapi/cli/php sapi/cli/php run-tests.php -m ext/standard/tests/string/str_pad_variation5.phpt Expected result: In all cases, str_pad() should recognize that its argument is ridiculous and return without trying to make the allocation. Actual result: -- 1) *** Testing str_pad() function: with large value for for 'pad_length' argument *** Fatal error: Allowed memory size of 134217728 bytes exhausted at ext/standard/string.c:4830 (tried to allocate 2147483648 bytes) in ext/standard/tests/strings/str_pad_variation5.phpt on line 25 2) PHP starts running at 100% CPU and eating huge amounts of swap space. 3) *** Testing str_pad() function: with large value for for 'pad_length' argument *** ==31081== Warning: silly arg (-2147221504) to malloc() Fatal error: Out of memory (allocated 524288) at ext/standard/string.c:4830 (tried to allocate 2147483648 bytes) in ext/standard/tests/strings/str_pad_variation5.phpt on line 25 4) ==31145== Warning: silly arg (-2147483648) to malloc() ==31145== Invalid write of size 1 ==31145==at 0x823B13: memcpy (mc_replace_strmem.c:482) ==31145==by 0x2B3F92: zif_str_pad (string.c:4855) ==31145==by 0x3E2D98: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:313) ==31145==by 0x3E9151: ZEND_DO_FCALL_SPEC_CONST_HANDLER (zend_vm_execute.h:1601) ==31145==by 0x3E1B59: execute (zend_vm_execute.h:104) ==31145==by 0x3AE947: zend_execute_scripts (zend.c:1188) ==31145==by 0x31E6CC: php_execute_script (main.c:2196) ==31145==by 0x499E5F: main (php_cli.c:1188) ==31145== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==31145== ==31145== Process terminating with default action of signal 10 (SIGBUS) ==31145== Non-existent physical address at address 0x0 ==31145==at 0x823B13: memcpy (mc_replace_strmem.c:482) ==31145==by 0x2B3F92: zif_str_pad (string.c:4855) ==31145==by 0x3E2D98: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:313) ==31145==by 0x3E9151: ZEND_DO_FCALL_SPEC_CONST_HANDLER (zend_vm_execute.h:1601) ==31145==by 0x3E1B59: execute (zend_vm_execute.h:104) ==31145==by 0x3AE947: zend_execute_scripts (zen
Bug #21993 [Com]: Frameset/PHP conflict
Edit report at http://bugs.php.net/bug.php?id=21993&edit=1
ID: 21993
Comment by: 604joe at gmail dot com
Reported by:black_dragon5 at juno dot com
Summary:Frameset/PHP conflict
Status: No Feedback
Type: Bug
Package:*General Issues
Operating System: Windows NT 5.1 (IIS 5.1)
PHP Version:4.3.0
Block user comment: N
Private report: N
New Comment:
same issue as the last guy who posted.
I'm trying to call a header.php from a frame src= ,,
it has other php files included in it
non get called.
http://spacelite.604industries.com
only started using frameset because IE doesn't like the css position:
fixed;
Previous Comments:
[2009-04-21 14:07:59] satish dot kumar dot us at hotmail dot com
i have a problem in frame set file.if i create a frame set file like
frame.php. in this file am not able to include php files.
[2006-04-27 23:20:27] tueff at gmx dot de
I'm experiencing a similar problem, but not with frames though. It's
just if I try to echo the -- '' and php comments printed
in the xhtml document. Seems to be a bug of IIS 5.1 (no problems with
Apache), no difference if the xml '...?>' end-tag is seperated via
string concatenation ('...?'.'>') either. I also get an error from IIS
at System shutdown (sorry, I'd have to reproduce it to remember the
exact error message and I'm not ready for that right now).
[2003-02-20 08:07:24] sni...@php.net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
[2003-02-13 20:10:04] mag...@php.net
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
[2003-02-02 21:39:51] black_dragon5 at juno dot com
I have uploaded the files (zipped) for download and testing. The file
is located at: http://force.digitalrice.com/upload/frameset.zip
My friend is running Windows XP Home (alas, no built-in IIS) with Apache
2.0.43 and the Apache PHP 4.3.0 module. He tested it and it works fine.
I'm not sure if it will work under the ISAPI version, but so far it
seems to be limited to the CGI version.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/bug.php?id=21993
--
Edit this bug report at http://bugs.php.net/bug.php?id=21993&edit=1
Req #25630 [Com]: session_decode feature
Edit report at http://bugs.php.net/bug.php?id=25630&edit=1
ID: 25630
Comment by: lealcy at gmail dot com
Reported by:marrtins at hackers dot lv
Summary:session_decode feature
Status: Open
Type: Feature/Change Request
Package:Feature/Change Request
PHP Version:4.3.3
Block user comment: N
Private report: N
New Comment:
There is no need for a new function to do this, just change the
prototype of
session_decode function to
function session_decode($data, $overwrite_session = true);
then make the function returns an array with the session data always,
this let to
the programmer to choose overwrite the $_SESSION or just get the decoded
array.
Previous Comments:
[2003-09-23 03:45:43] marrtins at hackers dot lv
so i'll try to explain now :)
my homepage uses sessions(i wrote a session handler) to store users
information - some username, visited sections, etc data
i wrote a script, to check who is online right now - scanning for
sessions active in last 3 minutes. script reads those session data from
mysql table. data looks like this:
$session_data="user|a:2:{s:8:"username";s:6:"foobar";s:9:"useremail";s:0:"";}..."
sou, it will be usefull to have function to get all these variables in
one array. for example
$session_vars = get_session_vars($session_data);
as a result will be
$session_vars['username'] = 'foobar';
$session_vars['useremail'] = '';
...
and so on.
[2003-09-23 03:28:56] sni...@php.net
Would you please explain this a bit better?
Like some example maybe..?
[2003-09-22 12:52:59] marrtins at hackers dot lv
Description:
need to store session decoded data in array not only in variables.
thnx!
--
Edit this bug report at http://bugs.php.net/bug.php?id=25630&edit=1
Bug #41631 [Com]: default_socket_timeout does not work with SSL
Edit report at http://bugs.php.net/bug.php?id=41631&edit=1 ID: 41631 Comment by: chrisw at networkm dot co dot uk Reported by:david at acz dot org Summary:default_socket_timeout does not work with SSL Status: Assigned Type: Bug Package:OpenSSL related Operating System: * PHP Version:5.2, 5.3 Assigned To:pajoye Block user comment: N Private report: N New Comment: Cannot reproduce this on Windows Server 2003 R2 Enterprise/PHP 5.2.9-2 fopen() returns after $default_socket_timeout seconds if the server does not respond. Previous Comments: [2010-06-13 15:12:55] fel...@php.net Pierre, doesn't the attached patch fix this issue? [2010-03-15 10:33:47] jason at kapoks dot co dot uk Had this issue over the weekend with 5.2.10. Essentially this means our entire service is vulnerable to Denial of Service. Linux localhost.localdomain 2.6.18-164.el5 #1 SMP Thu Sep 3 03:33:56 EDT 2009 i686 i686 i386 GNU/Linux CentOS release 5.3 (Final) PHP 5.2.10 (cli) (built: Jun 21 2009 11:10:43) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies with Zend Extension Manager v1.2.2, Copyright (c) 2003-2007, by Zend Technologies with Zend Optimizer v3.3.3, Copyright (c) 1998-2007, by Zend Technologies [2010-01-18 19:16:42] wdierkes at 5dollarwhitebox dot org This is also reproducible on 5.2.12 as described. As mentioned previously, this has the potentially to have major effects (Denial of Servide) etc due to processes hanging and never timing out. # cat /etc/redhat-release Red Hat Enterprise Linux Server release 5.4 (Tikanga) # php -v PHP 5.2.12 (cli) (built: Dec 17 2009 12:23:35) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies # uname -a Linux linux 2.6.18-164.el5 #1 SMP Tue Aug 18 15:51:48 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux [2009-10-16 20:14:25] arkadi dot shishlov at gmail dot com At least it would be helpful to set TCP keep-alive on socket so OS could timeout it eventually, otherwise there are connections stuck for days. [2009-09-24 19:30:14] srina...@php.net bug #48524 depends on this fix (http://bugs.php.net/bug.php?id=48524&edit=1) i wish , bug tracking system allowed to be able to close a bug as duplicate of another. then, we could close 48524 as dup of this (41631). this can also trigger the internal score for this bug to be increased (helping in set priority etc). The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=41631 -- Edit this bug report at http://bugs.php.net/bug.php?id=41631&edit=1
[PHP-BUG] Req #53356 [NEW]: Allow use function return value in write context
From:
Operating system:
PHP version: 5.3.3
Package: Scripting Engine problem
Bug Type: Feature/Change Request
Bug description:Allow use function return value in write context
Description:
Allow use function return value in write context if this function return
value by reference (Such as c or c++)
Test script:
---
function &test() {
static $a = 0;
return $a;
}
print(++test());
print(++test());
print(++test());
Expected result:
123
Actual result:
--
Fatal error
--
Edit bug report at http://bugs.php.net/bug.php?id=53356&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53356&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53356&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53356&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53356&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53356&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53356&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53356&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53356&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53356&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53356&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53356&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53356&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53356&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53356&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53356&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53356&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53356&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53356&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53356&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53356&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53356&r=mysqlcfg
[PHP-BUG] Req #53357 [NEW]: Problem with getMethod of ReflectionClass
From:
Operating system: Windows 7/all
PHP version: 5.3.3
Package: Reflection related
Bug Type: Feature/Change Request
Bug description:Problem with getMethod of ReflectionClass
Description:
---
>From manual page: http://www.php.net/reflectionclass.getmethod
---
If you use getMethod() on a ReflecitonClass Object, for a class, that
inherits its method from a parent class, you get a ReflectionMethod Object,
that links to the parent class. There is no possibility to get a
ReflectionMethod Object, that is connected to the class linked to the
ReflectionClass Object.
This beheaviour is not nice, if you want to use the ReflectionMethod Object
to call a static method. We could not figure out a possibility to call the
method on the child class.
A second argument on getMethod() would be nice. It could be a flag, wether
getMethod should return a ReflectionMethod object, which is connected to
the class where the method was defined or an object which is connected to
the class, that was used for the ReflectionClass.
Test script:
---
class ParentClass {
public static function foo(){
echo get_called_class();
}
}
class ChildClass extends MainClass {
}
$class = new ReflectionClass('ChildClass');
$method = $class->getMethod('foo');
$method->invoke(null); // outputs ParentClass instead of expected
ChildClass
Expected result:
ChildClass
Actual result:
--
ParentClass
--
Edit bug report at http://bugs.php.net/bug.php?id=53357&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53357&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53357&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53357&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53357&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53357&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53357&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53357&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53357&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53357&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53357&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53357&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53357&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53357&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53357&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53357&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53357&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53357&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53357&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53357&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53357&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53357&r=mysqlcfg
Bug #53152 [Opn->Bgs]: mysql_insert_id return 0
Edit report at http://bugs.php.net/bug.php?id=53152&edit=1
ID: 53152
Updated by: ka...@php.net
Reported by:genix at arctoz dot de
Summary:mysql_insert_id return 0
-Status: Open
+Status: Bogus
Type: Bug
Package:MySQL related
Operating System: Linux 2.6.34.6-54.fc13.i686
PHP Version:5.3.3
Block user comment: N
Private report: N
New Comment:
.
Previous Comments:
[2010-10-27 03:05:46] uramihsayibok at gmail dot com
The INSERT query is invalid - "table" is a reserved word.
Using
> CREATE TABLE `table` (id INT AUTO_INCREMENT PRIMARY KEY, foo TEXT)
> mysql_query("INSERT INTO `table` VALUES('', 'TEST')");
it works for me. Which isn't surprising considering a bug this obvious
would have
been noticed a long time ago.
Check your MySQL client and server versions and/or give a real,
self-contained
test script.
[2010-10-25 18:50:23] genix at arctoz dot de
Description:
When calling mysql_insert_id() after insert, php returns 0, but if
queried "SELECT LAST_INSERT_ID()" it returns the right value.
Test script:
---
Expected result:
LAST-ID (Function): 38
LAST-ID (Query): 38
Actual result:
--
LAST-ID (Function): 0
LAST-ID (Query): 38
--
Edit this bug report at http://bugs.php.net/bug.php?id=53152&edit=1
[PHP-BUG] Req #53358 [NEW]: API queries in php.ini
From: Operating system: PHP version: Irrelevant Package: *Configuration Issues Bug Type: Feature/Change Request Bug description:API queries in php.ini Description: I would rather appreciate a php ini section analogous to [HOST=] querying the SAPI, e.g. [SAPI=CLI] extension = php-gtk2.so in order to prevent the extension from being loaded when PHP is running as apache module or cgi. This would be helpful for distributions with like php.ini regardless of SAPI, in contrast to debian with its API-depending php.ini location. A workaround is a modified shebang line: #!/usr/bin/php -d extension=php_gtk2.so but this cannot be considered a good solution. Maybe this is not only php-gtk related. -- Edit bug report at http://bugs.php.net/bug.php?id=53358&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53358&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53358&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53358&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53358&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53358&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53358&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53358&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53358&r=needscript Try newer version: http://bugs.php.net/fix.php?id=53358&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53358&r=support Expected behavior: http://bugs.php.net/fix.php?id=53358&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53358&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53358&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53358&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53358&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53358&r=dst IIS Stability: http://bugs.php.net/fix.php?id=53358&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53358&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53358&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53358&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53358&r=mysqlcfg
Bug #47168 [Asn->Csd]: printf of floating point variable prints maximum of 40 decimal places
Edit report at http://bugs.php.net/bug.php?id=47168&edit=1 ID: 47168 Updated by: il...@php.net Reported by:exploringbinary at gmail dot com Summary:printf of floating point variable prints maximum of 40 decimal places -Status: Assigned +Status: Closed Type: Bug Package:Math related Operating System: * PHP Version:5.2.9 Assigned To:iliaa Block user comment: N Private report: N New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2010-11-19 17:36:12] il...@php.net Automatic comment from SVN on behalf of iliaa Revision: http://svn.php.net/viewvc/?view=revision&revision=305561 Log: Fixed bug #47168 (printf of floating point variable prints maximum of 40 decimal places). [2009-04-30 14:44:43] exploringbinary at gmail dot com A reader of my blog pointed out that serialize and unserialize have similar issues. I ran some tests and discovered that 2^-143 is the smallest negative power of two that PHP can serialize, and 2^-40 is the smallest it can unserialize. Here's are the testcases: This code works it prints d:8.9683101716788292539118693330554632401936764280097009392452370 16894662929189507849514484405517578125E-44; This code fails it prints d:4.4841550858394146269559346665277316200968382140048504696226185 08447331464594753924757242202758789062E-44; This code works it prints 0.9094947017729282379150390625 This code fails it prints Fails, prints 0.4547473508864641189575195312 [2009-04-30 03:48:24] ras...@php.net There are a couple of other places that need to be changed. I have a patch but I haven't had a chance to go through and fix the test cases yet. I'll get to it before RC2 next week. [2009-04-30 01:23:58] ivan dot rey at inpltda dot com I agree also. Full precision should be available for the developer. I wonder if recompiling php with a different CAP in In php-5.2.8\ext\standard\formatted_print.c I found this: #define MAX_FLOAT_PRECISION 40 is the actual solution or if it has some further implications. [2009-04-29 05:21:05] ras...@php.net I agree with Rick here. The 40-digit limit is strangely arbitrary and doesn't match the size of the double. We are hiding available precision here. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/bug.php?id=47168 -- Edit this bug report at http://bugs.php.net/bug.php?id=47168&edit=1
[PHP-BUG] Bug #53360 [NEW]: wrong operator precedence
From: Operating system: any PHP version: Irrelevant Package: Scripting Engine problem Bug Type: Bug Bug description:wrong operator precedence Description: According to documentation, comparison operators (like ==) have higher priority than bitwise ones (like &). However, the ==operator has higher precedence than &. It was tested on Debian Squeeze (PHP 5.3.2-1 with Suhosin-Patch) and Debian Lenny (PHP 5.2.6-1+lenny9 with Suhosin-Patch 0.9.6.2). Test script: --- $flag = 1; var_dump($flag & 3 == 1); var_dump(($flag & 3) == 1); Expected result: bool(true) bool(true) Actual result: -- int(0) bool(true) -- Edit bug report at http://bugs.php.net/bug.php?id=53360&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53360&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53360&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53360&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53360&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53360&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53360&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53360&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53360&r=needscript Try newer version: http://bugs.php.net/fix.php?id=53360&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53360&r=support Expected behavior: http://bugs.php.net/fix.php?id=53360&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53360&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53360&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53360&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53360&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53360&r=dst IIS Stability: http://bugs.php.net/fix.php?id=53360&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53360&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53360&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53360&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53360&r=mysqlcfg
Req #53351 [Opn->Csd]: Autoload should not cancel if called for same class twice
Edit report at http://bugs.php.net/bug.php?id=53351&edit=1
ID: 53351
Updated by: ka...@php.net
Reported by:php at addiks dot de
Summary:Autoload should not cancel if called for same class
twice
-Status: Open
+Status: Closed
Type: Feature/Change Request
Package:SPL related
Operating System: Ubuntu 10.04
PHP Version:5.3.3
-Assigned To:
+Assigned To:Kalle
Block user comment: N
Private report: N
New Comment:
This isn't really a logically solution to start skipping calls as the
compiler has no idea about its previous state.
If you have:
a.php:
class A {
}
b.php:
class B extends A {
}
and in your main script:
function __autoload($class) {
require $class . '.php';
}
then it will work, because in your current case you are ending up in a
recursive call and will either have a fatal error about it or a
memory_limit reach (as the Engine will keep running the code until it
runs dry of memory)
So the proper solution here is to not have such statically code that
depends on other stuff in the autoloader, and its not something that any
of us are going to implement, sorry :)
Previous Comments:
[2010-11-19 09:46:13] php at addiks dot de
Description:
hi,
currently i am using a require-all-script in my system that just plain
require-once's all files with correct ending
(".class.php";".mdl.php";...) it can find.
This happens inside of an autoload-method,
calling itself again when a depency (e.g. inheritance) occours.
when called again, it will skip all already called includes, since they
are require-_once_. Whith this loader i can just add a class file and it
will be loaded automaticly without needing me to register it somewhere
manually.
But it seems i have misunderstood the documentation,
because i now have noticed that when two classes extends the same
class,
it will fail at the second child-class complaining that the parent-class
is missing instead of just calling autoload again for the same class,
which i thought will happen.
now i have to build the initial-loader much more complex, holding a
cached depency-list of classes or looking into the source-code when
called.
Test script:
---
Expected result:
Actual result:
--
--
Edit this bug report at http://bugs.php.net/bug.php?id=53351&edit=1
Bug #53360 [Opn->Bgs]: wrong operator precedence
Edit report at http://bugs.php.net/bug.php?id=53360&edit=1 ID: 53360 Updated by: s...@php.net Reported by:torkvemada at nigma dot ru Summary:wrong operator precedence -Status: Open +Status: Bogus Type: Bug Package:Scripting Engine problem Operating System: any PHP Version:Irrelevant Block user comment: N Private report: N New Comment: Higher precedence implies "tighter binding", so var_dump($flag & 3 == 1); is the same as var_dump($flag & (3 == 1)); Both of these return int(0) Previous Comments: [2010-11-19 18:53:17] torkvemada at nigma dot ru Description: According to documentation, comparison operators (like ==) have higher priority than bitwise ones (like &). However, the ==operator has higher precedence than &. It was tested on Debian Squeeze (PHP 5.3.2-1 with Suhosin-Patch) and Debian Lenny (PHP 5.2.6-1+lenny9 with Suhosin-Patch 0.9.6.2). Test script: --- $flag = 1; var_dump($flag & 3 == 1); var_dump(($flag & 3) == 1); Expected result: bool(true) bool(true) Actual result: -- int(0) bool(true) -- Edit this bug report at http://bugs.php.net/bug.php?id=53360&edit=1
[PHP-BUG] Bug #53362 [NEW]: Segmentation fault when extending SplFixedArray
From: Operating system: Linux, Windows PHP version: 5.3.3 Package: SPL related Bug Type: Bug Bug description:Segmentation fault when extending SplFixedArray Description: Segmentation fault when extending SplFixedArray and working with it as with an array. Test script: --- http://bugs.php.net/bug.php?id=53362&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=53362&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=53362&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=53362&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=53362&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=53362&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=53362&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=53362&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=53362&r=needscript Try newer version: http://bugs.php.net/fix.php?id=53362&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=53362&r=support Expected behavior: http://bugs.php.net/fix.php?id=53362&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=53362&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=53362&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=53362&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53362&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=53362&r=dst IIS Stability: http://bugs.php.net/fix.php?id=53362&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=53362&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=53362&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=53362&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=53362&r=mysqlcfg
Bug #53362 [Opn]: Segmentation fault when extending SplFixedArray
Edit report at http://bugs.php.net/bug.php?id=53362&edit=1 ID: 53362 User updated by:public at grik dot net Reported by:public at grik dot net Summary:Segmentation fault when extending SplFixedArray Status: Open Type: Bug Package:SPL related Operating System: Linux, Windows PHP Version:5.3.3 Block user comment: N Private report: N New Comment: Program received signal SIGSEGV, Segmentation fault. 0x005cbfcf in spl_fixedarray_object_write_dimension (object=0x80232c818, offset=0x0, value=0x8023310a8) at /usr/ports/lang/php5/work/php-5.3.3/ext/spl/spl_fixedarray.c:409 409 in /usr/ports/lang/php5/work/php-5.3.3/ext/spl/spl_fixedarray.c Previous Comments: [2010-11-19 20:15:39] public at grik dot net Description: Segmentation fault when extending SplFixedArray and working with it as with an array. Test script: --- http://bugs.php.net/bug.php?id=53362&edit=1
Bug #53362 [Opn->Fbk]: Segmentation fault when extending SplFixedArray
Edit report at http://bugs.php.net/bug.php?id=53362&edit=1 ID: 53362 Updated by: paj...@php.net Reported by:public at grik dot net Summary:Segmentation fault when extending SplFixedArray -Status: Open +Status: Feedback Type: Bug Package:SPL related Operating System: Linux, Windows PHP Version:5.3.3 Block user comment: N Private report: N New Comment: Can you try using 5.3.4RC1 please? Previous Comments: [2010-11-19 20:27:30] public at grik dot net Program received signal SIGSEGV, Segmentation fault. 0x005cbfcf in spl_fixedarray_object_write_dimension (object=0x80232c818, offset=0x0, value=0x8023310a8) at /usr/ports/lang/php5/work/php-5.3.3/ext/spl/spl_fixedarray.c:409 409 in /usr/ports/lang/php5/work/php-5.3.3/ext/spl/spl_fixedarray.c [2010-11-19 20:15:39] public at grik dot net Description: Segmentation fault when extending SplFixedArray and working with it as with an array. Test script: --- http://bugs.php.net/bug.php?id=53362&edit=1
Bug #53362 [Fbk->Csd]: Segmentation fault when extending SplFixedArray
Edit report at http://bugs.php.net/bug.php?id=53362&edit=1 ID: 53362 Updated by: fel...@php.net Reported by:public at grik dot net Summary:Segmentation fault when extending SplFixedArray -Status: Feedback +Status: Closed Type: Bug Package:SPL related Operating System: Linux, Windows PHP Version:5.3.3 -Assigned To: +Assigned To:felipe Block user comment: N Private report: N New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2010-11-19 21:07:34] fel...@php.net Automatic comment from SVN on behalf of felipe Revision: http://svn.php.net/viewvc/?view=revision&revision=305565 Log: - Fixed bug #53362 (Segmentation fault when extending SplFixedArray) [2010-11-19 20:32:56] paj...@php.net Can you try using 5.3.4RC1 please? [2010-11-19 20:27:30] public at grik dot net Program received signal SIGSEGV, Segmentation fault. 0x005cbfcf in spl_fixedarray_object_write_dimension (object=0x80232c818, offset=0x0, value=0x8023310a8) at /usr/ports/lang/php5/work/php-5.3.3/ext/spl/spl_fixedarray.c:409 409 in /usr/ports/lang/php5/work/php-5.3.3/ext/spl/spl_fixedarray.c [2010-11-19 20:15:39] public at grik dot net Description: Segmentation fault when extending SplFixedArray and working with it as with an array. Test script: --- http://bugs.php.net/bug.php?id=53362&edit=1
Bug #53360 [Bgs]: wrong operator precedence
Edit report at http://bugs.php.net/bug.php?id=53360&edit=1 ID: 53360 User updated by:torkvemada at nigma dot ru Reported by:torkvemada at nigma dot ru Summary:wrong operator precedence Status: Bogus Type: Bug Package:Scripting Engine problem Operating System: any PHP Version:Irrelevant Block user comment: N Private report: N New Comment: Ah, sorry, I've read the docs not very careful :( Ticket should be closed. Previous Comments: [2010-11-19 19:42:05] s...@php.net Higher precedence implies "tighter binding", so var_dump($flag & 3 == 1); is the same as var_dump($flag & (3 == 1)); Both of these return int(0) [2010-11-19 18:53:17] torkvemada at nigma dot ru Description: According to documentation, comparison operators (like ==) have higher priority than bitwise ones (like &). However, the ==operator has higher precedence than &. It was tested on Debian Squeeze (PHP 5.3.2-1 with Suhosin-Patch) and Debian Lenny (PHP 5.2.6-1+lenny9 with Suhosin-Patch 0.9.6.2). Test script: --- $flag = 1; var_dump($flag & 3 == 1); var_dump(($flag & 3) == 1); Expected result: bool(true) bool(true) Actual result: -- int(0) bool(true) -- Edit this bug report at http://bugs.php.net/bug.php?id=53360&edit=1
Bug #53061 [Opn->Wfx]: filesystem functions deal poorly with out of disk space conditions
Edit report at http://bugs.php.net/bug.php?id=53061&edit=1
ID: 53061
Updated by: cataphr...@php.net
Reported by:crrodriguez at opensuse dot org
Summary:filesystem functions deal poorly with out of disk
space conditions
-Status: Open
+Status: Wont fix
Type: Bug
Package:Filesystem function related
Operating System: *nix
PHP Version:5.3SVN-2010-10-14 (SVN)
Block user comment: N
Private report: N
New Comment:
Closeing as Wont Fix per the exposed reasons.
Previous Comments:
[2010-10-16 02:18:04] cataphr...@php.net
Well, there's the hint that the return value is smaller than
strlen(str_repeat("fail", 1024000)) = 4096000.
I'm not sure if adding a warning here is appropriate, we try to avoid
warnings in correct scripts so that programmers don't have to use "@" to
have notice/warning free code. Even if we consider a disk full an
exceptional circumstance that merited breaking this guideline, a warning
would be of little use; unless the logs are in a separate filesystems,
the warning message would not be able to be logged.
So:
* We can't return false, because a part of the data may have been
written and we need to return how much.
* A warning would be of no use in most circumstances.
Maybe we could return a false+warning if no data has been written, but
it seems dangerous because sometimes programmers would be warned of an
out-of-disk-space conditional and other times they wouldn't.
[2010-10-15 02:47:11] crrodriguez at opensuse dot org
A liltte bit better test case:
# dd if=/dev/zero of=/tmp/vfs bs=1024 count=1024
# losetup /dev/loop0 /tmp/vfs
# mkfs -t ext2 -m 1 -v /dev/loop0
# mkdir /mnt/vfs
# mount -t ext2 /dev/loop0 /mnt/vfs
int(1003520)
bool(true)
bool(true)
ls -l /mnt/vfs/foo.txt
-rw-r--r-- 1 root root 1003520 oct 14 21:43 /mnt/vfs/foo.txt
Partial data on disk, no warning or return values hinting the problem.
[2010-10-14 07:00:13] cataphr...@php.net
Why would fflush return false? Nothing was written by fwrite, so the
flush is a no-op.
[2010-10-14 06:35:11] crrodriguez at opensuse dot org
Description:
Filesystem functions have IMHO the wrong behaviuor on disk-full
conditions
Test script:
---
http://bugs.php.net/bug.php?id=53061&edit=1
Req #53357 [Opn->Asn]: Problem with getMethod of ReflectionClass
Edit report at http://bugs.php.net/bug.php?id=53357&edit=1
ID: 53357
Updated by: johan...@php.net
Reported by:jonas dot jones at gmx dot ch
Summary:Problem with getMethod of ReflectionClass
-Status: Open
+Status: Assigned
Type: Feature/Change Request
Package:Reflection related
PHP Version:5.3.3
-Assigned To:
+Assigned To:johannes
Block user comment: N
Private report: N
New Comment:
The reflection API is supposed to tell "the truth". Extending the
ReflectionClass::getMethod() method is therefore no option. The only
thing I can imagine is hanving ReflectionMethod::invoke() to accept a
string, instead of an instance, as first parameter for defining the
scope. I will look into that.
Previous Comments:
[2010-11-19 16:31:22] jonas dot jones at gmx dot ch
Description:
---
>From manual page: http://www.php.net/reflectionclass.getmethod
---
If you use getMethod() on a ReflecitonClass Object, for a class, that
inherits its method from a parent class, you get a ReflectionMethod
Object, that links to the parent class. There is no possibility to get a
ReflectionMethod Object, that is connected to the class linked to the
ReflectionClass Object.
This beheaviour is not nice, if you want to use the ReflectionMethod
Object to call a static method. We could not figure out a possibility to
call the method on the child class.
A second argument on getMethod() would be nice. It could be a flag,
wether getMethod should return a ReflectionMethod object, which is
connected to the class where the method was defined or an object which
is connected to the class, that was used for the ReflectionClass.
Test script:
---
class ParentClass {
public static function foo(){
echo get_called_class();
}
}
class ChildClass extends MainClass {
}
$class = new ReflectionClass('ChildClass');
$method = $class->getMethod('foo');
$method->invoke(null); // outputs ParentClass instead of expected
ChildClass
Expected result:
ChildClass
Actual result:
--
ParentClass
--
Edit this bug report at http://bugs.php.net/bug.php?id=53357&edit=1
Bug #52389 [Opn->Fbk]: Memory (de)allocation problem for pgsql notices
Edit report at http://bugs.php.net/bug.php?id=52389&edit=1 ID: 52389 Updated by: fel...@php.net Reported by:miroslav dot zacek at skype dot net Summary:Memory (de)allocation problem for pgsql notices -Status: Open +Status: Feedback Type: Bug Package:PostgreSQL related Operating System: Linux (Kubuntu) PHP Version:5.3.2 Block user comment: N Private report: N New Comment: Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. Previous Comments: [2010-10-25 23:51:58] php at maxnet dot eu Oops, didn't notice the patch was for 5.3 Applied it to 5.2.14 [2010-10-25 23:37:21] php at maxnet dot eu The pgsql-fixed.diff patch results in a lot more core dumps for me than the original problem under FreeBSD. Seems to happen on any notice. == Oct 25 23:23:02 www3 kernel: pid 76489 (php), uid 80: exited on signal 6 (core dumped) Oct 25 23:23:03 www3 kernel: pid 76502 (php), uid 80: exited on signal 6 (core dumped) Oct 25 23:23:13 www3 kernel: pid 76483 (php), uid 80: exited on signal 6 (core dumped) Oct 25 23:23:15 www3 kernel: pid 76503 (php), uid 80: exited on signal 6 (core dumped) Oct 25 23:23:22 www3 kernel: pid 76485 (php), uid 80: exited on signal 6 (core dumped) Oct 25 23:23:22 www3 kernel: pid 76487 (php), uid 80: exited on signal 6 (core dumped) Oct 25 23:23:38 www3 kernel: pid 76506 (php), uid 80: exited on signal 6 (core dumped) Oct 25 23:23:45 www3 kernel: pid 76511 (php), uid 80: exited on signal 6 (core dumped) Oct 25 23:23:46 www3 kernel: pid 76515 (php), uid 80: exited on signal 6 (core dumped) Oct 25 23:23:51 www3 kernel: pid 76508 (php), uid 80: exited on signal 6 (core dumped) Oct 25 23:23:52 www3 kernel: pid 76513 (php), uid 80: exited on signal 6 (core dumped) Oct 25 23:24:04 www3 kernel: pid 76521 (php), uid 80: exited on signal 6 (core dumped) Oct 25 23:24:07 www3 kernel: pid 76525 (php), uid 80: exited on signal 6 (core dumped) Oct 25 23:24:09 www3 kernel: pid 76522 (php), uid 80: exited on signal 6 (core dumped) Oct 25 23:24:10 www3 kernel: pid 76526 (php), uid 80: exited on signal 6 (core dumped) Oct 25 23:24:16 www3 kernel: pid 76520 (php), uid 80: exited on signal 6 (core dumped) Oct 25 23:24:23 www3 kernel: pid 76527 (php), uid 80: exited on signal 6 (core dumped) == == www3# gdb /usr/local/bin/php php.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 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 "amd64-marcel-freebsd"... Core was generated by `php'. Program terminated with signal 6, Aborted. Reading symbols from /lib/libcrypt.so.3...done. Loaded symbols for /lib/libcrypt.so.3 Reading symbols from /lib/libz.so.3...done. Loaded symbols for /lib/libz.so.3 Reading symbols from /usr/local/pgsql/lib/libpq.so.5...done. Loaded symbols for /usr/local/pgsql/lib/libpq.so.5 Reading symbols from /lib/libm.so.4...done. Loaded symbols for /lib/libm.so.4 Reading symbols from /usr/local/lib/libxml2.so.5...done. Loaded symbols for /usr/local/lib/libxml2.so.5 Reading symbols from /usr/local/lib/libiconv.so.3...done. Loaded symbols for /usr/local/lib/libiconv.so.3 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/libpthread.so.2...done. Loaded symbols for /lib/libpthread.so.2 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x0008012990bc in kill () from /lib/libc.so.6 [New LWP 100277] (gdb) bt #0 0x0008012990bc in kill () from /lib/libc.so.6 #1 0x000801297f4d in abort () from /lib/libc.so.6 #2 0x000801231025 in _UTF8_init () from /lib/libc.so.6 #3 0x00080123105c in _UTF8_init () from /lib/libc.so.6 #4 0x000801231ffd in _UTF8_init () from /lib/libc.so.6 #5 0x004a6431 in _php_pgsql_notice_ptr_dtor (ptr=0x12ada) at /usr/home/max/tmp/php-5.2.14/ext/pgsql/pgsql.c:397 #6 0x005b13e2 in _zend_hash_index_update_or_next_insert (ht=0x85b928, h=4, pData=0x7fff7d78, nDataSize=8, pDest=0x0, flag=76482) a
Bug #53199 [Com]: Phar doesn't work with '--enable-zend-multibyte' option
Edit report at http://bugs.php.net/bug.php?id=53199&edit=1
ID: 53199
Comment by: php at group dot apple dot com
Reported by:brt dot river at gmail dot com
Summary:Phar doesn't work with '--enable-zend-multibyte'
option
Status: Feedback
Type: Bug
Package:PHAR related
Operating System: Mac OS X 10.6
PHP Version:5.3.3
Block user comment: N
Private report: N
New Comment:
The patch contained a logic flaw (compared against ptr and not size), so
I
reworked it to match the style of the other if-blocks in the function
and have
attached it as "phar.patch".
The patch file also contains a fix for Makefile.frag which removes
$(INSTALL_ROOT)
from the bang command path since INSTALL_ROOT is the mastering location,
not the
deployment location.
Previous Comments:
[2010-11-18 09:51:05] cataphr...@php.net
If it does indeed resolve the issue, this should be marked as duplicate
of bug #42396.
[2010-11-18 08:48:19] cataphr...@php.net
Can you please see if the attached patch resolves the issue?
Thanks.
[2010-11-18 08:47:39] cataphr...@php.net
The following patch has been added/updated:
Patch Name: bug53199.patch
Revision: 1290066459
URL:
http://bugs.php.net/patch-display.php?bug=53199&patch=bug53199.patch&revision=1290066459
[2010-11-18 07:02:28] php at group dot apple dot com
I have been debugging a similar report with the phar CLI. Executing "php
phar.php"
(using the generated php/ext/phar/phar.php) works properly, but the
resulting
phar.phar does not. I have tried modifying the stub (via phar.php) to
print
debugging information but that only produces more "?" characters.
Attempting to
debug with Xdebug and MacGDBp wouldn't step through the first line
before
terminating.
[2010-10-29 10:22:36] brt dot river at gmail dot com
Description:
I'm using PHP 5.3.3 with '--enable-zend-multibyte' under Mac OS X.
My script calls my phar archive directly, The result characters are
garbled.
Test script:
---
* create.php
setStub('http://bugs.php.net/bug.php?id=53199&edit=1
