#24550 [Csd->Opn]: tokenizing & syntax highlighting crashes
ID: 24550
Updated by: [EMAIL PROTECTED]
Reported By: hos dot endre at axelero dot hu
-Status: Closed
+Status: Open
Bug Type: Zend Engine 2 problem
-Operating System: *
+Operating System: Windows XP
-PHP Version: 5.0.0b2-dev
+PHP Version: CVS HEAD
New Comment:
token_get_all('function_name : NULL;
As near as I can tell, active_op_array doesn't exist. I suspect the
tokenizer does not properly prepare for parsing, but have no idea how
to investigate further. I need this one to be fixed for phpDocumentor
2.0 to work at all wiht __METHOD__ in source code.
Thanks,
Greg
Previous Comments:
[2003-07-27 07:25:52] [EMAIL PROTECTED]
This bug has been fixed in CVS.
In case this was a PHP problem, 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/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
[2003-07-09 06:47:16] [EMAIL PROTECTED]
[Switching to Thread 1024 (runnable)]
lex_scan (zendlval=0xb2b8) at
/usr/src/web/php/php5/Zend/zend_language_scanner.l:988
988 char *func_name = CG(active_op_array)->function_name;
(gdb) bt
#0 lex_scan (zendlval=0xb2b8) at
/usr/src/web/php/php5/Zend/zend_language_scanner.l:988
#1 0x813f070 in zend_highlight (syntax_highlighter_ini=0xb354) at
/usr/src/web/php/php5/Zend/zend_highlight.c:176
#2 0x81313db in highlight_string (str=0x40298ccc,
syntax_highlighter_ini=0xb354,
str_name=0x402992d4 "Command line code(1) : highlighted code")
at /usr/src/web/php/php5/Zend/zend_language_scanner.l:461
#3 0x80c8094 in zif_highlight_string (ht=1, return_value=0x402992b4,
this_ptr=0x0, return_value_used=0)
at /usr/src/web/php/php5/ext/standard/basic_functions.c:2251
#4 0x816b63d in zend_do_fcall_common_helper (execute_data=0xb43c,
op_array=0x4029905c)
at /usr/src/web/php/php5/Zend/zend_execute.c:2664
#5 0x816bbc2 in zend_do_fcall_handler (execute_data=0xb43c,
op_array=0x4029905c)
at /usr/src/web/php/php5/Zend/zend_execute.c:2793
#6 0x815bc54 in execute (op_array=0x4029905c) at
/usr/src/web/php/php5/Zend/zend_execute.c:1266
#7 0x813ea61 in zend_eval_string (str=0xb7d7
"highlight_string(', argc=3,
argv=0xb674, init=0x80696a0 <_init>,
fini=0x8175724 <_fini>, rtld_fini=0x4000aea0 <_dl_fini>,
stack_end=0xb66c)
at ../sysdeps/generic/libc-start.c:92
(gdb)
[2003-07-08 17:13:14] hos dot endre at axelero dot hu
Description:
Tokenizer function (token_get_all) crashes and Apache is going down
immediately, when a newly introduced __METHOD__ constant have found in
the script. Workx good with __FUNCTION__ constant, now I'm gonna use
__FUNCTION__ in my script, but might be problem one day for others...
I guess the sample code wont crash before PHP5, because if I write
anything else instead of __METHOD__, parser assumes that it's ok!
Compiler handles this constant, so the scripts works well with
__METHOD__, but should be untokenizable for documentation generators.
Now I tried syntax highlighting: same result, as I expected.
By the way: in the sample code I use __METHOD__ out of a method,
originally the problem came up in a method's body.
Reproduce code:
---
// I hope you like this - the shortest crasher formula:
highlight_string('http://bugs.php.net/?id=24550&edit=1
#24550 [Opn]: tokenizing & syntax highlighting crashes
ID: 24550
Updated by: [EMAIL PROTECTED]
Reported By: hos dot endre at axelero dot hu
Status: Open
Bug Type: Zend Engine 2 problem
Operating System: Windows XP
PHP Version: CVS HEAD
New Comment:
Found it.
Index: ext/tokenizer/tokenizer.c
===
RCS file: /repository/php-src/ext/tokenizer/tokenizer.c,v
retrieving revision 1.28
diff -u -r1.28 tokenizer.c
--- ext/tokenizer/tokenizer.c 2 Mar 2004 17:51:46 - 1.28
+++ ext/tokenizer/tokenizer.c 8 Mar 2004 05:03:31 -
@@ -257,6 +257,7 @@
REGISTER_LONG_CONSTANT("T_ARRAY", T_ARRAY, CONST_CS |
CONST_PERSISTENT);
REGISTER_LONG_CONSTANT("T_CLASS_C", T_CLASS_C, CONST_CS |
CONST_PERSISTENT);
REGISTER_LONG_CONSTANT("T_FUNC_C", T_FUNC_C, CONST_CS |
CONST_PERSISTENT);
+ REGISTER_LONG_CONSTANT("T_METHOD_C", T_FUNC_C, CONST_CS |
CONST_PERSISTENT);
REGISTER_LONG_CONSTANT("T_LINE", T_LINE, CONST_CS |
CONST_PERSISTENT);
REGISTER_LONG_CONSTANT("T_FILE", T_FILE, CONST_CS |
CONST_PERSISTENT);
REGISTER_LONG_CONSTANT("T_COMMENT", T_COMMENT, CONST_CS |
CONST_PERSISTENT);
@@ -470,6 +471,7 @@
case T_ARRAY: return "T_ARRAY";
case T_CLASS_C: return "T_CLASS_C";
case T_FUNC_C: return "T_FUNC_C";
+ case T_METHOD_C: return "T_METHOD_C";
case T_LINE: return "T_LINE";
case T_FILE: return "T_FILE";
case T_COMMENT: return "T_COMMENT";
Previous Comments:
[2004-03-07 23:52:25] [EMAIL PROTECTED]
token_get_all('function_name : NULL;
As near as I can tell, active_op_array doesn't exist. I suspect the
tokenizer does not properly prepare for parsing, but have no idea how
to investigate further. I need this one to be fixed for phpDocumentor
2.0 to work at all wiht __METHOD__ in source code.
Thanks,
Greg
[2003-07-27 07:25:52] [EMAIL PROTECTED]
This bug has been fixed in CVS.
In case this was a PHP problem, 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/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
[2003-07-09 06:47:16] [EMAIL PROTECTED]
[Switching to Thread 1024 (runnable)]
lex_scan (zendlval=0xb2b8) at
/usr/src/web/php/php5/Zend/zend_language_scanner.l:988
988 char *func_name = CG(active_op_array)->function_name;
(gdb) bt
#0 lex_scan (zendlval=0xb2b8) at
/usr/src/web/php/php5/Zend/zend_language_scanner.l:988
#1 0x813f070 in zend_highlight (syntax_highlighter_ini=0xb354) at
/usr/src/web/php/php5/Zend/zend_highlight.c:176
#2 0x81313db in highlight_string (str=0x40298ccc,
syntax_highlighter_ini=0xb354,
str_name=0x402992d4 "Command line code(1) : highlighted code")
at /usr/src/web/php/php5/Zend/zend_language_scanner.l:461
#3 0x80c8094 in zif_highlight_string (ht=1, return_value=0x402992b4,
this_ptr=0x0, return_value_used=0)
at /usr/src/web/php/php5/ext/standard/basic_functions.c:2251
#4 0x816b63d in zend_do_fcall_common_helper (execute_data=0xb43c,
op_array=0x4029905c)
at /usr/src/web/php/php5/Zend/zend_execute.c:2664
#5 0x816bbc2 in zend_do_fcall_handler (execute_data=0xb43c,
op_array=0x4029905c)
at /usr/src/web/php/php5/Zend/zend_execute.c:2793
#6 0x815bc54 in execute (op_array=0x4029905c) at
/usr/src/web/php/php5/Zend/zend_execute.c:1266
#7 0x813ea61 in zend_eval_string (str=0xb7d7
"highlight_string(', argc=3,
argv=0xb674, init=0x80696a0 <_init>,
fini=0x8175724 <_fini>, rtld_fini=0x4000aea0 <_dl_fini>,
stack_end=0xb66c)
at ../sysdeps/generic/libc-start.c:92
(gdb)
[2003-07-08 17:13:14] hos dot endre at axelero dot hu
Description:
Tokenizer function (token_get_all) crashes and Apache is going down
immediately, when a newly introduced __METHOD__ constant have found in
the script. Workx good with __FUNCTION__ constant, now I'm gonna use
__FUNCTION__ in my script, but might be problem one day for others...
I guess the sample code wont crash before PHP5, because if I write
anything else instead of __METHOD__, parser assumes that it's ok!
Compiler handles this constant, so the scripts works well with
__METHOD__, but should be untokenizable for documentation generators.
Now I tried syntax highlighting: same result, as
#26463 [Csd->Opn]: Incorrect results returned by token_get_all for heredoc
ID: 26463
Updated by: [EMAIL PROTECTED]
Reported By: andrey at midphase dot com
-Status: Closed
+Status: Open
Bug Type: Scripting Engine problem
Operating System: Windows XP
-PHP Version: 4.3.4
+PHP Version: PHP 5 CVS HEAD
Assigned To: iliaa
New Comment:
$a = token_get_all('');
var_dump($a);
foreach ($a as $token) {
@var_dump(token_name($token[0]));
}
generates
array(10) {
[0]=>
array(2) {
[0]=>
int(366)
[1]=>
string(6) "
array(2) {
[0]=>
int(335)
[1]=>
string(6) "return"
}
[2]=>
array(2) {
[0]=>
int(369)
[1]=>
string(1) " "
}
[3]=>
array(2) {
[0]=>
int(370)
[1]=>
string(8) "<<
array(2) {
[0]=>
int(307)
[1]=>
string(4) "test"
}
[5]=>
array(2) {
[0]=>
int(314)
[1]=>
string(1) " "
}
[6]=>
array(2) {
[0]=>
int(307)
[1]=>
string(2) "me"
}
[7]=>
array(2) {
[0]=>
int(314)
[1]=>
string(2) "
"
}
[8]=>
array(2) {
[0]=>
int(307)
[1]=>
string(3) "EOF"
}
[9]=>
array(2) {
[0]=>
int(314)
[1]=>
string(4) "; ?>"
}
}
string(10) "T_OPEN_TAG"
string(8) "T_RETURN"
string(12) "T_WHITESPACE"
string(15) "T_START_HEREDOC"
string(8) "T_STRING"
string(25) "T_ENCAPSED_AND_WHITESPACE"
string(8) "T_STRING"
string(25) "T_ENCAPSED_AND_WHITESPACE"
string(8) "T_STRING"
string(25) "T_ENCAPSED_AND_WHITESPACE"
This last token is a T_END_HEREDOC, T_WHITESPACE and T_CLOSE_TAG all
combined incorrectly into a T_ENCAPSED_AND_WHITESPACE. If any other
statements follow the T_END_HEREDOC, output is as expected.
Greg
Previous Comments:
[2003-11-29 14:04:12] [EMAIL PROTECTED]
This bug has been fixed in CVS.
In case this was a PHP problem, 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/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
[2003-11-29 10:10:59] andrey at midphase dot com
Sorry, actual content of test.php is
[2003-11-29 10:08:04] andrey at midphase dot com
Description:
When calling token_get_all with a string containing heredoc strings,
T_END_HEREDOC element contains two semicolons separated by newline and
is followed by semicolon character.
This does not happen if heredoc string is followed by concatenation
operatior
Reproduce code:
---
=
code.php
=
=
test.php
=
Expected result:
Array
(
[0] => Array
(
[0] => 354
[1] => Array
(
[0] => 357
[1] =>
)
[2] => Array
(
[0] => 307
[1] => $x
)
[3] => =
[4] => Array
(
[0] => 358
[1] => << Array
(
[0] => 312
[1] =>
)
[6] => Array
(
[0] => 305
[1] => jhdsjkfhjdsh
)
[7] => Array
(
[0] => 312
[1] =>
)
[8] => Array
(
[0] => 359
[1] => DD
)
[9] => .
[10] => Array
(
[0] => 313
[1] => ""
)
[11] => ;
[12] => Array
(
[0] => 357
[1] =>
)
[13] => Array
(
[0] => 307
[1] => $a
)
[14] => =
[15] => Array
(
[0] => 358
[1] => << Array
(
[0] => 312
[1] =>
)
[17] => Array
(
[0] => 305
[1] => jhdsjkfhjdsh
)
[18] => Array
(
[0] => 312
[1] =>
)
[19] => Array
(
[0] => 359
[1] => DD;
)
/*[20] => ; deleted */
[21] => Array
(
[0] => 357
[1] =>
)
[22] => Array
(
[0] => 314
[1] => echo
)
[23] => Array
(
[0] => 357
[1] =>
)
[24] => Array
(
[0] => 307
#29663 [Bgs]: php://stdin does not wait for input after first run
ID: 29663 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: CGI related Operating System: Win32 & Linux PHP Version: 5.0.1 New Comment: This is a major BC break with PHP 4, and breaks the PEAR installer's PEAR_Frontend_CLI::userDialog() function. I strongly suggest reconsidering the "bogus" mark Previous Comments: [2004-08-13 22:42:54] [EMAIL PROTECTED] Apparently this in intended behaviour for CLI scripts. [2004-08-13 21:40:44] [EMAIL PROTECTED] Using the STDIN constant works. Removing fclose() in the above example does not solve the problem. [2004-08-13 21:22:28] [EMAIL PROTECTED] Description: The code below works in PHP4, but not in PHP 5.0.1 After first being prompted for stdin input and clicking enter the rest of the loop finishes without waiting for user interaction Run the code below in CLI. Enter "foo"[ENTER] Reproduced in both Win32 and Linux Reproduce code: --- Expected result: Please enter something: foo string(3) "foo" Please enter something: Actual result: -- Please enter something: foo string(3) "foo" Please enter something: string(0) "" Please enter something: string(0) "" Please enter something: string(0) "" Please enter something: string(0) "" Please enter something: string(0) "" Please enter something: string(0) "" Please enter something: string(0) "" Please enter something: string(0) "" Please enter something: string(0) "" Please enter something: string(0) "" -- Edit this bug report at http://bugs.php.net/?id=29663&edit=1
#24910 [Bgs->Opn]: in function scope, $GLOBALS is not superglobal
ID: 24910 Updated by: [EMAIL PROTECTED] Reported By: greg at chiaraquartet dot net -Status: Bogus +Status: Open Bug Type: Arrays related Operating System: Windows XP PHP Version: 4.3.2 New Comment: This is not bogus. Did you try the code? The whole point is that in a function, $GLOBALS['GLOBALS'] !== $GLOBALS. It should be the same. In global scope, $GLOBALS['GLOBALS'] === $GLOBALS Greg Previous Comments: [2003-08-01 15:23:54] [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 $GLOBALS['GLOBALS'] is actually a reference to $GLOBALS if you want to access the globals just use $GLOBALS. [2003-08-01 14:47:52] greg at chiaraquartet dot net Description: the $GLOBALS variables contains indexes to every superglobal except 'GLOBALS' in function scope. In global scope, it contains the 'GLOBALS' index as a self-reference Reproduce code: --- Expected result: var_dump() of the $GLOBALS superglobal Actual result: -- Notice: Undefined index: GLOBALS in c:\web pages\chiara\a1.php on line 3 NULL -- Edit this bug report at http://bugs.php.net/?id=24910&edit=1
#24910 [Opn]: in function scope, $GLOBALS is not superglobal
ID: 24910
Updated by: [EMAIL PROTECTED]
Reported By: greg at chiaraquartet dot net
Status: Open
Bug Type: Arrays related
Operating System: Windows XP
PHP Version: 4.3.2
New Comment:
an interesting thing: the following code does work as expected.
Perhaps the index is not set unless $GLOBALS is accessed globally?
function not_super()
{
//var_dump($GLOBALS['GLOBALS']);
var_dump(isset($GLOBALS['GLOBALS']));
$a = array_keys($GLOBALS);
var_dump(isset($a['GLOBALS']));
}
not_super();
//var_dump(isset($GLOBALS['GLOBALS']));
$a = array_keys($GLOBALS);
//var_dump(isset($a['GLOBALS']));
Previous Comments:
[2003-08-01 15:32:34] [EMAIL PROTECTED]
This is not bogus. Did you try the code? The whole point is that in a
function, $GLOBALS['GLOBALS'] !== $GLOBALS. It should be the same.
In global scope, $GLOBALS['GLOBALS'] === $GLOBALS
Greg
[2003-08-01 15:23:54] [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
$GLOBALS['GLOBALS'] is actually a reference to $GLOBALS if you want to
access the globals just use $GLOBALS.
[2003-08-01 14:47:52] greg at chiaraquartet dot net
Description:
the $GLOBALS variables contains indexes to every superglobal except
'GLOBALS' in function scope. In global scope, it contains the
'GLOBALS' index as a self-reference
Reproduce code:
---
Expected result:
var_dump() of the $GLOBALS superglobal
Actual result:
--
Notice: Undefined index: GLOBALS in c:\web pages\chiara\a1.php on line
3
NULL
--
Edit this bug report at http://bugs.php.net/?id=24910&edit=1
#24910 [Bgs]: in function scope, $GLOBALS is not superglobal
ID: 24910
Updated by: [EMAIL PROTECTED]
Reported By: greg at chiaraquartet dot net
Status: Bogus
Bug Type: Arrays related
Operating System: Windows XP
PHP Version: 4.3.2
New Comment:
The reason this is a bug is this code deletes the $GLOBALS array, and
someone might do it by accident:
Someone just posted to php.general asking about this exact issue, which
is why I posted the bug. Last I checked, the definition of a bug is
unexpected behavior, and this qualifies. It's rare, but perhaps there
is something more critical hidden in the fact that this doesn't work?
Since you're insistent, I'll leave this as bogus, but I strongly
encourage you to reconsider
Note that this code works as expected:
Once $GLOBALS has been overwritten, it is irretrievable within function
scope. At the very least, a warning or notice should be thrown. This
is a bug. If it is not to be fixed, the documentation might use a
warning for dummies.
Greg
Previous Comments:
[2003-08-01 15:49:16] [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
First of all accessing $GLOBALS as $GLOBALS['GLOBALS'] is just plain
wrong, you should just use $GLOBALS. If you look @ var_dump($GLOBALS)
you'll see ["GLOBALS"] is infact a reference to itself, &array().
You could do something like
$GLOBALS['GLOBALS']['GLOBALS']['GLOBALS']['_ENV'] and it would work
because each globals array contains a reference to itself.
This reference is only avaliable inside the global (main()) scope,
which is why you cannot access it from inside the function.
[2003-08-01 15:38:43] [EMAIL PROTECTED]
an interesting thing: the following code does work as expected.
Perhaps the index is not set unless $GLOBALS is accessed globally?
function not_super()
{
//var_dump($GLOBALS['GLOBALS']);
var_dump(isset($GLOBALS['GLOBALS']));
$a = array_keys($GLOBALS);
var_dump(isset($a['GLOBALS']));
}
not_super();
//var_dump(isset($GLOBALS['GLOBALS']));
$a = array_keys($GLOBALS);
//var_dump(isset($a['GLOBALS']));
[2003-08-01 15:32:34] [EMAIL PROTECTED]
This is not bogus. Did you try the code? The whole point is that in a
function, $GLOBALS['GLOBALS'] !== $GLOBALS. It should be the same.
In global scope, $GLOBALS['GLOBALS'] === $GLOBALS
Greg
[2003-08-01 15:23:54] [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
$GLOBALS['GLOBALS'] is actually a reference to $GLOBALS if you want to
access the globals just use $GLOBALS.
[2003-08-01 14:47:52] greg at chiaraquartet dot net
Description:
the $GLOBALS variables contains indexes to every superglobal except
'GLOBALS' in function scope. In global scope, it contains the
'GLOBALS' index as a self-reference
Reproduce code:
---
Expected result:
var_dump() of the $GLOBALS superglobal
Actual result:
--
Notice: Undefined index: GLOBALS in c:\web pages\chiara\a1.php on line
3
NULL
--
Edit this bug report at http://bugs.php.net/?id=24910&edit=1
#25428 [Csd->Opn]: xmlrpc_server_call_method() causes segfault
ID: 25428
Updated by: [EMAIL PROTECTED]
Reported By: mfladischer at gmx dot net
-Status: Closed
+Status: Open
Bug Type: XMLRPC-EPI related
-Operating System: RedHat 9
+Operating System: Windows XP
-PHP Version: 5CVS-2003-09-08 (dev)
+PHP Version: 5.0.0
New Comment:
In windows, if raw post data is populated with an encoded
system.listMethods request (or any other registered method), this code
crashes on the xmlrpc_server_call_method()
Previous Comments:
[2003-10-14 20:16:24] [EMAIL PROTECTED]
This bug has been fixed in CVS.
In case this was a PHP problem, 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/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
Patch applied.
[2003-10-14 20:09:57] web-php-bugs at sklar dot com
This diff against v1.35 of ext/xmlrpc/xmlrpc-epi.php.c fixes the
problem.
diff -r1.35 xmlrpc-epi-php.c
1033c1033,1037
< set_output_options(&out, *output_opts);
---
> if (argc == 3) {
> set_output_options(&out, NULL);
> } else {
> set_output_options(&out, *output_opts);
> }
[2003-09-08 03:38:40] mfladischer at gmx dot net
Description:
When i'm trying to run a XML-RPC server (using the xml-rpc-extension)
with PHP5 i get a segfault.
Reproduce code:
---
Expected result:
system.listMethods
system.methodHelp
system.methodSignature
system.describeMethods
system.multiCall
system.getCapabilities
Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 19945)]
0x0822d92f in zif_xmlrpc_server_call_method (ht=3,
return_value=0x408ef0ac, this_ptr=0x0, return_value_used=1)
at /linux/devel/php5/ext/xmlrpc/xmlrpc-epi-php.c:1033
1033set_output_options(&out, *output_opts);
(gdb) bt
#0 0x0822d92f in zif_xmlrpc_server_call_method (ht=3,
return_value=0x408ef0ac, this_ptr=0x0, return_value_used=1)
at /linux/devel/php5/ext/xmlrpc/xmlrpc-epi-php.c:1033
#1 0x082a2583 in zend_do_fcall_common_helper (execute_data=0xbfffd180,
op_array=0x408ee410) at /linux/devel/php5/Zend/zend_execute.c:2541
#2 0x082a2d25 in zend_do_fcall_handler (execute_data=0xbfffd180,
op_array=0x408ee410) at /linux/devel/php5/Zend/zend_execute.c:2687
#3 0x0829e834 in execute (op_array=0x408ee410) at
/linux/devel/php5/Zend/zend_execute.c:1267
#4 0x0827f0f7 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /linux/devel/php5/Zend/zend.c:1018
#5 0x0823f15c in php_execute_script (primary_file=0xb580) at
/linux/devel/php5/main/main.c:1625
#6 0x082acea7 in main (argc=2, argv=0xb614) at
/linux/devel/php5/sapi/cli/php_cli.c:910
#7 0x40767bf7 in __libc_start_main () from /lib/i686/libc.so.6
--
Edit this bug report at http://bugs.php.net/?id=25428&edit=1
#48141 [Fbk->Asn]: memory leak in zend_execute.c and zend_operators.c
ID: 48141
Updated by: cel...@php.net
Reported By: greg at chiaraquartet dot net
-Status: Feedback
+Status: Assigned
Bug Type: Scripting Engine problem
Operating System: ubuntu linux
PHP Version: 5.3CVS-2009-05-04 (CVS)
Assigned To: dmitry
New Comment:
u...@ubuntu8041:~/workspace/php5$ cat config.nice
#! /bin/sh
#
# Created by configure
'./configure' \
'--enable-debug' \
'--with-zlib' \
'--with-bz2=shared' \
'--enable-cgi' \
"$@"
u...@ubuntu8041:~/workspace/php5$ uname -a
Linux ubuntu8041 2.6.24-23-generic #1 SMP Wed Apr 1 21:47:28 UTC 2009
i686 GNU/Linux
u...@ubuntu8041:~/workspace/php5$ cat CVS/Tag
TPHP_5_3
u...@ubuntu8041:~/workspace/php5$
Previous Comments:
[2009-05-04 10:16:39] dmi...@php.net
I'm not able to reproduce it with CVS PHP_5_3.
[2009-05-04 08:03:17] tony2...@php.net
Dmitry, could you look into it?
[2009-05-04 04:24:12] greg at chiaraquartet dot net
Description:
When running a simple file that only instantiates objects using
autoload, there is a memory leak.
The leak appears to be caused by some combination of string
concatenation and exception throwing. The line that causes the leak is
in Pyrus/src/Pyrus/Registry/Sqlite3.php in the constructor:
if ($path && $path != ':memory:') {
if (dirname($path) . DIRECTORY_SEPARATOR . '.pear2registry'
!= $path) {
$path = $path . DIRECTORY_SEPARATOR .
'.pear2registry';
}
}
The line "$path = $path . DIRECTORY_SEPARATOR . '.pear2registry';"
leaks the value "/usr/local/lib/php/.pear2registry" on my machine, and
the zval allocated for $path.
Reproduce code:
---
http://svn.pear.php.net/PEAR2/all
function __autoload($class)
{
if ($class == 'PEAR2_Exception') {
include __DIR__ . '/Exception/src/Exception.php';
return;
}
$class = str_replace('PEAR2_', '', $class);
$class = str_replace('_', '/', $class);
include __DIR__ . '/Pyrus/src/' . $class . '.php';
}
$a = PEAR2_Pyrus_Config::current();
Expected result:
no output
Actual result:
--
u...@ubuntu8041:~/workspace/all/Pyrus/tests/AtomicFileTransaction/rmrf$
php -n test.phpt
[Sun May 3 22:58:31 2009] Script: 'test.phpt'
/home/user/workspace/php5/Zend/zend_execute.c(723) : Freeing
0xB7B52AE4 (20 bytes), script=test.phpt
[Sun May 3 22:58:31 2009] Script: 'test.phpt'
/home/user/workspace/php5/Zend/zend_operators.c(1231) : Freeing
0x088CE1EC (34 bytes), script=test.phpt
=== Total 2 memory leaks detected ===
--
Edit this bug report at http://bugs.php.net/?id=48141&edit=1
#48141 [Asn]: memory leak in zend_execute.c and zend_operators.c
ID: 48141
Updated by: cel...@php.net
Reported By: greg at chiaraquartet dot net
Status: Assigned
Bug Type: Scripting Engine problem
Operating System: ubuntu linux
PHP Version: 5.3CVS-2009-05-04 (CVS)
Assigned To: dmitry
New Comment:
I'm using Ubuntu in a VMWare Fusion image in a MacBook Pro, in case
that is helpful
Previous Comments:
[2009-05-04 17:21:17] cel...@php.net
u...@ubuntu8041:~/workspace/php5$ cat config.nice
#! /bin/sh
#
# Created by configure
'./configure' \
'--enable-debug' \
'--with-zlib' \
'--with-bz2=shared' \
'--enable-cgi' \
"$@"
u...@ubuntu8041:~/workspace/php5$ uname -a
Linux ubuntu8041 2.6.24-23-generic #1 SMP Wed Apr 1 21:47:28 UTC 2009
i686 GNU/Linux
u...@ubuntu8041:~/workspace/php5$ cat CVS/Tag
TPHP_5_3
u...@ubuntu8041:~/workspace/php5$
[2009-05-04 10:16:39] dmi...@php.net
I'm not able to reproduce it with CVS PHP_5_3.
[2009-05-04 08:03:17] tony2...@php.net
Dmitry, could you look into it?
[2009-05-04 04:24:12] greg at chiaraquartet dot net
Description:
When running a simple file that only instantiates objects using
autoload, there is a memory leak.
The leak appears to be caused by some combination of string
concatenation and exception throwing. The line that causes the leak is
in Pyrus/src/Pyrus/Registry/Sqlite3.php in the constructor:
if ($path && $path != ':memory:') {
if (dirname($path) . DIRECTORY_SEPARATOR . '.pear2registry'
!= $path) {
$path = $path . DIRECTORY_SEPARATOR .
'.pear2registry';
}
}
The line "$path = $path . DIRECTORY_SEPARATOR . '.pear2registry';"
leaks the value "/usr/local/lib/php/.pear2registry" on my machine, and
the zval allocated for $path.
Reproduce code:
---
http://svn.pear.php.net/PEAR2/all
function __autoload($class)
{
if ($class == 'PEAR2_Exception') {
include __DIR__ . '/Exception/src/Exception.php';
return;
}
$class = str_replace('PEAR2_', '', $class);
$class = str_replace('_', '/', $class);
include __DIR__ . '/Pyrus/src/' . $class . '.php';
}
$a = PEAR2_Pyrus_Config::current();
Expected result:
no output
Actual result:
--
u...@ubuntu8041:~/workspace/all/Pyrus/tests/AtomicFileTransaction/rmrf$
php -n test.phpt
[Sun May 3 22:58:31 2009] Script: 'test.phpt'
/home/user/workspace/php5/Zend/zend_execute.c(723) : Freeing
0xB7B52AE4 (20 bytes), script=test.phpt
[Sun May 3 22:58:31 2009] Script: 'test.phpt'
/home/user/workspace/php5/Zend/zend_operators.c(1231) : Freeing
0x088CE1EC (34 bytes), script=test.phpt
=== Total 2 memory leaks detected ===
--
Edit this bug report at http://bugs.php.net/?id=48141&edit=1
#48257 [Opn->Asn]: PharData throws exception with non-phar tar
ID: 48257
Updated by: cel...@php.net
Reported By: cel...@php.net
-Status: Open
+Status: Assigned
Bug Type: PHAR related
Operating System: n/a
PHP Version: 5.3CVS-2009-05-13 (CVS)
-Assigned To:
+Assigned To: cellog
Previous Comments:
[2009-05-13 06:24:06] cel...@php.net
Description:
pear download Net_URL
php -r 'new PharData("Net_URL-1.0.15.tgz");'
results in exception, tar does not have signature.
--
Edit this bug report at http://bugs.php.net/?id=48257&edit=1
#48257 [Asn->Tbd]: PharData throws exception with non-phar tar
ID: 48257
Updated by: cel...@php.net
Reported By: cel...@php.net
-Status: Assigned
+Status: To be documented
Bug Type: PHAR related
Operating System: n/a
PHP Version: 5.3CVS-2009-05-13 (CVS)
Assigned To: cellog
New Comment:
fixed in HEAD, 5.3, and pecl/phar
documentation needs to state that phar.require_hash does not affect
plain tar files, thus:
will not fail if sometar.tar does not have a signature.
will fail if sometar.phar.tar does not contain a signature.
Previous Comments:
[2009-05-13 06:24:06] cel...@php.net
Description:
pear download Net_URL
php -r 'new PharData("Net_URL-1.0.15.tgz");'
results in exception, tar does not have signature.
--
Edit this bug report at http://bugs.php.net/?id=48257&edit=1
#48541 [Opn->Csd]: spl_autoload_register only registers first closure, then leaks the others
ID: 48541 Updated by: cel...@php.net Reported By: cel...@php.net -Status: Open +Status: Closed Bug Type:SPL related PHP Version: 5.3CVS-2009-06-13 (CVS) -Assigned To: +Assigned To: cellog New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. fixed in HEAD and PHP_5_3 Previous Comments: [2009-06-13 06:09:09] cel...@php.net Description: The test script below does not leak, but if $a were to successfully load class "foo" (i.e. move the eval() in $b() into $a) it leaks memory in zend_execute.c on line 723, which is the portion called when the closure is assigned to $b. This is caused by 2 separate bugs. 1) php_spl.c line 501 increases the refcount of the closure zval 2) php_spl.c line 511 checks to see if the function name has already been registered, but treats all closures as if they were "closure::__invoke" instead of using some unique aspect of each closure. This then jumps to the end of spl_autoload_register without decreasing the refcount, and boom, we have a memory leak. I don't know anything about the closures implementation, so someone who knows a better way to get a unique function name for a closure needs to fix this, both the refcount and the only-one-closure-allowed issues. Also, the memory leak is triggered by an important feature of Pyrus, and yes, we are registering multiple closures as autoload callbacks to implement a dynamic plugin system. It works great except for these two bugs. Reproduce code: --- http://bugs.php.net/?id=48541&edit=1
#48508 [Asn]: Segfault with "include 'file.phar.bz2'
ID: 48508 Updated by: cel...@php.net Reported By: webmaster at ajeux dot com Status: Assigned Bug Type: PHAR related Operating System: Linux 2.6.28 PHP Version: 5.3CVS-2009-06-09 (snap) Assigned To: cellog New Comment: thanks for the heads up, I'll take a look Previous Comments: [2009-06-09 14:22:49] webmaster at ajeux dot com Description: Trying to include a specific .phar leads to a segfault under Linux. The .phar is a bz2 archive, and very small (just one file inside). Source of the file can be found here : http://uploadfile.org/download.php?id=EqxNUSSdIgcpKKCgrkgG Bug seems to happen with any .phar.bz2 file. Reproduce code: --- http://bugs.php.net/?id=48508&edit=1
#48508 [Asn->Fbk]: Segfault with "include 'file.phar.bz2'
ID: 48508 Updated by: cel...@php.net Reported By: webmaster at ajeux dot com -Status: Assigned +Status: Feedback Bug Type: PHAR related Operating System: Linux 2.6.28 PHP Version: 5.3CVS-2009-06-09 (snap) Assigned To: cellog 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. I can't reproduce this, and the download link has expired. Can you also please say from which directory you are running the script? Previous Comments: [2009-06-18 17:55:36] cel...@php.net thanks for the heads up, I'll take a look [2009-06-09 14:22:49] webmaster at ajeux dot com Description: Trying to include a specific .phar leads to a segfault under Linux. The .phar is a bz2 archive, and very small (just one file inside). Source of the file can be found here : http://uploadfile.org/download.php?id=EqxNUSSdIgcpKKCgrkgG Bug seems to happen with any .phar.bz2 file. Reproduce code: --- http://bugs.php.net/?id=48508&edit=1
#48594 [Asn->Bgs]: pear not found
ID: 48594 Updated by: cel...@php.net Reported By: dmda at yandex dot ru -Status: Assigned +Status: Bogus Bug Type: Compile Failure Operating System: NetBSD 3.1 PHP Version: 5.3.0RC3 Assigned To: cellog New Comment: "Build complete" <-- there's no compile failure. There is also no error. phar.phar still exists and works. If you have PEAR already installed, and have installed the PHP_Archive package, phar.phar will also work in the absence of the phar extension, but this is an extra feature. No bug here. Previous Comments: [2009-06-20 13:57:08] paj...@php.net Can you take a look please? [2009-06-18 08:13:45] dmda at yandex dot ru Description: at the end of "make" process, the following error apeears in the output: Generating phar.php Generating phar.phar pear: not found ^^^ Pear package PHP_Archive or Archive.php class file not found. ^ clicommand.inc directorytreeiterator.inc directorygraphiterator.inc invertedregexiterator.inc pharcommand.inc phar.inc Build complete. Don't forget to run 'make test'. -- Edit this bug report at http://bugs.php.net/?id=48594&edit=1
#48508 [Asn->Fbk]: Segfault with "include 'file.phar.bz2'
ID: 48508
Updated by: cel...@php.net
Reported By: webmaster at ajeux dot com
-Status: Assigned
+Status: Feedback
Bug Type: PHAR related
Operating System: Linux 2.6.28
PHP Version: 5.3CVS-2009-06-09 (snap)
Assigned To: cellog
New Comment:
two problems:
1) this file is not bzipped, in fact it is not compressed at all
2) this file is not a phar archive, it is a plain tar archive
and the segfault can't be reproduced even when I bzip the resulting
archive, so I suspect your system is borked.
If you want to provide a bzipped phar archive that actually reproduces
the segfault, that would be fine.
Better yet, please provide a script similar to the following:
setStub(file_get_contents('cli.php'));
$a->compress(PHAR::BZ2);
?>
that creates an actual phar archive that is broken.
Previous Comments:
[2009-06-18 18:54:14] webmaster at ajeux dot com
File can be found here : http://www.ajeux.fr/cli.bz2
It contains a single file cli.php
Download this file and launch this:
Now that I'm more familiar with Phar, I'm not sure this is phar
related. I'm just including something that is absolutely not a php
readable file, don't I ?
Same SEGFAULT (ie same line/file) when including a bz2 archive that
contains a file containing the string 'iiiaaaoouu'; (yes, this is not a
php syntax, I can see that ;) ).
What do you think ?
[2009-06-18 18:08:57] cel...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
I can't reproduce this, and the download link has expired.
Can you also please say from which directory you are running the
script?
[2009-06-18 17:55:36] cel...@php.net
thanks for the heads up, I'll take a look
[2009-06-09 14:22:49] webmaster at ajeux dot com
Description:
Trying to include a specific .phar leads to a segfault under Linux.
The .phar is a bz2 archive, and very small (just one file inside).
Source of the file can be found here :
http://uploadfile.org/download.php?id=EqxNUSSdIgcpKKCgrkgG
Bug seems to happen with any .phar.bz2 file.
Reproduce code:
---
http://bugs.php.net/?id=48508&edit=1
#48681 [Opn->Ana]: openssl signature verification for tar archives broken
ID: 48681
Updated by: cel...@php.net
Reported By: cel...@php.net
-Status: Open
+Status: Analyzed
Bug Type:PHAR related
PHP Version: 5.3CVS-2009-06-24 (CVS)
-Assigned To:
+Assigned To: cellog
Previous Comments:
[2009-06-24 22:18:15] cel...@php.net
Description:
openssl signature verification is broken for tar archives, and will be
broken in PHP 5.3.0. This patch can be used for those who can't wait
until PHP 5.3.1.
Alternately, HEAD of php-src/ext/phar can be used, or pecl/phar, as
they are synchronized with php5/ext/phar
Reproduce code:
---
Index: ext/phar/tar.c
===
RCS file: /repository/php-src/ext/phar/tar.c,v
retrieving revision 1.55.2.29
diff -u -r1.55.2.29 tar.c
--- ext/phar/tar.c 4 Jun 2009 19:59:09 - 1.55.2.29
+++ ext/phar/tar.c 24 Jun 2009 22:14:08 -
@@ -255,6 +255,8 @@
phar_tar_number(hdr->size, sizeof(hdr->size));
if (((!old && hdr->prefix[0] == 0) || old) && strlen(hdr->name)
==
sizeof(".phar/signature.bin")-1 && !strncmp(hdr->name,
".phar/signature.bin", sizeof(".phar/signature.bin")-1)) {
+ off_t curloc;
+
if (size > 511) {
if (error) {
spprintf(error, 4096, "phar error:
tar-based phar \"%s\" has
signature that is larger than 511 bytes, cannot process", fname);
@@ -264,6 +266,7 @@
phar_destroy_phar_data(myphar TSRMLS_CC);
return FAILURE;
}
+ curloc = php_stream_tell(fp);
read = php_stream_read(fp, buf, size);
if (read != size) {
if (error) {
@@ -280,7 +283,7 @@
#else
# define PHAR_GET_32(buffer) (php_uint32) *(buffer)
#endif
- if (FAILURE == phar_verify_signature(fp,
php_stream_tell(fp) - size
- 512, PHAR_GET_32(buf), buf + 8, PHAR_GET_32(buf + 4), fname,
&myphar->signature, &myphar->sig_len, error TSRMLS_CC)) {
+ if (FAILURE == phar_verify_signature(fp,
php_stream_tell(fp) - size
- 512, PHAR_GET_32(buf), buf + 8, size - 8, fname, &myphar->signature,
&myphar->sig_len, error TSRMLS_CC)) {
if (error) {
char *save = *error;
spprintf(error, 4096, "phar error:
tar-based phar \"%s\"
signature cannot be verified: %s", fname, save);
@@ -288,11 +291,11 @@
}
goto bail;
}
+ php_stream_seek(fp, curloc + 512, SEEK_SET);
/* signature checked out, let's ensure this is the last
file in the
phar */
- size = ((size+511)&~511) + 512;
if (((hdr->typeflag == '\0') || (hdr->typeflag ==
TAR_FILE)) &&
size > 0) {
/* this is not good enough - seek succeeds even
on truncated tars
*/
- php_stream_seek(fp, size, SEEK_CUR);
+ php_stream_seek(fp, 512, SEEK_CUR);
if ((uint)php_stream_tell(fp) > totalsize) {
if (error) {
spprintf(error, 4096, "phar
error: \"%s\" is a corrupted tar
file (truncated)", fname);
--
Edit this bug report at http://bugs.php.net/?id=48681&edit=1
#48681 [Ana->Csd]: openssl signature verification for tar archives broken
ID: 48681
Updated by: cel...@php.net
Reported By: cel...@php.net
-Status: Analyzed
+Status: Closed
Bug Type:PHAR related
PHP Version: 5.3CVS-2009-06-24 (CVS)
Assigned To: cellog
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
fixed in 5.3, 6.0, pecl
Previous Comments:
[2009-06-24 22:18:15] cel...@php.net
Description:
openssl signature verification is broken for tar archives, and will be
broken in PHP 5.3.0. This patch can be used for those who can't wait
until PHP 5.3.1.
Alternately, HEAD of php-src/ext/phar can be used, or pecl/phar, as
they are synchronized with php5/ext/phar
Reproduce code:
---
Index: ext/phar/tar.c
===
RCS file: /repository/php-src/ext/phar/tar.c,v
retrieving revision 1.55.2.29
diff -u -r1.55.2.29 tar.c
--- ext/phar/tar.c 4 Jun 2009 19:59:09 - 1.55.2.29
+++ ext/phar/tar.c 24 Jun 2009 22:14:08 -
@@ -255,6 +255,8 @@
phar_tar_number(hdr->size, sizeof(hdr->size));
if (((!old && hdr->prefix[0] == 0) || old) && strlen(hdr->name)
==
sizeof(".phar/signature.bin")-1 && !strncmp(hdr->name,
".phar/signature.bin", sizeof(".phar/signature.bin")-1)) {
+ off_t curloc;
+
if (size > 511) {
if (error) {
spprintf(error, 4096, "phar error:
tar-based phar \"%s\" has
signature that is larger than 511 bytes, cannot process", fname);
@@ -264,6 +266,7 @@
phar_destroy_phar_data(myphar TSRMLS_CC);
return FAILURE;
}
+ curloc = php_stream_tell(fp);
read = php_stream_read(fp, buf, size);
if (read != size) {
if (error) {
@@ -280,7 +283,7 @@
#else
# define PHAR_GET_32(buffer) (php_uint32) *(buffer)
#endif
- if (FAILURE == phar_verify_signature(fp,
php_stream_tell(fp) - size
- 512, PHAR_GET_32(buf), buf + 8, PHAR_GET_32(buf + 4), fname,
&myphar->signature, &myphar->sig_len, error TSRMLS_CC)) {
+ if (FAILURE == phar_verify_signature(fp,
php_stream_tell(fp) - size
- 512, PHAR_GET_32(buf), buf + 8, size - 8, fname, &myphar->signature,
&myphar->sig_len, error TSRMLS_CC)) {
if (error) {
char *save = *error;
spprintf(error, 4096, "phar error:
tar-based phar \"%s\"
signature cannot be verified: %s", fname, save);
@@ -288,11 +291,11 @@
}
goto bail;
}
+ php_stream_seek(fp, curloc + 512, SEEK_SET);
/* signature checked out, let's ensure this is the last
file in the
phar */
- size = ((size+511)&~511) + 512;
if (((hdr->typeflag == '\0') || (hdr->typeflag ==
TAR_FILE)) &&
size > 0) {
/* this is not good enough - seek succeeds even
on truncated tars
*/
- php_stream_seek(fp, size, SEEK_CUR);
+ php_stream_seek(fp, 512, SEEK_CUR);
if ((uint)php_stream_tell(fp) > totalsize) {
if (error) {
spprintf(error, 4096, "phar
error: \"%s\" is a corrupted tar
file (truncated)", fname);
--
Edit this bug report at http://bugs.php.net/?id=48681&edit=1
#48791 [Opn->Fbk]: open office files always reported as corrupted
ID: 48791
Updated by: cel...@php.net
Reported By: RalfBecker at outdoor-training dot de
-Status: Open
+Status: Feedback
Bug Type: PHAR related
Operating System: CentOS5.3
PHP Version: 5.3.0
New Comment:
please provide a link to an actual odt file that fails which I can use
in a test case to reproduce the problem (no GPL things in it please)
Previous Comments:
[2009-07-03 18:02:13] paj...@php.net
oops, no :)
[2009-07-03 18:02:00] paj...@php.net
duplicate #48763
[2009-07-03 17:51:04] RalfBecker at outdoor-training dot de
Description:
If I try to read content.xml of an odt file (just a few lines, tried
several files, created with different odt version on different
plattforms), it always fails with error message the zip file is
corrupted. Open Office itself, unzip or kde's ark can read it without
problem. So I think the problem is related the zip implementation in
phar.
I get the same result with php5.2.9 under openSUSE11.0.
Reading the directory with:
php -r "print_r(scandir('phar://test.odt/'));"
shows the files and gives no error or warning.
Reproduce code:
---
php -r "echo file_get_contents('phar://test.odt/content.xml');"
Expected result:
xml of odt content
Actual result:
--
PHP Warning: file_get_contents(phar://test.odt/content.xml): failed to
open stream: phar error: internal corruption of zip-based phar
"/root/test.odt" (local header of file "content.xml" does not match
central directory) in Command line code on line 1
--
Edit this bug report at http://bugs.php.net/?id=48791&edit=1
#48800 [Opn->Bgs]: autoload does not strip leading T_NS_SEPARATOR
ID: 48800 Updated by: cel...@php.net Reported By: greg at chiaraquartet dot net -Status: Open +Status: Bogus Bug Type:Scripting Engine problem PHP Version: 5.3.0 Assigned To: dmitry New Comment: several problems between operator and keyboard Previous Comments: [2009-07-05 05:18:34] greg at chiaraquartet dot net Description: If attempts to instantiate \class\name and class\name are made, autoload is called twice. Reproduce code: --- http://bugs.php.net/?id=48800&edit=1
#49018 [Opn->Asn]: tar stores long filenames with prefix/name reversed
ID: 49018 Updated by: cel...@php.net Reported By: cel...@php.net -Status: Open +Status: Assigned Bug Type:PHAR related PHP Version: 5.3.0 -Assigned To: +Assigned To: cellog Previous Comments: [2009-07-22 15:23:20] cel...@php.net Description: for filenames longer than 100 characters, phar stores the prefix in the name section, and the name in the prefix section -- Edit this bug report at http://bugs.php.net/?id=49018&edit=1
#49018 [Asn->Csd]: phar tar stores long filenames with prefix/name reversed
ID: 49018 Updated by: cel...@php.net Reported By: cel...@php.net -Status: Assigned +Status: Closed Bug Type:PHAR related PHP Version: 5.3.0 Assigned To: cellog New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2009-07-22 15:23:20] cel...@php.net Description: for filenames longer than 100 characters, phar stores the prefix in the name section, and the name in the prefix section -- Edit this bug report at http://bugs.php.net/?id=49018&edit=1
#49020 [Opn->Asn]: phar misinterprets ustar long filename standard
ID: 49020 Updated by: cel...@php.net Reported By: cel...@php.net -Status: Open +Status: Assigned Bug Type:PHAR related PHP Version: 5.3.0 -Assigned To: +Assigned To: cellog Previous Comments: [2009-07-22 19:09:27] cel...@php.net Description: the phar implementation of long filenames splits on the 100th character no matter what, but the ustar standard specifies that the split should be on a directory boundary -- Edit this bug report at http://bugs.php.net/?id=49020&edit=1
#49020 [Asn->Csd]: phar misinterprets ustar long filename standard
ID: 49020 Updated by: cel...@php.net Reported By: cel...@php.net -Status: Assigned +Status: Closed Bug Type:PHAR related PHP Version: 5.3.0 Assigned To: cellog New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2009-07-22 19:09:27] cel...@php.net Description: the phar implementation of long filenames splits on the 100th character no matter what, but the ustar standard specifies that the split should be on a directory boundary -- Edit this bug report at http://bugs.php.net/?id=49020&edit=1
#49021 [Opn->Csd]: phar tar signature algorithm reports as Unknown (0) in getSignature() call
ID: 49021 Updated by: cel...@php.net Reported By: cel...@php.net -Status: Open +Status: Closed Bug Type:PHAR related PHP Version: 5.3.0 -Assigned To: +Assigned To: cellog New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2009-07-22 20:17:04] cel...@php.net Description: a call to getSignature on a Phar or PharData object based on a tar archive always reports Unknown (0) as the signature type -- Edit this bug report at http://bugs.php.net/?id=49021&edit=1
#48740 [Opn->Asn]: PHAR install fails when INSTALL_ROOT is not the final install location
ID: 48740 Updated by: cel...@php.net Reported By: james dot cohen at digitalwindow dot com -Status: Open +Status: Assigned Bug Type: PHAR related Operating System: CentOS release 5.3 PHP Version: 5.3.0 -Assigned To: +Assigned To: cellog New Comment: hi, that actually should be: --- php-5.3.0/ext/phar/Makefile.frag2009-06-30 15:01:38.0 +0100 +++ php-5.3.0/ext/phar/Makefile.frag.symlink2009-06-30 15:05:27.0 +0100 @@ -43,4 +43,4 @@ $(builddir)/phar.phar: $(builddir)/phar. install-pharcmd: pharcmd -...@$(mkinstalldirs) $(INSTALL_ROOT)$(bindir) $(INSTALL) $(builddir)/phar.phar $(INSTALL_ROOT)$(bindir) - $(LN_S) -f $(INSTALL_ROOT)$(bindir)/phar.phar $(INSTALL_ROOT)$(bindir)/phar + $(LN_S) -f $(bindir)/phar.phar $(INSTALL_ROOT)$(bindir)/phar Otherwise the symbolic link will be to any file phar.phar in the path and not specifically to our phar.phar Previous Comments: [2009-06-30 14:16:48] james dot cohen at digitalwindow dot com --- php-5.3.0/ext/phar/Makefile.frag2009-06-30 15:01:38.0 +0100 +++ php-5.3.0/ext/phar/Makefile.frag.symlink2009-06-30 15:05:27.0 +0100 @@ -43,4 +43,4 @@ $(builddir)/phar.phar: $(builddir)/phar. install-pharcmd: pharcmd -...@$(mkinstalldirs) $(INSTALL_ROOT)$(bindir) $(INSTALL) $(builddir)/phar.phar $(INSTALL_ROOT)$(bindir) - $(LN_S) -f $(INSTALL_ROOT)$(bindir)/phar.phar $(INSTALL_ROOT)$(bindir)/phar + $(LN_S) -f phar.phar $(INSTALL_ROOT)$(bindir)/phar [2009-06-30 14:00:24] james dot cohen at digitalwindow dot com Description: When you run `make install` to install PHAR to a location other than the final build location an error occurs. Building an RPM within a build root is a good example of when this might occur. The bin/phar symbolic link point will point to the build root rather than the install root. php-5.3.0/ext/phar/Makefile.frag Line 46 reads: $(LN_S) -f $(INSTALL_ROOT)$(bindir)/phar.phar $(INSTALL_ROOT)$(bindir)/phar To correct the bug the line should be modified to the following $(LN_S) -f phar.phar $(INSTALL_ROOT)$(bindir)/phar This should be safe as both are in the same directory ($(INSTALL_ROOT)$(bindir)/phar) -- Edit this bug report at http://bugs.php.net/?id=48740&edit=1
#48740 [Asn->Fbk]: PHAR install fails when INSTALL_ROOT is not the final install location
ID: 48740 Updated by: cel...@php.net Reported By: james dot cohen at digitalwindow dot com -Status: Assigned +Status: Feedback Bug Type: PHAR related Operating System: CentOS release 5.3 PHP Version: 5.3.0 Assigned To: cellog New Comment: Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Previous Comments: [2009-07-23 15:33:47] cel...@php.net hi, that actually should be: --- php-5.3.0/ext/phar/Makefile.frag2009-06-30 15:01:38.0 +0100 +++ php-5.3.0/ext/phar/Makefile.frag.symlink2009-06-30 15:05:27.0 +0100 @@ -43,4 +43,4 @@ $(builddir)/phar.phar: $(builddir)/phar. install-pharcmd: pharcmd -...@$(mkinstalldirs) $(INSTALL_ROOT)$(bindir) $(INSTALL) $(builddir)/phar.phar $(INSTALL_ROOT)$(bindir) - $(LN_S) -f $(INSTALL_ROOT)$(bindir)/phar.phar $(INSTALL_ROOT)$(bindir)/phar + $(LN_S) -f $(bindir)/phar.phar $(INSTALL_ROOT)$(bindir)/phar Otherwise the symbolic link will be to any file phar.phar in the path and not specifically to our phar.phar [2009-06-30 14:16:48] james dot cohen at digitalwindow dot com --- php-5.3.0/ext/phar/Makefile.frag2009-06-30 15:01:38.0 +0100 +++ php-5.3.0/ext/phar/Makefile.frag.symlink2009-06-30 15:05:27.0 +0100 @@ -43,4 +43,4 @@ $(builddir)/phar.phar: $(builddir)/phar. install-pharcmd: pharcmd -...@$(mkinstalldirs) $(INSTALL_ROOT)$(bindir) $(INSTALL) $(builddir)/phar.phar $(INSTALL_ROOT)$(bindir) - $(LN_S) -f $(INSTALL_ROOT)$(bindir)/phar.phar $(INSTALL_ROOT)$(bindir)/phar + $(LN_S) -f phar.phar $(INSTALL_ROOT)$(bindir)/phar [2009-06-30 14:00:24] james dot cohen at digitalwindow dot com Description: When you run `make install` to install PHAR to a location other than the final build location an error occurs. Building an RPM within a build root is a good example of when this might occur. The bin/phar symbolic link point will point to the build root rather than the install root. php-5.3.0/ext/phar/Makefile.frag Line 46 reads: $(LN_S) -f $(INSTALL_ROOT)$(bindir)/phar.phar $(INSTALL_ROOT)$(bindir)/phar To correct the bug the line should be modified to the following $(LN_S) -f phar.phar $(INSTALL_ROOT)$(bindir)/phar This should be safe as both are in the same directory ($(INSTALL_ROOT)$(bindir)/phar) -- Edit this bug report at http://bugs.php.net/?id=48740&edit=1
#48783 [Opn->Fbk]: make install will fail saying phar file exists
ID: 48783 Updated by: cel...@php.net Reported By: dmda at yandex dot ru -Status: Open +Status: Feedback Bug Type: PHAR related Operating System: solaris 8/sparc PHP Version: 5.3.0 -Assigned To: +Assigned To: cellog New Comment: Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Previous Comments: [2009-07-23 15:48:05] s...@php.net Automatic comment from SVN on behalf of cellog Revision: http://svn.php.net/viewvc/?view=revision&revision=284652 Log: fix php bug #48783: make install will fail saying phar file exists [2009-07-03 00:06:56] dmda at yandex dot ru Description: make install fails with following result ln: cannot create /export/home/jvlad/php64/install/bin/phar: File exists make: *** [install-pharcmd] Error 2 It's something brand-new :) All previous versions of php installed everything and even if anything existed or remained from previous version, they did never fail Expected result: warning about existing files is okay, make install failure is not. -- Edit this bug report at http://bugs.php.net/?id=48783&edit=1
#48791 [Opn->Fbk]: open office files always reported as corrupted
ID: 48791 Updated by: cel...@php.net Reported By: RalfBecker at outdoor-training dot de -Status: Open +Status: Feedback Bug Type: PHAR related Operating System: CentOS5.3 PHP Version: 5.3.0 -Assigned To: +Assigned To: cellog New Comment: Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ this is a fascinating issue - the fix was implementing the data descriptor part of the zip standard. I didn't think anyone actually used that in modern ZIP implementations, since it is designed for creating streamed zip files, but I guess I was wrong. :) Previous Comments: [2009-07-23 16:30:27] s...@php.net Automatic comment from SVN on behalf of cellog Revision: http://svn.php.net/viewvc/?view=revision&revision=284658 Log: fix PHP bug #48791: open office files always reported as corrupted [2009-07-04 08:24:46] RalfBecker at outdoor-training dot de Here's my test file: https://pole.outdoor-training.de/test.odt Thought so far I was not able to produce an oo3 file, which can be read with phar. Thanks for looking into it :-) Ralf [2009-07-04 05:46:35] cel...@php.net please provide a link to an actual odt file that fails which I can use in a test case to reproduce the problem (no GPL things in it please) [2009-07-03 18:02:13] paj...@php.net oops, no :) [2009-07-03 18:02:00] paj...@php.net duplicate #48763 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/48791 -- Edit this bug report at http://bugs.php.net/?id=48791&edit=1
#48377 [Opn->Csd]: error message unclear on converting phar with existing file
ID: 48377 Updated by: cel...@php.net Reported By: cel...@php.net -Status: Open +Status: Closed Bug Type: PHAR related Operating System: n/a PHP Version: 5.3CVS-2009-05-24 (CVS) -Assigned To: +Assigned To: cellog New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2009-07-23 17:04:25] s...@php.net Automatic comment from SVN on behalf of cellog Revision: http://svn.php.net/viewvc/?view=revision&revision=284660 Log: fix PHP Bug #48377: error message unclear on converting phar with existing file [2009-05-24 19:13:29] cel...@php.net Description: if one is converting from a tar P1-1.0.0.tar to P1-1.0.0.tgz, the error message says the file extension is invalid, when in fact the problem is that the file exists and must be deleted prior to converting. -- Edit this bug report at http://bugs.php.net/?id=48377&edit=1
#49046 [Asn->Bgs]: namespaces with leading \ misbehave
ID: 49046
Updated by: cel...@php.net
Reported By: simon at stienen dot name
-Status: Assigned
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: FreeBSD
PHP Version: 5.3SVN-2009-07-24 (SVN)
Assigned To: dmitry
New Comment:
the code below is looking for the Bar constant in the current
namespace,
see http://us3.php.net/manual/en/language.namespaces.nsconstants.php
Previous Comments:
[2009-07-24 16:38:28] der...@php.net
Nonsense Jani, we allow more than on per file. Dmitry, could you please
have a look?
[2009-07-24 15:32:54] j...@php.net
RTFM: http://www.php.net/manual/en/language.namespaces.definition.php
You can only have one namespace per file..
[2009-07-24 13:18:46] simon at stienen dot name
Whyever this is necessary:
... happy now?)
[2009-07-24 11:26:58] simon at stienen dot name
Description:
So much wrong here ...
The initial intention was to get back into global namespace using the
"namespace X;" syntax. (Why isn't this possible? Neither as namespace;
namespace \; ... not even namespace \\;)
Curiously, "namespace \" expected the name of a constant.
Even more curiously, "namespace \foo" is looking for the constant "foo"
in the *current* namespace.
If the constant exists, the namespace directive is simply ignored.
If it does not, the script dies with a fatal error.
Reproduce code:
---
namespace Foo;
const Bar = "Blob";
namespace \Bar;
function x() { echo __NAMESPACE__; }
x();
Expected result:
Pretty much everything else than the actual result ... but at least
"Bar" or "Blob"
Actual result:
--
Foo
--
Edit this bug report at http://bugs.php.net/?id=49046&edit=1
#49046 [Bgs]: namespaces with leading \ misbehave
ID: 49046
Updated by: cel...@php.net
Reported By: simon at stienen dot name
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: FreeBSD
PHP Version: 5.3SVN-2009-07-24 (SVN)
New Comment:
note that there is some dissent amongst developers about the usefulness
of the "namespace" operator, so this may go bye-bye in a future PHP
5.3.x, in which case this bug will re-open
Previous Comments:
[2009-07-24 16:46:10] cel...@php.net
the code below is looking for the Bar constant in the current
namespace,
see http://us3.php.net/manual/en/language.namespaces.nsconstants.php
[2009-07-24 16:38:28] der...@php.net
Nonsense Jani, we allow more than on per file. Dmitry, could you please
have a look?
[2009-07-24 15:32:54] j...@php.net
RTFM: http://www.php.net/manual/en/language.namespaces.definition.php
You can only have one namespace per file..
[2009-07-24 13:18:46] simon at stienen dot name
Whyever this is necessary:
... happy now?)
[2009-07-24 11:26:58] simon at stienen dot name
Description:
So much wrong here ...
The initial intention was to get back into global namespace using the
"namespace X;" syntax. (Why isn't this possible? Neither as namespace;
namespace \; ... not even namespace \\;)
Curiously, "namespace \" expected the name of a constant.
Even more curiously, "namespace \foo" is looking for the constant "foo"
in the *current* namespace.
If the constant exists, the namespace directive is simply ignored.
If it does not, the script dies with a fatal error.
Reproduce code:
---
namespace Foo;
const Bar = "Blob";
namespace \Bar;
function x() { echo __NAMESPACE__; }
x();
Expected result:
Pretty much everything else than the actual result ... but at least
"Bar" or "Blob"
Actual result:
--
Foo
--
Edit this bug report at http://bugs.php.net/?id=49046&edit=1
#49046 [Bgs]: namespaces with leading \ misbehave
ID: 49046 Updated by: cel...@php.net Reported By: simon at stienen dot name Status: Bogus Bug Type: Scripting Engine problem Operating System: FreeBSD PHP Version: 5.3SVN-2009-07-24 (SVN) New Comment: more to the point, here are 2 scripts that do what you want it to do: and to go to global namespace, there is only one way: Previous Comments: [2009-07-24 16:47:42] cel...@php.net note that there is some dissent amongst developers about the usefulness of the "namespace" operator, so this may go bye-bye in a future PHP 5.3.x, in which case this bug will re-open [2009-07-24 16:46:10] cel...@php.net the code below is looking for the Bar constant in the current namespace, see http://us3.php.net/manual/en/language.namespaces.nsconstants.php [2009-07-24 16:38:28] der...@php.net Nonsense Jani, we allow more than on per file. Dmitry, could you please have a look? [2009-07-24 15:32:54] j...@php.net RTFM: http://www.php.net/manual/en/language.namespaces.definition.php You can only have one namespace per file.. [2009-07-24 13:18:46] simon at stienen dot name Whyever this is necessary: ... happy now?) 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/49046 -- Edit this bug report at http://bugs.php.net/?id=49046&edit=1
#48927 [Asn->Csd]: dump_bt in .gdbinit should use printu
ID: 48927 Updated by: cel...@php.net Reported By: alex dot emsenhuber at bluewin dot ch -Status: Assigned +Status: Closed Bug Type: Unicode Engine related Operating System: Mac OS X 10.5 PHP Version: 6CVS-2009-07-15 (CVS) Assigned To: cellog 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. yup Previous Comments: [2009-08-01 11:06:32] ka...@php.net Greg, did you fix this recently? [2009-07-15 16:20:04] alex dot emsenhuber at bluewin dot ch Description: Function's names are now unicode strings and the function/macro dump_bt in .gdbinit should be updated accordingly to use printu rather than printf. Proposed patch: Index: .gdbinit === --- .gdbinit(revision 284128) +++ .gdbinit(working copy) @@ -20,7 +20,8 @@ while $t printf "[0x%08x] ", $t if $t->function_state.function->common.function_name - printf "%s() ", $t->function_state.function->common.function_name + printu $t->function_state.function->common.function_name 0 + printf "() " else printf "??? " end Reproduce code: --- Running php from gdb and entring the following command when a breakpoint/error occurs: (gdb) zbacktrace Expected result: the backtrace prints correctly Actual result: -- [0x02e59368] Value can't be converted to integer. -- Edit this bug report at http://bugs.php.net/?id=48927&edit=1
#43857 [Asn->Fbk]: --program-suffix not always reflected everywhere
ID: 43857 Updated by: cel...@php.net Reported By: bjoern at xrow dot de -Status: Assigned +Status: Feedback Bug Type: Compile Failure Operating System: linux PHP Version: 5.2.8 Assigned To: cellog New Comment: Please try using this snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Previous Comments: [2009-08-02 19:11:15] s...@php.net Automatic comment from SVN on behalf of cellog Revision: http://svn.php.net/viewvc/?view=revision&revision=286687 Log: fix Bug #43857 [2009-07-26 19:42:27] j...@php.net Is this still not fixed? [2009-04-20 04:43:02] cel...@php.net this is about to be fixed some time this week, the PEAR version with the fix should be released any day now, and once its stability is verified, we'll update the phar. I will update the Makefile.frag when this happens, and then change the status to Feedback to make sure it works for you (my preliminary testing has it working here) [2009-01-22 01:16:51] j...@php.net Was the package updated for 5.2.8 or not..? (it's 5.2.9 soon..) [2008-11-29 04:08:17] cel...@php.net this is now fixed in PEAR CVS, but I will keep this open until the install phar in php's source is updated 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/43857 -- Edit this bug report at http://bugs.php.net/?id=43857&edit=1
#48753 [Asn->Csd]: go-pear.bat / phar not working
ID: 48753 Updated by: cel...@php.net Reported By: bjoern at xrow dot de -Status: Assigned +Status: Closed Bug Type: PHAR related Operating System: WINDOWS VISTA PHP Version: 5.3.0 Assigned To: cellog New Comment: This bug has been fixed in SVN. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2009-07-16 19:39:23] paj...@php.net See http://news.php.net/php.internals/44569 Can you guys simply regenerate this phar please? [2009-07-16 19:35:15] shank1969 at hotmail dot com http://lenss.nl/2008/07/pear-install-weirdness/ = 404. Any other ideas? [2009-07-16 18:48:14] bjoern at xrow dot de learn c and fix it on your own. your comment was not helpfull to solve this bug. [2009-07-16 18:45:53] justme at some dot com (this applies to WinXP as well) Great, yeat another NEW bug in PHP! Since 5.2, every time a new version appears, it is WORSE than previous and takes hours of workaround work to get it to work as expected. The EXIF extension has not worked since 5.2 and it still doesn't and now they have managed to get even the go-pear.bat broken. Don't they test anything anymore? [2009-07-03 10:05:15] rclerkin at gmail dot com In the mean time there is a workaround here; http://lenss.nl/2008/07/pear-install-weirdness/ I have used this to install pear successfuly with 5.3.0 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/48753 -- Edit this bug report at http://bugs.php.net/?id=48753&edit=1
#48791 [NoF->Csd]: open office files always reported as corrupted
ID: 48791 Updated by: cel...@php.net Reported By: RalfBecker at outdoor-training dot de -Status: No Feedback +Status: Closed Bug Type: PHAR related Operating System: CentOS5.3 PHP Version: 5.3.0 Assigned To: cellog Previous Comments: [2009-07-31 01:00:03] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2009-07-23 16:30:35] cel...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ this is a fascinating issue - the fix was implementing the data descriptor part of the zip standard. I didn't think anyone actually used that in modern ZIP implementations, since it is designed for creating streamed zip files, but I guess I was wrong. :) [2009-07-23 16:30:27] s...@php.net Automatic comment from SVN on behalf of cellog Revision: http://svn.php.net/viewvc/?view=revision&revision=284658 Log: fix PHP bug #48791: open office files always reported as corrupted [2009-07-04 08:24:46] RalfBecker at outdoor-training dot de Here's my test file: https://pole.outdoor-training.de/test.odt Thought so far I was not able to produce an oo3 file, which can be read with phar. Thanks for looking into it :-) Ralf [2009-07-04 05:46:35] cel...@php.net please provide a link to an actual odt file that fails which I can use in a test case to reproduce the problem (no GPL things in it please) 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/48791 -- Edit this bug report at http://bugs.php.net/?id=48791&edit=1
#49274 [Fbk]: filter_var() should accept objects without fatal error
ID: 49274 Updated by: cel...@php.net Reported By: cel...@php.net Status: Feedback Bug Type: Filter related Operating System: * PHP Version: 5.3SVN-2009-08-16 (SVN) New Comment: don't know, that's up to the developers to decide, don't you think? Previous Comments: [2009-08-17 09:32:59] j...@php.net Does this happen ONLY with PHP_5_3 branch? If not, please use the proper version string. [2009-08-16 22:09:05] cel...@php.net Description: throws a fatal error because stdClass can't be converted into a string. filter_var() should be more flexible and simply return false in this situation, it makes it very difficult to provide validation not just for untrusted user input but for untrusted third party use of libraries who may make it insecure by passing in the wrong value to a field for setting. -- Edit this bug report at http://bugs.php.net/?id=49274&edit=1
#49274 [Bgs->Opn]: filter_var() should accept objects without fatal error
ID: 49274 Updated by: cel...@php.net Reported By: cel...@php.net -Status: Bogus +Status: Open Bug Type: Filter related Operating System: * PHP Version: 5.3SVN-2009-08-16 (SVN) New Comment: all work without error. works without error. Only filter_var with an object that doesn't implement __toString fails with an error. Either filter is incorrectly returning false with no error on all of those other random types, or you're wrong, Jani. Previous Comments: [2009-08-17 13:13:43] j...@php.net This is not a bug. It's exactly what's supposed to happen. When you pass crap in you get crap out. The language isn't supposed to hold your hand in every corner. [2009-08-17 11:45:09] cel...@php.net don't know, that's up to the developers to decide, don't you think? [2009-08-17 09:32:59] j...@php.net Does this happen ONLY with PHP_5_3 branch? If not, please use the proper version string. [2009-08-16 22:09:05] cel...@php.net Description: throws a fatal error because stdClass can't be converted into a string. filter_var() should be more flexible and simply return false in this situation, it makes it very difficult to provide validation not just for untrusted user input but for untrusted third party use of libraries who may make it insecure by passing in the wrong value to a field for setting. -- Edit this bug report at http://bugs.php.net/?id=49274&edit=1
#49274 [Fbk]: filter_var() should accept objects without fatal error
ID: 49274 Updated by: cel...@php.net Reported By: cel...@php.net Status: Feedback Bug Type: Filter related Operating System: * PHP Version: 5.3SVN-2009-08-16 (SVN) New Comment: the stdClass was just to illustrate the point, this happens with any object that doesn't have a __toString(). I would imagine it would be easier to check for IS_OBJECT and then see if it implements __toString than to do a custom error handler. The performance should be about the same (dismal). Previous Comments: [2009-08-17 13:48:45] paj...@php.net As StdClass has no __toString implementation (obviously), it can't be converted to string. I tend to agree that it should not raise a fatal (recovable error) here as it defeats the main purpose of this API. I'm however not sure it is worth the effort to add custom error handler for this edge case. Patch welcome, it could help to get this edge case solved (I can't work on this exact issue any time soon). [2009-08-17 13:27:50] cel...@php.net all work without error. works without error. Only filter_var with an object that doesn't implement __toString fails with an error. Either filter is incorrectly returning false with no error on all of those other random types, or you're wrong, Jani. [2009-08-17 13:13:43] j...@php.net This is not a bug. It's exactly what's supposed to happen. When you pass crap in you get crap out. The language isn't supposed to hold your hand in every corner. [2009-08-17 11:45:09] cel...@php.net don't know, that's up to the developers to decide, don't you think? [2009-08-17 09:32:59] j...@php.net Does this happen ONLY with PHP_5_3 branch? If not, please use the proper version string. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/49274 -- Edit this bug report at http://bugs.php.net/?id=49274&edit=1
#49190 [Opn->Bgs]: PharData::convertToExecutable does not recognize filenames with multiple dots
ID: 49190
Updated by: cel...@php.net
Reported By: alexander dot wahl at netclusive dot com
-Status: Open
+Status: Bogus
Bug Type: PHAR related
Operating System: Linux 2.6.26-2-amd64
PHP Version: 5.3.0
New Comment:
convertToExecutable(Phar::PHAR, Phar::NONE,
'.one.two.phar');
} catch (Exception $e) {
echo $e->getMessage();
}
?>
will do what you desire.
Previous Comments:
[2009-08-07 14:26:50] alexander dot wahl at netclusive dot com
email typo
[2009-08-07 14:25:44] alexander dot wahl at netlusive dot com
email typo
[2009-08-07 14:23:26] alexander dot wahl at netclusive dot com
Description:
PharData::convertToExecutable does not recognize filenames with
multiple
dots, while creating the new archive. Everything from the first dot is
ignored.
Reproduce code:
---
convertToExecutable(Phar::PHAR, Phar::NONE, '.phar');
} catch (Exception $e) {
echo $e->getMessage();
}
?>
Expected result:
A new PHAR archive with the expected filename:
test.one.two.phar
Actual result:
--
A new PHAR archive with the filename:
test.phar
--
Edit this bug report at http://bugs.php.net/?id=49190&edit=1
#49682 [Asn]: Pear broken in php 5.2.11
ID: 49682 Updated by: cel...@php.net Reported By: kr_krack at yahoo dot com Status: Assigned Bug Type: Compile Failure Operating System: Ubuntu 8.04 LTS PHP Version: 5.2.11 -Assigned To: cellog +Assigned To: dufuz New Comment: Pierre: I have a newborn, I reassigned this to dufuz because I won't have time to fix this in any reasonable timeframe Previous Comments: [2009-10-27 07:14:28] jcua at shaw dot ca I have the same errors compiling php5.2.11 on centos 5.4 with apache 2.2.14 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1391 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1396 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1400 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1391 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1396 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1400 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1391 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1396 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1400 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1391 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1396 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1400 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1391 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1396 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1400 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1391 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1396 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1400 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1391 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1396 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.phar/PEAR/ChannelFile.php on line 1400 [2009-09-27 02:54:30] j...@php.net Assigned to the PEAR maintainer. [2009-09-26 18:58:39] kr_krack at yahoo dot com Description: I just compiled php 5.2.11, it seems that pear is broken again in this version, like in php 5.2.10. Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.pha r/PEAR/ChannelFile.php on line 1391 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.pha r/PEAR/ChannelFile.php on line 1396 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.pha r/PEAR/ChannelFile.php on line 1400 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.pha r/PEAR/ChannelFile.php on line 1391 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.pha r/PEAR/ChannelFile.php on line 1396 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.pha r/PEAR/ChannelFile.php on line 1400 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.pha r/PEAR/ChannelFile.php on line 1391 Warning: Cannot use a scalar value as an array in phar://install-pear-nozlib.pha
#49910 [Opn->Asn]: no support for ././@LongLink for long filenames in phar tar support
ID: 49910 Updated by: cel...@php.net Reported By: cel...@php.net -Status: Open +Status: Assigned Bug Type: PHAR related Operating System: n/a PHP Version: 5.3SVN-2009-10-18 (SVN) -Assigned To: +Assigned To: cellog New Comment: read support enabled. Will keep this open while I decide whether to also implement write support for filenames > 256 characters Previous Comments: [2009-11-11 21:03:00] s...@php.net Automatic comment from SVN on behalf of cellog Revision: http://svn.php.net/viewvc/?view=revision&revision=290527 Log: fix PHP Bug #49910: no support for ././@LongLink for long filenames in phar tar support [2009-10-18 04:27:47] cel...@php.net Description: The arcane (and poorly documented) ././@LongLink method of storing long filenames is not supported by ext/phar. The header stores the size of the filename, and the next block stores the filename itself. -- Edit this bug report at http://bugs.php.net/?id=49910&edit=1
#49938 [Asn->Ana]: Phar::isBuffering() returns inverted value
ID: 49938
Updated by: cel...@php.net
-Summary: Phar::startBuffering() didn't work. After this
isBuffering() returns false.
Reported By: nodkz at mail dot ru
-Status: Assigned
+Status: Analyzed
Bug Type: PHAR related
Operating System: Windows XP
PHP Version: 5.3.1RC2
Assigned To: cellog
New Comment:
The only bug is that Phar::isBuffering() has its values inverted.
It is not performant to use the buffering feature for extremely large
phar archives. Instead, use this code:
buildFromDirectory(__DIR__ . '/fillit');
$b = time(true);
echo "done in ", $b - $a, " seconds\n";
echo count($phar),"\n";
?>
I get 10 files added in approximately 118 seconds. The code you
supplied takes well over that just for the first 1 files.
Previous Comments:
[2009-10-21 07:57:23] nodkz at mail dot ru
Description:
I need add 100 000 files to phar arhive.
First 1000 files insert very quick. But when I insert from 9000 to
1, it works about 20 minutes.
I found that every changes writes to disk. In documentation I so
buffering operation to maket set of change, before writing to disk. If I
run startBuffering()/stopBuffering() commands.
So I try to run startBuffering() on PHP 5.2.11 - it doesn't work.
So I install PHP5.3.1RC2 - it doesn't work again.
Reproduce code:
---
$phar = new Phar('test.phar');
$phar->startBuffering();
var_dump($phar->isBuffering());
for($i=0;$i<10;$i++) {
// write data in files XXX/XXX.txt
$phar->addFromString( floor($i/1000).'/'.($i%1000).'txt', 'some
data');
}
$phar->stopBuffering();
Expected result:
Expect to see
bool(true)
Actual result:
--
But scripts shows:
bool(false)
--
Edit this bug report at http://bugs.php.net/?id=49938&edit=1
#43112 [Asn]: install-pear-installer fails
ID: 43112 Updated by: [EMAIL PROTECTED] Reported By: buck dot golemon at amd dot com Status: Assigned Bug Type: Compile Failure Operating System: RHEL (Taroon Update 3) PHP Version: 5.2.4 Assigned To: cellog New Comment: you have a corrupted PEAR installation from a previous version. Best is to wipe out /usr/local/lib/php/.registry and try again. Before wiping, run: pear list and note the packages installed. After you've upgraded PEAR, you will want to re-install these packages using pear upgrade -o where is the package you had installed. For example: pear upgrade -o HTML_QuickForm DB You did find a real bug in the error handling, but you would still need to wipe out your corrupted registry in order to upgrade PEAR even after the fix. Greg Previous Comments: [2007-10-31 10:18:50] [EMAIL PROTECTED] Assigned to the PEAR installer maintainer. [2007-10-26 23:55:27] buck dot golemon at amd dot com Description: # php --version PHP 5.2.4 (cli) (built: Oct 26 2007 15:29:20) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies # make install-pear-installer Warning: Invalid argument supplied for foreach() in phar://install-pear-nozlib.phar/PEAR/DependencyDB.php on line 425 Warning: Invalid argument supplied for foreach() in phar://install-pear-nozlib.phar/PEAR/DependencyDB.php on line 425 Warning: Invalid argument supplied for foreach() in phar://install-pear-nozlib.phar/PEAR/DependencyDB.php on line 425 Warning: Invalid argument supplied for foreach() in phar://install-pear-nozlib.phar/PEAR/DependencyDB.php on line 425 Warning: Invalid argument supplied for foreach() in phar://install-pear-nozlib.phar/PEAR/DependencyDB.php on line 425 Warning: Invalid argument supplied for foreach() in phar://install-pear-nozlib.phar/PEAR/DependencyDB.php on line 425 Notice: Array to string conversion in phar://install-pear-nozlib.phar/PEAR/Registry.php on line 483 Fatal error: Call to a member function setConfig() on a non-object in phar://install-pear-nozlib.phar/PEAR/DependencyDB.php on line 558 make: *** [install-pear-installer] Error 255 Expected result: install Actual result: -- fails -- Edit this bug report at http://bugs.php.net/?id=43112&edit=1
#43200 [Opn->Bgs]: Interface implementation / inheritence not possible in abstract classes
ID: 43200 Updated by: [EMAIL PROTECTED] Reported By: daniel dot gorski at develnet dot org -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: Linux PHP Version: 5.3CVS-2007-11-05 (CVS) New Comment: foo(); ?> If you don't want to implement a method from an interface, don't redeclare it, and the code will work as intended. Previous Comments: [2007-11-05 15:50:30] daniel dot gorski at develnet dot org Description: PHP 5.3.0-dev (cli) (built: Nov 5 2007 16:42:56) from todays CVS HEAD. The implementation of interfaces in concrete abstract classes and their inheritence is not possible: Reproduce code: --- foo(); ?> Expected result: Echoing "works" Actual result: -- Fatal error: Can't inherit abstract function A::foo() (previously declared abstract in B) in ... -- Edit this bug report at http://bugs.php.net/?id=43200&edit=1
#43589 [Opn]: infinite loop in bz2_filter.c
ID: 43589
Updated by: [EMAIL PROTECTED]
Reported By: greg at chiaraquartet dot net
Status: Open
Bug Type: Streams related
Operating System: n/a
PHP Version: 5.3CVS-2007-12-13 (CVS)
New Comment:
bad patch - missing if condition:
Index: ext/bz2/bz2_filter.c
===
RCS file: /repository/php-src/ext/bz2/bz2_filter.c,v
retrieving revision 1.3.2.2.2.5
diff -u -r1.3.2.2.2.5 bz2_filter.c
--- ext/bz2/bz2_filter.c9 Aug 2007 23:27:22 -
1.3.2.2.2.5
+++ ext/bz2/bz2_filter.c13 Dec 2007 19:34:48 -
@@ -132,6 +132,8 @@
data->strm.avail_out =
data->outbuf_len;
data->strm.next_out = data->outbuf;
exit_status = PSFS_PASS_ON;
+ } elseif (status == BZ_OK) {
+ break;
}
}
}
Previous Comments:
[2007-12-13 19:32:21] greg at chiaraquartet dot net
Description:
An endless loop is possible in the bz2 stream filter bzip2.decompress
if status == BZ_OK and data->strm.avail_out < data->outbuf_len
Reproduce code:
---
Index: ext/bz2/bz2_filter.c
===
RCS file: /repository/php-src/ext/bz2/bz2_filter.c,v
retrieving revision 1.3.2.2.2.5
diff -u -r1.3.2.2.2.5 bz2_filter.c
--- ext/bz2/bz2_filter.c9 Aug 2007 23:27:22 -
1.3.2.2.2.5
+++ ext/bz2/bz2_filter.c13 Dec 2007 19:29:27 -
@@ -132,6 +132,8 @@
data->strm.avail_out =
data->outbuf_len;
data->strm.next_out = data->outbuf;
exit_status = PSFS_PASS_ON;
+ } else {
+ break;
}
}
}
--
Edit this bug report at http://bugs.php.net/?id=43589&edit=1
#43793 [Opn->Csd]: zlib filter is unable to auto-detect gzip/zlib file headers
ID: 43793
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: Streams related
Operating System: n/a
PHP Version: 5.2.5
Assigned To: cellog
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2008-01-09 06:38:43] [EMAIL PROTECTED]
Description:
according to the zlib documentation for inflateInit2() in zlib.h
(online copy at
http://www.raspberryginger.com/jbailey/minix/html/zlib_8h-source.html):
windowBits can also be greater than 15 for optional gzip decoding. Add
32 to windowBits to enable zlib and gzip decoding with automatic
header
detection, or add 16 to decode only the gzip format (the zlib format
will return a Z_DATA_ERROR)
zlib.inflate filter's filterparams only accepts window size of 15, but
should accept up to 15+32 according to these docs.
Reproduce code:
---
15+16));
echo "2\n";
echo fread($fp, 2000);
fclose($fp);
// auto-detect
$fp = fopen(dirname(__FILE__) . '/test.txt.gz', 'r');
stream_filter_append($fp, 'zlib.inflate', STREAM_FILTER_READ,
array('window' => 15+32));
echo "3\n";
echo fread($fp, 2000);
fclose($fp);
?>
Expected result:
1
2
This is quite the thing ain't it
3
This is quite the thing ain't it
Actual result:
--
1
2
3
--
Edit this bug report at http://bugs.php.net/?id=43793&edit=1
#40189 [Csd->Opn]: endless loop in zlib.inflate stream filter
ID: 40189 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Closed +Status: Open Bug Type: Zlib Related Operating System: kubuntu linux PHP Version: 5CVS-2007-01-22 (CVS) -Assigned To: pollita +Assigned To: cellog New Comment: the fix for this bug unfortunately is incorrect, and can result in truncation of valid gzipped data. The correct fix is to look for Z_STREAM_END and to flush if it is returned. Currently, Z_OK and Z_STREAM_END are treated identically. I need to look at bz2 and see if the same fix needs to happen there. Previous Comments: [2007-01-25 12:22:56] [EMAIL PROTECTED] Patch committed (+ I ported the same patch to ext/bz2). [2007-01-23 23:58:53] [EMAIL PROTECTED] last detail: I have a 64-bit machine, not sure if that matters or not, but there you go [2007-01-23 23:57:55] [EMAIL PROTECTED] not sure what this cvs update -f business was. Forget that. Use this to reproduce the bug: cd pecl/phar cvs update -D "Jan 22 01:00:00 2007 UTC" ln -s ~/php5/ext/phar ~/pecl/phar cd ~/php5 ./configure --enable-debug --enable-phar --with-zlib make cli cd ext/phar/tests ~/php5/sapi/cli/php phar_ctx_001.phpt ~/php5/sapi/cli/php phar_ctx_001.phpt or ~/php5/sapi/cli/php phar_oo_compressed_001.phpt ~/php5/sapi/cli/php phar_oo_compressed_001.phpt (sometimes it only happened on the 2nd run for me) [2007-01-22 14:44:59] [EMAIL PROTECTED] cvs update -f "Jan 22 02:07:44 2007 UTC" I committed a workaround for the failure, completely forgetting you needed the file for this bug, sorry. This is the patch that needs to be reversed: http://cvs.php.net/viewvc.cgi/pecl/phar/phar.c?r1=1.135&r2=1.136 [2007-01-22 09:46:45] [EMAIL PROTECTED] I have to say, I can't reproduce it on my Suse either. 4 tests fail, but the ones you mentioned work fine. Btw, phar_oo_compressed_001.phpt fails because of several leaks: 016+ /local/dev/php/5_2/main/streams/streams.c(386) : Stream of type 'MEMORY' 0x40203094 (path:(null)) was not closed 017+ /local/dev/php/5_2/main/streams/streams.c(386) : Stream of type 'TEMP' 0x402004f8 (path:(null)) was not closed You need to close those streams when destroying the object. 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/40189 -- Edit this bug report at http://bugs.php.net/?id=40189&edit=1
#40189 [Opn->Csd]: endless loop in zlib.inflate stream filter
ID: 40189 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Zlib Related Operating System: kubuntu linux PHP Version: 5CVS-2007-01-22 (CVS) Assigned To: cellog New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. fixed in HEAD, PHP_5_2, PHP_5_3 Previous Comments: [2008-01-12 20:03:19] [EMAIL PROTECTED] the fix for this bug unfortunately is incorrect, and can result in truncation of valid gzipped data. The correct fix is to look for Z_STREAM_END and to flush if it is returned. Currently, Z_OK and Z_STREAM_END are treated identically. I need to look at bz2 and see if the same fix needs to happen there. [2007-01-25 12:22:56] [EMAIL PROTECTED] Patch committed (+ I ported the same patch to ext/bz2). [2007-01-23 23:58:53] [EMAIL PROTECTED] last detail: I have a 64-bit machine, not sure if that matters or not, but there you go [2007-01-23 23:57:55] [EMAIL PROTECTED] not sure what this cvs update -f business was. Forget that. Use this to reproduce the bug: cd pecl/phar cvs update -D "Jan 22 01:00:00 2007 UTC" ln -s ~/php5/ext/phar ~/pecl/phar cd ~/php5 ./configure --enable-debug --enable-phar --with-zlib make cli cd ext/phar/tests ~/php5/sapi/cli/php phar_ctx_001.phpt ~/php5/sapi/cli/php phar_ctx_001.phpt or ~/php5/sapi/cli/php phar_oo_compressed_001.phpt ~/php5/sapi/cli/php phar_oo_compressed_001.phpt (sometimes it only happened on the 2nd run for me) [2007-01-22 14:44:59] [EMAIL PROTECTED] cvs update -f "Jan 22 02:07:44 2007 UTC" I committed a workaround for the failure, completely forgetting you needed the file for this bug, sorry. This is the patch that needs to be reversed: http://cvs.php.net/viewvc.cgi/pecl/phar/phar.c?r1=1.135&r2=1.136 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/40189 -- Edit this bug report at http://bugs.php.net/?id=40189&edit=1
#43112 [Asn->Fbk]: install-pear-installer fails
ID: 43112 Updated by: [EMAIL PROTECTED] Reported By: buck dot golemon at amd dot com -Status: Assigned +Status: Feedback Bug Type: Compile Failure Operating System: RHEL (Taroon Update 3) PHP Version: 5.2.4 Assigned To: cellog New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi Previous Comments: [2007-11-01 04:11:40] [EMAIL PROTECTED] you have a corrupted PEAR installation from a previous version. Best is to wipe out /usr/local/lib/php/.registry and try again. Before wiping, run: pear list and note the packages installed. After you've upgraded PEAR, you will want to re-install these packages using pear upgrade -o where is the package you had installed. For example: pear upgrade -o HTML_QuickForm DB You did find a real bug in the error handling, but you would still need to wipe out your corrupted registry in order to upgrade PEAR even after the fix. Greg [2007-10-31 10:18:50] [EMAIL PROTECTED] Assigned to the PEAR installer maintainer. [2007-10-26 23:55:27] buck dot golemon at amd dot com Description: # php --version PHP 5.2.4 (cli) (built: Oct 26 2007 15:29:20) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies # make install-pear-installer Warning: Invalid argument supplied for foreach() in phar://install-pear-nozlib.phar/PEAR/DependencyDB.php on line 425 Warning: Invalid argument supplied for foreach() in phar://install-pear-nozlib.phar/PEAR/DependencyDB.php on line 425 Warning: Invalid argument supplied for foreach() in phar://install-pear-nozlib.phar/PEAR/DependencyDB.php on line 425 Warning: Invalid argument supplied for foreach() in phar://install-pear-nozlib.phar/PEAR/DependencyDB.php on line 425 Warning: Invalid argument supplied for foreach() in phar://install-pear-nozlib.phar/PEAR/DependencyDB.php on line 425 Warning: Invalid argument supplied for foreach() in phar://install-pear-nozlib.phar/PEAR/DependencyDB.php on line 425 Notice: Array to string conversion in phar://install-pear-nozlib.phar/PEAR/Registry.php on line 483 Fatal error: Call to a member function setConfig() on a non-object in phar://install-pear-nozlib.phar/PEAR/DependencyDB.php on line 558 make: *** [install-pear-installer] Error 255 Expected result: install Actual result: -- fails -- Edit this bug report at http://bugs.php.net/?id=43112&edit=1
#44021 [Opn->Fbk]: is_subclass_of Does Not Accept Namespaces
ID: 44021
Updated by: [EMAIL PROTECTED]
Reported By: rpanning at hotmail dot com
-Status: Open
+Status: Feedback
Bug Type: Class/Object related
Operating System: Windows XP SP2
PHP Version: 5.3CVS-2008-02-02 (snap)
New Comment:
Does the above code work for you? If yes, please close this bug as
bogus.
Automatic prefixing only occurs with absolute classnames, not compiled
variables. Imagine, for instance this code:
Now, if one calls this code from this file:
should it look for Blah::ChildClass, Foo::ChildClass, or ::ChildClass?
There is no deterministic way to answer this question. Therefore fully
qualified classnames must be used for anything that isn't a T_STRING.
Previous Comments:
[2008-02-02 02:01:37] rpanning at hotmail dot com
Description:
The is_subclass_of() function does not accept classes in namespaces. A
warning is generated and the statement results as FALSE.
Also, in the example, if the namespace definition is removed it works.
Reproduce code:
---
namespace NS;
class ParentClass {}
class ChildClass extends ParentClass {}
if (is_subclass_of('ChildClass', 'ParentClass')) {
print 'Yes';
} else {
print 'No';
}
Expected result:
Yes
Actual result:
--
Warning: Unknown class passed as parameter in C:\test.php on line 7
No
--
Edit this bug report at http://bugs.php.net/?id=44021&edit=1
#44126 [Opn->Bgs]: pear config-set works, but pecl config-set does not
ID: 44126 Updated by: [EMAIL PROTECTED] Reported By: mpb dot mail at gmail dot com -Status: Open +Status: Bogus Bug Type: *Configuration Issues Operating System: Linux 2.6 PHP Version: 5.2.5 New Comment: I am closing this bug as bogus because it was reported in the wrong bugtracker, not because of any problems in the report. The bug tracker for PEAR is listed below. This is a valid bug, but may be fixed. Please try: pear upgrade PEAR and then try the pecl config-set again. If the problem persists, please report at http://pear.php.net/bugs/report.php?package=PEAR For future reference, this is the bugtracker for the PEAR installer pear/pecl commands. Previous Comments: [2008-02-15 01:42:10] mpb dot mail at gmail dot com Description: I am able to set php_ini via pear, but not via pecl, as follows: $ pecl config-set php_ini /home/gobo/Programs/PHP/5.2.5/lib/php.ini config-set (php_ini, /home/gobo/Programs/PHP/5.2.5/lib/php.ini, user) failed, channel pecl.php.net exit 1 $ pear config-set php_ini /home/gobo/Programs/PHP/5.2.5/lib/php.ini config-set succeeded I would expect to be able to do config-set via either pear or pecl, as "pecl help" lists config-set as a valid pecl command. Thanks! -- Edit this bug report at http://bugs.php.net/?id=44126&edit=1
#45792 [Opn->Asn]: bz2 compressed files in zip failure
ID: 45792 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Assigned Bug Type: PHAR related Operating System: linux PHP Version: 5.3CVS-2008-08-12 (CVS) Assigned To: cellog Previous Comments: [2008-08-12 02:55:55] [EMAIL PROTECTED] Description: a zip archive created with info-zip using bzip2 compression is not properly processed by phar. -- Edit this bug report at http://bugs.php.net/?id=45792&edit=1
#45811 [Asn->Fbk]: file_exists crashes Apache when phar is enabled
ID: 45811 Updated by: [EMAIL PROTECTED] Reported By: guilhermeblanco at gmail dot com -Status: Assigned +Status: Feedback Bug Type: PHAR related Operating System: Windows Vista Home Premium 32bit PHP Version: 5.3CVS-2008-08-13 (snap) Assigned To: cellog New Comment: which apache version? I'd like to try to reproduce on linux where I can gdb if necessary Previous Comments: [2008-08-13 20:04:29] [EMAIL PROTECTED] Assigned to the PHAR maintainer. [2008-08-13 19:57:59] guilhermeblanco at gmail dot com Description: With phar enabled the code below crashes my Apache. I was requested to get a backtrace (#php.pecl @ efnet), here is the content: Analysis Summary TypeDescription Recommendation Error WARNING - DebugDiag was not able to locate debug symbols for C:\Server\php5.3.0-200808121402\ext\php_phar.dll, so the information below may be incomplete. In httpd__PID__2124__Date__08_13_2008__Time_04_42_34PM__689__Second_Chance_Exception_C005.dmp the module C:\Server\php5.3.0-200808121402\ext\php_phar.dll has caused an access violation exception (0xC005) when trying to read from memory location 0x on thread 2 Please follow up with the vendor of this module, The PHP Group, for further assistance with this issue. Information DebugDiag determined that this dump file (httpd__PID__2124__Date__08_13_2008__Time_04_42_34PM__689__Second_Chance_Exception_C005.dmp) is a crash dump and did not perform any hang analysis. If you wish to enable combined crash and hang analysis for crash dumps, edit the CrashHangAnalysis.asp script (located in the DebugDiag\Scripts folder) and set the g_DoCombinedAnalysis constant to True. Analysis Details Your browser settings are currently prohibiting this report's scripts from running. This is preventing some features of this analysis report from displaying properly. To enable scripts to run, right-click the security warning above and choose "Allow Blocked Content..." or enable the "Allow active content to run in files on My Computer*" setting on the Advanced tab of your "Internet Options" dialog to avoid being prompted in the future Table Of Contents httpd__PID__2124__Date__08_13_2008__Time_04_42_34PM__689__Second_Chance_Exception_C005.dmp Faulting Thread Report for httpd__PID__2124__Date__08_13_2008__Time_04_42_34PM__689__Second_Chance_Exception_C005.dmp Report for httpd__PID__2124__Date__08_13_2008__Time_04_42_34PM__689__Second_Chance_Exception_C005.dmp Type of Analysis PerformedCrash Analysis Machine Name BLANCO-LAPTOP Operating System Windows Vista Service Pack 1 Number Of Processors 2 Process ID2124 Process Image C:\Server\Apache2.2.8\bin\httpd.exe System Up-Time14:44:18 Process Up-Time 00:00:24 Thread 2 - System ID 4924 Entry point msvcrt!beginthreadex+86 Create time 13/08/2008 16:42:10 Time spent in user mode 0 Days 0:0:0.0 Time spent in kernel mode 0 Days 0:0:0.0 FunctionArg 1 Arg 2 Arg 3 Source 0x 0001040ed2f0 php_phar+5d5b 0001040ed2f0 php5ts!execute+cc5 WARNING - DebugDiag was not able to locate debug symbols for C:\Server\php5.3.0-200808121402\ext\php_phar.dll, so the information below may be incomplete. In httpd__PID__2124__Date__08_13_2008__Time_04_42_34PM__689__Second_Chance_Exception_C005.dmp the module C:\Server\php5.3.0-200808121402\ext\php_phar.dll has caused an access violation exception (0xC005) when trying to read from memory location 0x on thread 2 Module Information Image Name: C:\Server\php5.3.0-200808121402\ext\php_phar.dll Symbol Type: Export Base address: 0x00b0Time Stamp: Tue Aug 12 15:01:58 2008 Checksum: 0xComments: Thanks to Gregory Beaver, Marcus Boerger COM DLL:False Company Name: The PHP Group ISAPIExtension: False File Description: PHP Archive ISAPIFilter:False File Version: 5.3.0alpha2-dev Managed DLL:False Internal Name:PHAR extension VB DLL: False Legal Copyright: Copyright © 1997-2008 The PHP Group Loaded Image Name: php_phar.dll Legal Trademarks: PHP Mapped Image Name: C:\Server\php5.3.0-200808121402\ext\php_phar.dll Original filename: php_phar.dll Module name:php_phar Private Build: Single Threaded:False Product Name: PHP Module Size:224,00 KBytes Product Version: 5.3.0alpha2-
#45811 [Asn->Fbk]: file_exists crashes Apache when phar is enabled
ID: 45811 Updated by: [EMAIL PROTECTED] Reported By: guilhermeblanco at gmail dot com -Status: Assigned +Status: Feedback Bug Type: PHAR related Operating System: Windows Vista Home Premium 32bit PHP Version: 5.3CVS-2008-08-13 (snap) Assigned To: cellog New Comment: I cannot reproduce this on windows or linux, please provide more information. Previous Comments: [2008-08-18 06:59:21] [EMAIL PROTECTED] > Process Image C:\Server\Apache2.2.8\bin\httpd.exe I assume that would be Apache2.2.8 he is running... [2008-08-18 05:05:33] [EMAIL PROTECTED] which apache version? I'd like to try to reproduce on linux where I can gdb if necessary [2008-08-13 20:04:29] [EMAIL PROTECTED] Assigned to the PHAR maintainer. [2008-08-13 19:57:59] guilhermeblanco at gmail dot com Description: With phar enabled the code below crashes my Apache. I was requested to get a backtrace (#php.pecl @ efnet), here is the content: Analysis Summary TypeDescription Recommendation Error WARNING - DebugDiag was not able to locate debug symbols for C:\Server\php5.3.0-200808121402\ext\php_phar.dll, so the information below may be incomplete. In httpd__PID__2124__Date__08_13_2008__Time_04_42_34PM__689__Second_Chance_Exception_C005.dmp the module C:\Server\php5.3.0-200808121402\ext\php_phar.dll has caused an access violation exception (0xC005) when trying to read from memory location 0x on thread 2 Please follow up with the vendor of this module, The PHP Group, for further assistance with this issue. Information DebugDiag determined that this dump file (httpd__PID__2124__Date__08_13_2008__Time_04_42_34PM__689__Second_Chance_Exception_C005.dmp) is a crash dump and did not perform any hang analysis. If you wish to enable combined crash and hang analysis for crash dumps, edit the CrashHangAnalysis.asp script (located in the DebugDiag\Scripts folder) and set the g_DoCombinedAnalysis constant to True. Analysis Details Your browser settings are currently prohibiting this report's scripts from running. This is preventing some features of this analysis report from displaying properly. To enable scripts to run, right-click the security warning above and choose "Allow Blocked Content..." or enable the "Allow active content to run in files on My Computer*" setting on the Advanced tab of your "Internet Options" dialog to avoid being prompted in the future Table Of Contents httpd__PID__2124__Date__08_13_2008__Time_04_42_34PM__689__Second_Chance_Exception_C005.dmp Faulting Thread Report for httpd__PID__2124__Date__08_13_2008__Time_04_42_34PM__689__Second_Chance_Exception_C005.dmp Report for httpd__PID__2124__Date__08_13_2008__Time_04_42_34PM__689__Second_Chance_Exception_C005.dmp Type of Analysis PerformedCrash Analysis Machine Name BLANCO-LAPTOP Operating System Windows Vista Service Pack 1 Number Of Processors 2 Process ID2124 Process Image C:\Server\Apache2.2.8\bin\httpd.exe System Up-Time14:44:18 Process Up-Time 00:00:24 Thread 2 - System ID 4924 Entry point msvcrt!beginthreadex+86 Create time 13/08/2008 16:42:10 Time spent in user mode 0 Days 0:0:0.0 Time spent in kernel mode 0 Days 0:0:0.0 FunctionArg 1 Arg 2 Arg 3 Source 0x 0001040ed2f0 php_phar+5d5b 0001040ed2f0 php5ts!execute+cc5 WARNING - DebugDiag was not able to locate debug symbols for C:\Server\php5.3.0-200808121402\ext\php_phar.dll, so the information below may be incomplete. In httpd__PID__2124__Date__08_13_2008__Time_04_42_34PM__689__Second_Chance_Exception_C005.dmp the module C:\Server\php5.3.0-200808121402\ext\php_phar.dll has caused an access violation exception (0xC005) when trying to read from memory location 0x on thread 2 Module Information Image Name: C:\Server\php5.3.0-200808121402\ext\php_phar.dll Symbol Type: Export Base address: 0x00b0Time Stamp: Tue Aug 12 15:01:58 2008 Checksum: 0xComments: Thanks to Gregory Beaver, Marcus Boerger COM DLL:False Company Name: The PHP Group ISAPIExtension: False File Description: PHP Archive ISAPIFilter:False File Version: 5.3.0alpha2-dev Managed DLL:False Internal Name:PHAR extension VB DLL: False Legal Copyrigh
#45811 [Fbk->Bgs]: file_exists crashes Apache when phar is enabled
ID: 45811 Updated by: [EMAIL PROTECTED] Reported By: guilhermeblanco at gmail dot com -Status: Feedback +Status: Bogus Bug Type: PHAR related Operating System: Windows Vista Home Premium 32bit PHP Version: 5.3CVS-2008-08-13 (snap) Assigned To: cellog New Comment: no wonder I can't duplicate, this was already fixed in Bug #45613, making this bug a duplicate bug Previous Comments: [2008-08-18 15:00:59] [EMAIL PROTECTED] I cannot reproduce this on windows or linux, please provide more information. [2008-08-18 06:59:21] [EMAIL PROTECTED] > Process Image C:\Server\Apache2.2.8\bin\httpd.exe I assume that would be Apache2.2.8 he is running... [2008-08-18 05:05:33] [EMAIL PROTECTED] which apache version? I'd like to try to reproduce on linux where I can gdb if necessary [2008-08-13 20:04:29] [EMAIL PROTECTED] Assigned to the PHAR maintainer. [2008-08-13 19:57:59] guilhermeblanco at gmail dot com Description: With phar enabled the code below crashes my Apache. I was requested to get a backtrace (#php.pecl @ efnet), here is the content: Analysis Summary TypeDescription Recommendation Error WARNING - DebugDiag was not able to locate debug symbols for C:\Server\php5.3.0-200808121402\ext\php_phar.dll, so the information below may be incomplete. In httpd__PID__2124__Date__08_13_2008__Time_04_42_34PM__689__Second_Chance_Exception_C005.dmp the module C:\Server\php5.3.0-200808121402\ext\php_phar.dll has caused an access violation exception (0xC005) when trying to read from memory location 0x on thread 2 Please follow up with the vendor of this module, The PHP Group, for further assistance with this issue. Information DebugDiag determined that this dump file (httpd__PID__2124__Date__08_13_2008__Time_04_42_34PM__689__Second_Chance_Exception_C005.dmp) is a crash dump and did not perform any hang analysis. If you wish to enable combined crash and hang analysis for crash dumps, edit the CrashHangAnalysis.asp script (located in the DebugDiag\Scripts folder) and set the g_DoCombinedAnalysis constant to True. Analysis Details Your browser settings are currently prohibiting this report's scripts from running. This is preventing some features of this analysis report from displaying properly. To enable scripts to run, right-click the security warning above and choose "Allow Blocked Content..." or enable the "Allow active content to run in files on My Computer*" setting on the Advanced tab of your "Internet Options" dialog to avoid being prompted in the future Table Of Contents httpd__PID__2124__Date__08_13_2008__Time_04_42_34PM__689__Second_Chance_Exception_C005.dmp Faulting Thread Report for httpd__PID__2124__Date__08_13_2008__Time_04_42_34PM__689__Second_Chance_Exception_C005.dmp Report for httpd__PID__2124__Date__08_13_2008__Time_04_42_34PM__689__Second_Chance_Exception_C005.dmp Type of Analysis PerformedCrash Analysis Machine Name BLANCO-LAPTOP Operating System Windows Vista Service Pack 1 Number Of Processors 2 Process ID2124 Process Image C:\Server\Apache2.2.8\bin\httpd.exe System Up-Time14:44:18 Process Up-Time 00:00:24 Thread 2 - System ID 4924 Entry point msvcrt!beginthreadex+86 Create time 13/08/2008 16:42:10 Time spent in user mode 0 Days 0:0:0.0 Time spent in kernel mode 0 Days 0:0:0.0 FunctionArg 1 Arg 2 Arg 3 Source 0x 0001040ed2f0 php_phar+5d5b 0001040ed2f0 php5ts!execute+cc5 WARNING - DebugDiag was not able to locate debug symbols for C:\Server\php5.3.0-200808121402\ext\php_phar.dll, so the information below may be incomplete. In httpd__PID__2124__Date__08_13_2008__Time_04_42_34PM__689__Second_Chance_Exception_C005.dmp the module C:\Server\php5.3.0-200808121402\ext\php_phar.dll has caused an access violation exception (0xC005) when trying to read from memory location 0x on thread 2 Module Information Image Name: C:\Server\php5.3.0-200808121402\ext\php_phar.dll Symbol Type: Export Base address: 0x00b0Time Stamp: Tue Aug 12 15:01:58 2008 Checksum: 0xComments: Thanks to Gregory Beaver, Marcus Boerger COM DLL:False Company Name: The PHP Group ISAPIExtension:
#45815 [Asn->Bgs]: Illegal stub for phar
ID: 45815
Updated by: [EMAIL PROTECTED]
Reported By: felipensp at gmail dot com
-Status: Assigned
+Status: Bogus
Bug Type: PHAR related
Operating System: FreeBSD
PHP Version: 5.3CVS-2008-08-13 (CVS)
Assigned To: cellog
New Comment:
valid bug, but duplicate of Bug #45726
Previous Comments:
[2008-08-14 17:43:53] [EMAIL PROTECTED]
Assigned to the PHAR maintainer.
[2008-08-13 23:50:32] felipensp at gmail dot com
Description:
In the end of compilation:
Generating phar.php
Generating phar.phar
pear: not found
Pear package PHP_Archive or Archive.php class file not found.
Fatal error: Uncaught exception 'PharException' with
message 'illegal stub for
phar "/usr/home/felipe/php5/ext/phar/phar.phar"'
in /usr/home/felipe/php5/ext/phar/phar.php:994
Stack trace:
#0 /usr/home/felipe/php5/ext/phar/phar.php(994):
Phar->setStub('#!/usr/local/bi...')
#1 /usr/home/felipe/php5/ext/phar/phar.php(1054):
PharCommand->phar_set_stub_begin(Object(Phar), '/usr/home/felip...',
'/usr/home/felip...', '/usr/local/bin/...')
#2 [internal function]: PharCommand->cli_cmd_run_pack(Array)
#3 /usr/home/felipe/php5/ext/phar/phar.php(225):
call_user_func(Array, Array)
#4 /usr/home/felipe/php5/ext/phar/phar.php(2073):
CLICommand->__construct(19, Array)
#5 {main}
thrown in /usr/home/felipe/php5/ext/phar/phar.php on line 994
*** Error code 255
Stop in /usr/home/felipe/php5.
--
Edit this bug report at http://bugs.php.net/?id=45815&edit=1
#45792 [Asn]: bz2 compressed files in zip failure
ID: 45792 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Assigned Bug Type: PHAR related Operating System: linux PHP Version: 5.3CVS-2008-08-12 (CVS) Assigned To: cellog New Comment: significant progress - I've got this working for the described test case. The largest problem was that the zip header was not checked for validity when opening an internal zip file, and local header can have a different offset than the central header (stupid design flaw of ZIP file format). The fix must be ported to conversion convertTo*() and a few other places prior to commit. Previous Comments: [2008-08-12 02:55:55] [EMAIL PROTECTED] Description: a zip archive created with info-zip using bzip2 compression is not properly processed by phar. -- Edit this bug report at http://bugs.php.net/?id=45792&edit=1
#45792 [Asn->Csd]: bz2 compressed files in zip failure
ID: 45792 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Assigned +Status: Closed Bug Type: PHAR related Operating System: linux PHP Version: 5.3CVS-2008-08-12 (CVS) Assigned To: cellog New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2008-08-18 21:51:34] [EMAIL PROTECTED] significant progress - I've got this working for the described test case. The largest problem was that the zip header was not checked for validity when opening an internal zip file, and local header can have a different offset than the central header (stupid design flaw of ZIP file format). The fix must be ported to conversion convertTo*() and a few other places prior to commit. [2008-08-12 02:55:55] [EMAIL PROTECTED] Description: a zip archive created with info-zip using bzip2 compression is not properly processed by phar. -- Edit this bug report at http://bugs.php.net/?id=45792&edit=1
#46032 [Opn->Csd]: PharData::__construct() - wrong memory read
ID: 46032
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: PHAR related
Operating System: *
PHP Version: 5.2CVS-2008-09-09 (CVS)
-Assigned To:
+Assigned To: cellog
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
thanks Felipe :)
Previous Comments:
[2008-09-10 17:04:13] [EMAIL PROTECTED]
See also:
__construct('`hf???0...')
#1 {main}
thrown in %s on line %d
--
Edit this bug report at http://bugs.php.net/?id=46032&edit=1
#46060 [Opn->Csd]: Phar::addEmptyDir() breaks
ID: 46060
Updated by: [EMAIL PROTECTED]
-Summary: addEmptyDir() breaks
Reported By: xl269 at cam dot ac dot uk
-Status: Open
+Status: Closed
Bug Type: PHAR related
Operating System: Debian GNU/Linux lenny
PHP Version: 5.3.0alpha2
-Assigned To:
+Assigned To: cellog
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
fixed in 5.3, HEAD and pecl, thanks for the report
Previous Comments:
[2008-09-12 16:43:35] xl269 at cam dot ac dot uk
the following will create an empty directory "test"
$zip->addFromString("test/", "");
[2008-09-12 03:49:50] xl269 at cam dot ac dot uk
whoops, the "* result" sections should read "test.tar" not
"test.tar.bz2" (if it isn't obvious). i was playing around with the bug
whilst editing this report, and overlooked updating that part.
[2008-09-12 03:33:30] xl269 at cam dot ac dot uk
Description:
PharData::addEmptyDir() on a tar archive adds empty files instead of
directories.
Reproduce code:
---
$zip = new PharData('test.tar');
$zip = $zip->convertToData(Phar::TAR, Phar::NONE); // compression
scheme does not affect the result.
// Phar::ZIP is not buggy, but you need to add a file to the empty
directory to see this.
$zip->startBuffering();
$zip->addEmptyDir('test/');
// $zip->addFile('file', 'test/file'); // see (*)
$zip->stopBuffering();
Expected result:
test.tar.bz2 should contain 1 empty directory "test"
Actual result:
--
test.tar.bz2 contains 1 empty *file* "test"
(*) doing this will create the directory "test" automatically, so that
the tar archive now contains both a file and a directory called "test",
and becomes unextractable.
--
Edit this bug report at http://bugs.php.net/?id=46060&edit=1
#46072 [Asn->Fbk]: Compile failure under IRIX 6.5.30 building util.c
ID: 46072 Updated by: [EMAIL PROTECTED] Reported By: neko at nekochan dot net -Status: Assigned +Status: Feedback Bug Type: Compile Failure Operating System: IRIX 6.5.30 PHP Version: 5.3.0alpha2 Assigned To: cellog New Comment: Thanks for the report. Would you try the patch against current ext/phar CVS of PHP_5_3 found at: http://pear.php.net/~greg/bug46072.patch.txt and report on whether it works? Previous Comments: [2008-09-13 20:32:17] neko at nekochan dot net IRIX64 Kazehana 6.5 6.5.30f 07202013 IP35 MIPSpro Compilers: Version 7.4.4m [2008-09-13 20:31:10] neko at nekochan dot net Description: Description: Able to compile up to and including php-5.2.6 without error (and run in a production environment). My attempt to build php-5.3.0alpha2 dies in util.c (multiple errors) Reproduce code: --- './configure' '--prefix=/usr/nekoware/php5' '--enable-dba' '--enable-dbx' '--enable-calendar' '--enable-wddx' '--with-config-file-path=/usr/nekoware/etc/php5' '--with-apxs2=/usr/nekoware/apache2/bin/apxs' '--enable-cli' '--with-libxml-dir=/usr/nekoware' '--with-expat-dir=/usr/nekoware' '--with-png-dir=/usr/nekoware' '--with-jpeg-dir=/usr/nekoware' '--with-freetype-dir=/usr/nekoware' '--with-zlib-dir=/usr/nekoware' '--with-zlib' '--with-curlwrappers' '--with-curl=shared,/usr/nekoware' '--with-openssl=shared,/usr/nekoware' '--with-mysql=shared,mysqlnd' '--with-mysqli=shared,mysqlnd' '--with-mhash=shared,/usr/nekoware' '--with-mcrypt=shared,/usr/nekoware' '--with-bz2=shared,/usr/nekoware' '--enable-ftp=shared' '--enable-sockets=shared' '--with-gd=shared '--enable-exif=shared' '--enable-dbase=shared' '--with-xmlrpc' '--with-gettext=shared,/usr/nekoware' '--with-iconv-dir=/usr/nekoware' '--enable-mbstring=shared' '--enable-sysvsem=shared' '--enable-sysvshm=shared' '--enable-sysvmsg=shared' '--with-xpm-dir=/usr/lib32' '--enable-zip=shared' '--with-pgsql=shared,/usr/nekoware/pgsql' '--with-tsrm-st' Expected result: Completed build. Actual result: -- /bin/sh /opt/build/php-5.3.0alpha2/libtool --silent --preserve-dup- deps --mode=compile c99 -Iext/phar/ -I/opt/build/php- 5.3.0alpha2/ext/phar/ -DPHP_ATOM_INC -I/opt/build/php- 5.3.0alpha2/include -I/opt/build/php-5.3.0alpha2/main - I/opt/build/php-5.3.0alpha2 -I/opt/build/php- 5.3.0alpha2/ext/ereg/regex -I/usr/nekoware/include/libxml2 - I/usr/nekoware/include -I/opt/build/php-5.3.0alpha2/ext/date/lib - I/usr/nekoware/include/freetype2 -I/opt/build/php- 5.3.0alpha2/ext/mbstring/oniguruma -I/opt/build/php- 5.3.0alpha2/ext/mbstring/libmbfl -I/opt/build/php- 5.3.0alpha2/ext/mbstring/libmbfl/mbfl - I/usr/nekoware/mysql5/include/mysql -I/opt/build/php- 5.3.0alpha2/ext/sqlite3/libsqlite -I/usr/nekoware/pgsql/include - I/opt/build/php-5.3.0alpha2/TSRM -I/opt/build/php-5.3.0alpha2/Zend - D_XPG_IV -L/usr/nekoware/lib -L/usr/lib32 -I/usr/include -mips4 -O2 - I/usr/nekoware/include -I/usr/include -Wl,-rpath - Wl,/usr/nekoware/lib:/usr/nekoware/mysql5/lib/mysql - OPT:Olimit=0:roundoff=3 -TARG:platform=IP35:proc=r16000 -c /opt/build/php-5.3.0alpha2/ext/phar/util.c -o ext/phar/util.lo cc-3604 c99: WARNING File = /opt/build/php- 5.3.0alpha2/Zend/zend_alloc.h, Line = 87 missing return statement at end of non-void function "__zend_malloc" } ^ cc-3604 c99: WARNING File = /opt/build/php- 5.3.0alpha2/Zend/zend_alloc.h, Line = 104 missing return statement at end of non-void function "__zend_realloc" } ^ cc-3970 c99: WARNING File = /opt/build/php- 5.3.0alpha2/Zend/zend_execute.h, Line = 70 conversion from pointer to same-sized integral type (potential portability problem) FREE_ZVAL_REL(p); ^ cc-3970 c99: WARNING File = /opt/build/php- 5.3.0alpha2/Zend/zend_execute.h, Line = 272 conversion from pointer to same-sized integral type (potential portability problem) int delete_count = (int)(zend_uintptr_t) *p; ^ cc-3970 c99: WARNING File = /opt/build/php- 5.3.0alpha2/Zend/zend_execute.h, Line = 285 conversion from pointer to same-sized integral type (potential portability problem) int arg_count = (int)(zend_uintptr_t) *p; ^ cc-1079 c99: ERROR File = /opt/build/php-5.3.0alpha2/ext/phar/tar.h, Line = 46 A type specifier is ex
#46072 [Opn->Fbk]: Compile failure under IRIX 6.5.30 building util.c
ID: 46072 Updated by: [EMAIL PROTECTED] Reported By: neko at nekochan dot net -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: IRIX 6.5.30 PHP Version: 5.3.0alpha2 Assigned To: cellog New Comment: that bus error is not phar-related (as you can see from the backtrace). Did you ./cvsclean prior to rebuilding? Previous Comments: [2008-09-14 04:48:19] neko at nekochan dot net # dbx ./sapi/cli/php core dbx version 7.3.7 (96015_Nov16 MR) Nov 16 2004 07:34:16 Core from signal SIGBUS: Bus error (dbx) where Thread 0x1 > 0 zend_assign_to_variable(0x14a0, 0x107fde5c, 0x0, 0xc, 0x21000, 0x1000, 0xc, 0x106bab80) ["/opt/build/php- 5.3.0alpha2/Zend/zend_execute.c":739, 0x1039ebcc] 1 ZEND_ASSIGN_SPEC_CV_TMP_HANDLER(0x107fdde8, 0xd, 0x0, 0xc, 0x21000, 0x1000, 0xc, 0x106bab80) ["/opt/build/php- 5.3.0alpha2/Zend/zend_vm_execute.h":25843, 0x103ef740] 2 execute(0x106ba598, 0xd, 0x0, 0xc, 0x21000, 0x1000, 0xc, 0x106bab80) ["/opt/build/php-5.3.0alpha2/Zend/zend_vm_execute.h":104, 0x103a0418] 3 zend_execute_scripts(0x8, 0xd, 0x3, 0x0, 0x21000, 0x1000, 0xc, 0x106bab80) ["/opt/build/php-5.3.0alpha2/Zend/zend.c":1197, 0x10374a58] 4 php_execute_script(0x14a0, 0xd, 0x0, 0xc, 0x21000, 0x1000, 0xc, 0x106bab80) ["/opt/build/php-5.3.0alpha2/main/main.c":2074, 0x10313158] 5 main(0xf, 0x7fff2ef4, 0x0, 0xc, 0x21000, 0x1000, 0xc, 0x106bab80) ["/opt/build/php-5.3.0alpha2/sapi/cli/php_cli.c":1130, 0x103fed20] 6 __start() ["/xlv55/kudzu- apr12/work/irix/lib/libc/libc_n32_M4/csu/crt1text.s":177, 0x1004cb88] (dbx) [2008-09-14 02:44:32] neko at nekochan dot net The linked patch does allow the util.c compile to complete without error, but the build process halts with a bus error: Generating phar.php gmake: *** [ext/phar/phar.php] Bus error (core dumped) gmake: *** Deleting file `ext/phar/phar.php' [2008-09-13 21:40:02] [EMAIL PROTECTED] Thanks for the report. Would you try the patch against current ext/phar CVS of PHP_5_3 found at: http://pear.php.net/~greg/bug46072.patch.txt and report on whether it works? [2008-09-13 20:32:17] neko at nekochan dot net IRIX64 Kazehana 6.5 6.5.30f 07202013 IP35 MIPSpro Compilers: Version 7.4.4m [2008-09-13 20:31:10] neko at nekochan dot net Description: Description: Able to compile up to and including php-5.2.6 without error (and run in a production environment). My attempt to build php-5.3.0alpha2 dies in util.c (multiple errors) Reproduce code: --- './configure' '--prefix=/usr/nekoware/php5' '--enable-dba' '--enable-dbx' '--enable-calendar' '--enable-wddx' '--with-config-file-path=/usr/nekoware/etc/php5' '--with-apxs2=/usr/nekoware/apache2/bin/apxs' '--enable-cli' '--with-libxml-dir=/usr/nekoware' '--with-expat-dir=/usr/nekoware' '--with-png-dir=/usr/nekoware' '--with-jpeg-dir=/usr/nekoware' '--with-freetype-dir=/usr/nekoware' '--with-zlib-dir=/usr/nekoware' '--with-zlib' '--with-curlwrappers' '--with-curl=shared,/usr/nekoware' '--with-openssl=shared,/usr/nekoware' '--with-mysql=shared,mysqlnd' '--with-mysqli=shared,mysqlnd' '--with-mhash=shared,/usr/nekoware' '--with-mcrypt=shared,/usr/nekoware' '--with-bz2=shared,/usr/nekoware' '--enable-ftp=shared' '--enable-sockets=shared' '--with-gd=shared '--enable-exif=shared' '--enable-dbase=shared' '--with-xmlrpc' '--with-gettext=shared,/usr/nekoware' '--with-iconv-dir=/usr/nekoware' '--enable-mbstring=shared' '--enable-sysvsem=shared' '--enable-sysvshm=shared' '--enable-sysvmsg=shared' '--with-xpm-dir=/usr/lib32' '--enable-zip=shared' '--with-pgsql=shared,/usr/nekoware/pgsql' '--with-tsrm-st' Expected result: Completed build. Actual result: -- /bin/sh /opt/build/php-5.3.0alpha2/libtool --silent --preserve-dup- deps --mode=compile c99 -Iext/phar/ -I/opt/build/php- 5.3.0alpha2/ext/phar/ -DPHP_ATOM_INC -I/opt/build/php- 5.3.0alpha2/include -I/opt/build/php-5.3.0alpha2/main - I/opt/build/php-5.3.0alpha2 -I/opt/build/php- 5.3.0alpha2/ext/ereg/regex -I/usr/nekoware/include/libxml2 - I/usr/nekoware/include -I/opt/build/php-5.3.0al
#46072 [Fbk->Csd]: Compile failure under IRIX 6.5.30 building util.c
ID: 46072 Updated by: [EMAIL PROTECTED] Reported By: neko at nekochan dot net -Status: Feedback +Status: Closed Bug Type: Compile Failure Operating System: IRIX 6.5.30 PHP Version: 5.3.0alpha2 Assigned To: cellog New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2008-09-14 06:37:52] [EMAIL PROTECTED] that bus error is not phar-related (as you can see from the backtrace). Did you ./cvsclean prior to rebuilding? [2008-09-14 04:48:19] neko at nekochan dot net # dbx ./sapi/cli/php core dbx version 7.3.7 (96015_Nov16 MR) Nov 16 2004 07:34:16 Core from signal SIGBUS: Bus error (dbx) where Thread 0x1 > 0 zend_assign_to_variable(0x14a0, 0x107fde5c, 0x0, 0xc, 0x21000, 0x1000, 0xc, 0x106bab80) ["/opt/build/php- 5.3.0alpha2/Zend/zend_execute.c":739, 0x1039ebcc] 1 ZEND_ASSIGN_SPEC_CV_TMP_HANDLER(0x107fdde8, 0xd, 0x0, 0xc, 0x21000, 0x1000, 0xc, 0x106bab80) ["/opt/build/php- 5.3.0alpha2/Zend/zend_vm_execute.h":25843, 0x103ef740] 2 execute(0x106ba598, 0xd, 0x0, 0xc, 0x21000, 0x1000, 0xc, 0x106bab80) ["/opt/build/php-5.3.0alpha2/Zend/zend_vm_execute.h":104, 0x103a0418] 3 zend_execute_scripts(0x8, 0xd, 0x3, 0x0, 0x21000, 0x1000, 0xc, 0x106bab80) ["/opt/build/php-5.3.0alpha2/Zend/zend.c":1197, 0x10374a58] 4 php_execute_script(0x14a0, 0xd, 0x0, 0xc, 0x21000, 0x1000, 0xc, 0x106bab80) ["/opt/build/php-5.3.0alpha2/main/main.c":2074, 0x10313158] 5 main(0xf, 0x7fff2ef4, 0x0, 0xc, 0x21000, 0x1000, 0xc, 0x106bab80) ["/opt/build/php-5.3.0alpha2/sapi/cli/php_cli.c":1130, 0x103fed20] 6 __start() ["/xlv55/kudzu- apr12/work/irix/lib/libc/libc_n32_M4/csu/crt1text.s":177, 0x1004cb88] (dbx) [2008-09-14 02:44:32] neko at nekochan dot net The linked patch does allow the util.c compile to complete without error, but the build process halts with a bus error: Generating phar.php gmake: *** [ext/phar/phar.php] Bus error (core dumped) gmake: *** Deleting file `ext/phar/phar.php' [2008-09-13 21:40:02] [EMAIL PROTECTED] Thanks for the report. Would you try the patch against current ext/phar CVS of PHP_5_3 found at: http://pear.php.net/~greg/bug46072.patch.txt and report on whether it works? [2008-09-13 20:32:17] neko at nekochan dot net IRIX64 Kazehana 6.5 6.5.30f 07202013 IP35 MIPSpro Compilers: Version 7.4.4m 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/46072 -- Edit this bug report at http://bugs.php.net/?id=46072&edit=1
#46147 [Opn->Asn]: after stream seek, appending stream filter reads incorrect data
ID: 46147 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Assigned Bug Type: Streams related Operating System: n/a PHP Version: 5.3CVS-2008-09-22 (CVS) -Assigned To: +Assigned To: cellog Previous Comments: [2008-09-22 01:23:21] [EMAIL PROTECTED] Description: appending a stream filter to a stream that has already had data read into its buffer can cause unfiltered data to be read back in. This is because the data is written to writepos, but read from readpos, and so the buffer should be invalidated (writepos/readpos set to 0) prior to writing back the filtered data. This bug affects all PHP versions, and will be fixed in 5.2, 5.3, and 6.0 by me, I have a working patch ready to commit momentarily This bug was causing ext/phar/tests/zip/badalias.phpt to fail Reproduce code: --- execute within php5/ext/phar/tests/zip: Expected result: string(8) "hi/there" Actual result: -- string(8) "���/�H-J" -- Edit this bug report at http://bugs.php.net/?id=46147&edit=1
#46147 [Asn->Csd]: after stream seek, appending stream filter reads incorrect data
ID: 46147 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Assigned +Status: Closed Bug Type: Streams related Operating System: n/a PHP Version: 5.3CVS-2008-09-22 (CVS) Assigned To: cellog New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2008-09-22 01:23:21] [EMAIL PROTECTED] Description: appending a stream filter to a stream that has already had data read into its buffer can cause unfiltered data to be read back in. This is because the data is written to writepos, but read from readpos, and so the buffer should be invalidated (writepos/readpos set to 0) prior to writing back the filtered data. This bug affects all PHP versions, and will be fixed in 5.2, 5.3, and 6.0 by me, I have a working patch ready to commit momentarily This bug was causing ext/phar/tests/zip/badalias.phpt to fail Reproduce code: --- execute within php5/ext/phar/tests/zip: Expected result: string(8) "hi/there" Actual result: -- string(8) "���/�H-J" -- Edit this bug report at http://bugs.php.net/?id=46147&edit=1
#46178 [Opn->Asn]: memory leak in ext/phar
ID: 46178 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Assigned Bug Type: PHAR related Operating System: Mac OS X PHP Version: 5.3CVS-2008-09-26 (CVS) -Assigned To: +Assigned To: cellog Previous Comments: [2008-09-26 01:41:06] [EMAIL PROTECTED] Description: When running http://svn.pear.php.net/PEAR2/Pyrus/trunk/src/Pyrus/makepackage.php I get Greg-Beavers-monster:Pyrus Greg$ php -d phar.readonly=0 makepackage.php [Thu Sep 25 20:38:04 2008] Script: 'makepackage.php' /Users/Greg/Documents/php/php5/ext/phar/util.c(1524) : Freeing 0x00E41CD0 (54 bytes), script=makepackage.php Last leak repeated 5 times [Thu Sep 25 20:38:04 2008] Script: 'makepackage.php' /Users/Greg/Documents/php/php5/ext/phar/util.c(1521) : Freeing 0x00E2FCF8 (104 bytes), script=makepackage.php /Users/Greg/Documents/php/php5/Zend/zend_alloc.c(2391) : Actual location (location was relayed) Last leak repeated 5 times === Total 12 memory leaks detected === not sure why yet -- Edit this bug report at http://bugs.php.net/?id=46178&edit=1
#46178 [Asn->Csd]: memory leak in ext/phar
ID: 46178 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Assigned +Status: Closed Bug Type: PHAR related Operating System: Mac OS X PHP Version: 5.3CVS-2008-09-26 (CVS) Assigned To: cellog New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2008-09-26 01:41:06] [EMAIL PROTECTED] Description: When running http://svn.pear.php.net/PEAR2/Pyrus/trunk/src/Pyrus/makepackage.php I get Greg-Beavers-monster:Pyrus Greg$ php -d phar.readonly=0 makepackage.php [Thu Sep 25 20:38:04 2008] Script: 'makepackage.php' /Users/Greg/Documents/php/php5/ext/phar/util.c(1524) : Freeing 0x00E41CD0 (54 bytes), script=makepackage.php Last leak repeated 5 times [Thu Sep 25 20:38:04 2008] Script: 'makepackage.php' /Users/Greg/Documents/php/php5/ext/phar/util.c(1521) : Freeing 0x00E2FCF8 (104 bytes), script=makepackage.php /Users/Greg/Documents/php/php5/Zend/zend_alloc.c(2391) : Actual location (location was relayed) Last leak repeated 5 times === Total 12 memory leaks detected === not sure why yet -- Edit this bug report at http://bugs.php.net/?id=46178&edit=1
#46194 [Ctl->Fbk]: SIGSEGV when requested file is not found
ID: 46194
Updated by: [EMAIL PROTECTED]
Reported By: xuefer at gmail dot com
-Status: Critical
+Status: Feedback
Bug Type: PHAR related
Operating System: linux
PHP Version: 5.3CVS-2008-09-29 (CVS)
-Assigned To:
+Assigned To: cellog
New Comment:
Please try this simple patch found at
http://pear.php.net/~greg/fixbug46194.patch.txt
Index: ext/phar/phar.c
===
RCS file: /repository/php-src/ext/phar/phar.c,v
retrieving revision 1.370.2.45
diff -u -r1.370.2.45 phar.c
--- ext/phar/phar.c 13 Sep 2008 22:30:55 - 1.370.2.45
+++ ext/phar/phar.c 29 Sep 2008 13:00:22 -
@@ -3286,6 +3286,9 @@
int failed;
phar_archive_data *phar;
+ if (!file_handle || !file_handle->filename) {
+ return phar_orig_compile_file(file_handle, type
TSRMLS_CC);
+ }
if (strstr(file_handle->filename, ".phar") &&
!strstr(file_handle->filename, "://")) {
if (SUCCESS ==
phar_open_from_filename(file_handle->filename,
strlen(file_handle->filename), NULL, 0, 0, &phar, NULL TSRMLS_CC)) {
if (phar->is_zip || phar->is_tar) {
Previous Comments:
[2008-09-29 11:13:16] [EMAIL PROTECTED]
Seems to be PHAR related issue (once again) so the quick fix: disable
phar. This is quite critical bug..
[2008-09-29 03:13:05] xuefer at gmail dot com
Description:
i have setup lighttpd + fastcgi + php, it used to work with old php but
not with 5.3 (not sure about 5.2)
"localhost:1026" => (
"host" => "127.0.0.1", "port" => 2048,
"check-local" => "disable", "disable-time" => 1,
"broken-scriptfilename" => "enable",
),
be aware that it is check-local => disable, which mean lighttpd won't
check if the file is exists but will forward the request to php anyway
when i try to request a non existing file, php SIGSEGV
Program received signal SIGSEGV, Segmentation fault.
0x4b319f51 in strstr () from /lib/libc.so.6
(gdb) bt
#0 0x4b319f51 in strstr () from /lib/libc.so.6
#1 0x082292c1 in phar_compile_file (file_handle=0xbfec434c, type=8) at
/home/xuefer/src/php/php5/ext/phar/phar.c:3294
#2 0x0849d9b2 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /home/xuefer/src/php/php5/Zend/zend.c:1189
#3 0x08433dbb in php_execute_script (primary_file=0xbfec434c) at
/home/xuefer/src/php/php5/main/main.c:2080
#4 0x0852e362 in main (argc=3, argv=0xbfec44b4) at
/home/xuefer/src/php/php5/sapi/cgi/cgi_main.c:1980
(gdb) up
#1 0x082292c1 in phar_compile_file (file_handle=0xbfec434c, type=8) at
/home/xuefer/src/php/php5/ext/phar/phar.c:3294
3294if (strstr(file_handle->filename, ".phar") &&
!strstr(file_handle->filename, "://")) {
(gdb) p file_handle[0]
$2 = {type = ZEND_HANDLE_FILENAME, filename = 0x0, opened_path = 0x0,
handle = {fd = 0, fp = 0x0, stream = {handle = 0x0, isatty = 0,
mmap = {len = 0, pos = 1, map = 0x83f, buf = 0xb7f14878
"j®\t\b\020ii\r", old_handle = 0xb7f15000, old_closer = 0x807ba17},
reader = 0x4b2b9840, fsizer = 0x805f4a4, closer = 0x1}},
free_filename = 0 '\0'}
--
Edit this bug report at http://bugs.php.net/?id=46194&edit=1
#45907 [Asn]: undefined reference to `PHP_SHA512Init'
ID: 45907 Updated by: [EMAIL PROTECTED] Reported By: olivier at ajeux dot com Status: Assigned Bug Type: PHAR related Operating System: Linux i686 2.6.17 PHP Version: 5.3CVS-2008-09-29 (snap) Assigned To: cellog New Comment: I think we can fix this by using php_hash_sha256_ops and php_hash_sha512_ops to extract the actual address of PHP_SHA512Init and company, will try a fix later if I have time, otherwise tomorrow. Unless Steph beats me to it (check php_hash.h and hash_sha.c, searching for php_hash_sha256_ops to see what I'm talking about) Previous Comments: [2008-09-29 14:31:31] [EMAIL PROTECTED] Greg, please have a look. Phar should properly check for the existence of hash imo. [2008-09-29 12:44:24] olivier at ajeux dot com New configure/make without "--enable-hash=shared" (replaced with "--enable-hash"): OK Build complete. [2008-09-29 12:04:49] [EMAIL PROTECTED] Can someone please confirm that this occurs only when ext/hash is built as shared? [2008-09-29 10:36:04] olivier at ajeux dot com Tested again with php5.3 200809290830 Same bug. ext/phar/.libs/util.o: In function `phar_create_signature': /usr/src/php5.3-200809290830/ext/phar/util.c:2047: undefined reference to `PHP_SHA512Init' /usr/src/php5.3-200809290830/ext/phar/util.c:2050: undefined reference to `PHP_SHA512Update' /usr/src/php5.3-200809290830/ext/phar/util.c:2053: undefined reference to `PHP_SHA512Final' /usr/src/php5.3-200809290830/ext/phar/util.c:2062: undefined reference to `PHP_SHA256Init' /usr/src/php5.3-200809290830/ext/phar/util.c:2065: undefined reference to `PHP_SHA256Update' /usr/src/php5.3-200809290830/ext/phar/util.c:2068: undefined reference to `PHP_SHA256Final' ext/phar/.libs/util.o: In function `phar_verify_signature': /usr/src/php5.3-200809290830/ext/phar/util.c:1916: undefined reference to `PHP_SHA256Init' /usr/src/php5.3-200809290830/ext/phar/util.c:1926: undefined reference to `PHP_SHA256Update' /usr/src/php5.3-200809290830/ext/phar/util.c:1883: undefined reference to `PHP_SHA512Init' /usr/src/php5.3-200809290830/ext/phar/util.c:1893: undefined reference to `PHP_SHA512Update' /usr/src/php5.3-200809290830/ext/phar/util.c:1900: undefined reference to `PHP_SHA512Final' /usr/src/php5.3-200809290830/ext/phar/util.c:1933: undefined reference to `PHP_SHA256Final' collect2: ld returned 1 exit status make: *** [sapi/cgi/php-cgi] Error 1 [2008-09-06 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". 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/45907 -- Edit this bug report at http://bugs.php.net/?id=45907&edit=1
#45907 [Asn]: undefined reference to `PHP_SHA512Init'
ID: 45907 Updated by: [EMAIL PROTECTED] Reported By: olivier at ajeux dot com Status: Assigned Bug Type: PHAR related Operating System: Linux i686 2.6.17 PHP Version: 5.3CVS-2008-09-29 (snap) Assigned To: cellog New Comment: another update: this should be completely unnecessary as we include ext/hash/php_hash_sha.h which has: PHP_HASH_API void PHP_SHA256Init(PHP_SHA256_CTX *); all defined properly I wonder if building hash shared prevents the proper export of this function? Previous Comments: [2008-09-29 23:57:03] [EMAIL PROTECTED] I think we can fix this by using php_hash_sha256_ops and php_hash_sha512_ops to extract the actual address of PHP_SHA512Init and company, will try a fix later if I have time, otherwise tomorrow. Unless Steph beats me to it (check php_hash.h and hash_sha.c, searching for php_hash_sha256_ops to see what I'm talking about) [2008-09-29 14:31:31] [EMAIL PROTECTED] Greg, please have a look. Phar should properly check for the existence of hash imo. [2008-09-29 12:44:24] olivier at ajeux dot com New configure/make without "--enable-hash=shared" (replaced with "--enable-hash"): OK Build complete. [2008-09-29 12:04:49] [EMAIL PROTECTED] Can someone please confirm that this occurs only when ext/hash is built as shared? [2008-09-29 10:36:04] olivier at ajeux dot com Tested again with php5.3 200809290830 Same bug. ext/phar/.libs/util.o: In function `phar_create_signature': /usr/src/php5.3-200809290830/ext/phar/util.c:2047: undefined reference to `PHP_SHA512Init' /usr/src/php5.3-200809290830/ext/phar/util.c:2050: undefined reference to `PHP_SHA512Update' /usr/src/php5.3-200809290830/ext/phar/util.c:2053: undefined reference to `PHP_SHA512Final' /usr/src/php5.3-200809290830/ext/phar/util.c:2062: undefined reference to `PHP_SHA256Init' /usr/src/php5.3-200809290830/ext/phar/util.c:2065: undefined reference to `PHP_SHA256Update' /usr/src/php5.3-200809290830/ext/phar/util.c:2068: undefined reference to `PHP_SHA256Final' ext/phar/.libs/util.o: In function `phar_verify_signature': /usr/src/php5.3-200809290830/ext/phar/util.c:1916: undefined reference to `PHP_SHA256Init' /usr/src/php5.3-200809290830/ext/phar/util.c:1926: undefined reference to `PHP_SHA256Update' /usr/src/php5.3-200809290830/ext/phar/util.c:1883: undefined reference to `PHP_SHA512Init' /usr/src/php5.3-200809290830/ext/phar/util.c:1893: undefined reference to `PHP_SHA512Update' /usr/src/php5.3-200809290830/ext/phar/util.c:1900: undefined reference to `PHP_SHA512Final' /usr/src/php5.3-200809290830/ext/phar/util.c:1933: undefined reference to `PHP_SHA256Final' collect2: ld returned 1 exit status make: *** [sapi/cgi/php-cgi] Error 1 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/45907 -- Edit this bug report at http://bugs.php.net/?id=45907&edit=1
#46194 [Opn->Csd]: SIGSEGV when requested file is not found
ID: 46194
Updated by: [EMAIL PROTECTED]
Reported By: xuefer at gmail dot com
-Status: Open
+Status: Closed
Bug Type: PHAR related
Operating System: linux
PHP Version: 5.3CVS-2008-09-29 (CVS)
Assigned To: cellog
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
I'm marking this bug closed, as phar now handles stupid input
correctly. Please open another bug in CGI/CLI related category for the
other problem.
Previous Comments:
[2008-09-30 02:10:56] xuefer at gmail dot com
ok, it seems fixed with your patch, but i don't think it right. why
filename can be NULL before it is past to compile file?
with php5.2-CVS cgi-fcgi:
No input file specified.
with php5.3-CVS and phar patch (or disable phar)
Fatal error: Unknown: Failed opening required '' (include_path='.:') in
Unknown on line 0
something changed in cgi, many zend extensions might be affected
$ diff ~/src/php/php5.2/sapi/cgi/cgi_main.c
~/src/php/php5/sapi/cgi/cgi_main.c
yeah... there are big changes
$ diff -u ~/src/php/php5.2/sapi/cgi/cgi_main.c
~/src/php/php5/sapi/cgi/cgi_main.c |grep 'No input file specified' -C 5
+ SG(sapi_headers).http_response_code = 403;
+ PUTS("Access denied.\n");
} else {
- len += strlen(argv[i]);
+ SG(sapi_headers).http_response_code = 404;
+ PUTS("No input file specified.\n");
+ }
+ /* we want to serve more requests if this is
fastcgi
+ so cleanup and continue, request shutdown is
+ handled later */
+ if (fastcgi) {
--
- if (errno == EACCES) {
- SG(sapi_headers).http_response_code = 403;
- PUTS("Access denied.\n");
- } else {
- SG(sapi_headers).http_response_code = 404;
- PUTS("No input file specified.\n");
- }
-#if PHP_FASTCGI
- /* we want to serve more requests if this is fastcgi
- so cleanup and continue, request shutdown is
- handled later */
i'm not sure when will 5.3 cgi-fcgi prints out "No input file
specified" which used to be print by 5.2, are you?
summary:
1. "Fatal error" just does not make sense here. it should be legal to
pass any request including which might cause "404 File not found", from
the webserver to php cgi-fcgi backend, and php should issue 404 error
like 5.2 does
otherwise i have to set up
a. webserver(frontend) on server1 -> webserver + mod_php(backend) on
server2, or
b. webserver(frontend, check-local=disabled) on server 1 ->
webserver(backend, check-local=enabled to produce 404) -> php cgi-fcgi
(backend)
2. passing file_handle == NULL || file_handle->filename == NULL does
not make sense, it breaks zend extensions that hook zend_compile_file,
like phar, apc, ZendOptimizer, XCache, Xdebug, eaccelerator,
blahblah...
as you assigned it to phar category, i ask your advise
[2008-09-29 13:02:10] [EMAIL PROTECTED]
Please try this simple patch found at
http://pear.php.net/~greg/fixbug46194.patch.txt
Index: ext/phar/phar.c
===
RCS file: /repository/php-src/ext/phar/phar.c,v
retrieving revision 1.370.2.45
diff -u -r1.370.2.45 phar.c
--- ext/phar/phar.c 13 Sep 2008 22:30:55 - 1.370.2.45
+++ ext/phar/phar.c 29 Sep 2008 13:00:22 -
@@ -3286,6 +3286,9 @@
int failed;
phar_archive_data *phar;
+ if (!file_handle || !file_handle->filename) {
+ return phar_orig_compile_file(file_handle, type
TSRMLS_CC);
+ }
if (strstr(file_handle->filename, ".phar") &&
!strstr(file_handle->filename, "://")) {
if (SUCCESS ==
phar_open_from_filename(file_handle->filename,
strlen(file_handle->filename), NULL, 0, 0, &phar, NULL TSRMLS_CC)) {
if (phar->is_zip || phar->is_tar) {
[2008-09-29 11:13:16] [EMAIL PROTECTED]
Seems to be PHAR related issue (once again) so the quick fix: disable
phar. This is quite critical bug..
[2008-09-29 03:13:05] xuefer at gmail dot com
Description:
i have setup lighttpd + fastcgi + php, it used to work with old php but
n
#45907 [Asn->Ver]: undefined reference to `PHP_SHA512Init'
ID: 45907 Updated by: [EMAIL PROTECTED] Reported By: olivier at ajeux dot com -Status: Assigned +Status: Verified Bug Type: PHAR related Operating System: Linux i686 2.6.17 PHP Version: 5.3CVS-2008-09-29 (snap) Assigned To: cellog Previous Comments: [2008-09-30 11:25:29] [EMAIL PROTECTED] Sorry Greg, would if I could but still have no way to build 5.3. I'll poke Marcus. [2008-09-30 00:02:30] [EMAIL PROTECTED] another update: this should be completely unnecessary as we include ext/hash/php_hash_sha.h which has: PHP_HASH_API void PHP_SHA256Init(PHP_SHA256_CTX *); all defined properly I wonder if building hash shared prevents the proper export of this function? [2008-09-29 23:57:03] [EMAIL PROTECTED] I think we can fix this by using php_hash_sha256_ops and php_hash_sha512_ops to extract the actual address of PHP_SHA512Init and company, will try a fix later if I have time, otherwise tomorrow. Unless Steph beats me to it (check php_hash.h and hash_sha.c, searching for php_hash_sha256_ops to see what I'm talking about) [2008-09-29 14:31:31] [EMAIL PROTECTED] Greg, please have a look. Phar should properly check for the existence of hash imo. [2008-09-29 12:44:24] olivier at ajeux dot com New configure/make without "--enable-hash=shared" (replaced with "--enable-hash"): OK Build complete. 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/45907 -- Edit this bug report at http://bugs.php.net/?id=45907&edit=1
#45907 [Ver->Csd]: undefined reference to `PHP_SHA512Init'
ID: 45907 Updated by: [EMAIL PROTECTED] Reported By: olivier at ajeux dot com -Status: Verified +Status: Closed Bug Type: PHAR related Operating System: Linux i686 2.6.17 PHP Version: 5.3CVS-2008-09-29 (snap) Assigned To: cellog New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Unfortunately, the fix is removing support for ext/hash if it is built shared. This could be revisited in a future release, but would involve extensive code changes to call the PHP versions of hash_init() rather than the C versions, something I don't want to do until 5.3.0 is released. Previous Comments: [2008-09-30 11:25:29] [EMAIL PROTECTED] Sorry Greg, would if I could but still have no way to build 5.3. I'll poke Marcus. [2008-09-30 00:02:30] [EMAIL PROTECTED] another update: this should be completely unnecessary as we include ext/hash/php_hash_sha.h which has: PHP_HASH_API void PHP_SHA256Init(PHP_SHA256_CTX *); all defined properly I wonder if building hash shared prevents the proper export of this function? [2008-09-29 23:57:03] [EMAIL PROTECTED] I think we can fix this by using php_hash_sha256_ops and php_hash_sha512_ops to extract the actual address of PHP_SHA512Init and company, will try a fix later if I have time, otherwise tomorrow. Unless Steph beats me to it (check php_hash.h and hash_sha.c, searching for php_hash_sha256_ops to see what I'm talking about) [2008-09-29 14:31:31] [EMAIL PROTECTED] Greg, please have a look. Phar should properly check for the existence of hash imo. [2008-09-29 12:44:24] olivier at ajeux dot com New configure/make without "--enable-hash=shared" (replaced with "--enable-hash"): OK Build complete. 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/45907 -- Edit this bug report at http://bugs.php.net/?id=45907&edit=1
#46026 [Opn->Ver]: bz2_decompress_filter tries to decompress after end of stream
ID: 46026
Updated by: [EMAIL PROTECTED]
Reported By: Keisial at gmail dot com
-Status: Open
+Status: Verified
Bug Type: Bzip2 Related
Operating System: *
PHP Version: 5.2CVS-2008-09-08 (snap)
-Assigned To:
+Assigned To: cellog
New Comment:
this same bug applies to zlib stream filter, and also happens simply
when trying to read from a filtered stream that contains a limited
amount of compressed data (as in a zip archive with a bz2-compressed
file), as php_stream_fill_read_buffer reads in maxlen data, triggering
the problem you found. I'll try to get this fixed up and put in a few
tests
Previous Comments:
[2008-09-19 16:47:15] Keisial at gmail dot com
Ok, I have implemented a fix.
Patch: http://pastebin.com/f24d58100
Patch ignoring whitespaces: http://pastebin.com/fb084a7b
When adding a filter to a stream, "bzip2.decompress", $parameters only
indicated if bzlib should use the alternative decompression algorithm
which uses less memory but at the cost of decompressing more slowly,
either as a boolean or as an array("small"=>value). I have extended the
array syntax to also allow a 'concatenated' parameter.
By default, bzip2.decompress filter won't process any data after it has
reached and end-of-stream. However, if you provide
array("concatenated"=>true) it will continue reading as if it has
another bzip2 stream concatenated, just as bzip2 does.
In the future, it would be nice to be able to apply a bzip2.decompress,
read the data, remove the filter, and read non-bzip data appended, but
the stream_filter system would need to be extended to support that.
Additionally, if there is a decompression error, it will show a
warning. Also, bzip2 internal buffers will now be allocated later and
freed sooner.
[2008-09-08 22:58:41] Keisial at gmail dot com
Description:
If the input is larger than the bzip2 stream, bz2_decompress_filter
tries to continue decompressing after it has received a BZ_STREAM_END,
so bzlib returns BZ_SEQUENCE_ERROR and the stream filter finalises with
PSFS_ERR_FATAL, getting no output.
Reproduce code:
---
bz2Decompress.php:
$ echo 'Hello world' > hello.txt
$ bzip2 hello.txt
$ php bz2Decompress.php hello.txt.bz2
Hello world
$ echo '!' >> hello.txt.bz2
$ php bz2Decompress.php hello.txt.bz2
/* No output */
Expected result:
At least the correctly read data should be returned.
Two things can be done on receiving a BZ_STREAM_END:
-Setting an EOF flag and remove any further incoming data (allow to
continue reading if the filter is removed?).
-Reinitialising the decompressing library (approach of the bzip2
utility) so concatenated bzip2 streams can be unbzipped as the
concatenation of its output.
--
Edit this bug report at http://bugs.php.net/?id=46026&edit=1
#46026 [Ver]: bz2_decompress_filter tries to decompress after end of stream
ID: 46026
Updated by: [EMAIL PROTECTED]
Reported By: Keisial at gmail dot com
Status: Verified
Bug Type: Bzip2 Related
Operating System: *
PHP Version: 5.2CVS-2008-09-08 (snap)
Assigned To: cellog
New Comment:
In the future, please follow 2 important elements of the coding
standards:
1) use tabs instead of spaces
2) always use {} around if/else blocks
I had to waste 15 minutes just getting the patch formatted correctly
before I could even begin testing it. I don't like wasting time.
Previous Comments:
[2008-10-11 17:12:10] [EMAIL PROTECTED]
this same bug applies to zlib stream filter, and also happens simply
when trying to read from a filtered stream that contains a limited
amount of compressed data (as in a zip archive with a bz2-compressed
file), as php_stream_fill_read_buffer reads in maxlen data, triggering
the problem you found. I'll try to get this fixed up and put in a few
tests
[2008-09-19 16:47:15] Keisial at gmail dot com
Ok, I have implemented a fix.
Patch: http://pastebin.com/f24d58100
Patch ignoring whitespaces: http://pastebin.com/fb084a7b
When adding a filter to a stream, "bzip2.decompress", $parameters only
indicated if bzlib should use the alternative decompression algorithm
which uses less memory but at the cost of decompressing more slowly,
either as a boolean or as an array("small"=>value). I have extended the
array syntax to also allow a 'concatenated' parameter.
By default, bzip2.decompress filter won't process any data after it has
reached and end-of-stream. However, if you provide
array("concatenated"=>true) it will continue reading as if it has
another bzip2 stream concatenated, just as bzip2 does.
In the future, it would be nice to be able to apply a bzip2.decompress,
read the data, remove the filter, and read non-bzip data appended, but
the stream_filter system would need to be extended to support that.
Additionally, if there is a decompression error, it will show a
warning. Also, bzip2 internal buffers will now be allocated later and
freed sooner.
[2008-09-08 22:58:41] Keisial at gmail dot com
Description:
If the input is larger than the bzip2 stream, bz2_decompress_filter
tries to continue decompressing after it has received a BZ_STREAM_END,
so bzlib returns BZ_SEQUENCE_ERROR and the stream filter finalises with
PSFS_ERR_FATAL, getting no output.
Reproduce code:
---
bz2Decompress.php:
$ echo 'Hello world' > hello.txt
$ bzip2 hello.txt
$ php bz2Decompress.php hello.txt.bz2
Hello world
$ echo '!' >> hello.txt.bz2
$ php bz2Decompress.php hello.txt.bz2
/* No output */
Expected result:
At least the correctly read data should be returned.
Two things can be done on receiving a BZ_STREAM_END:
-Setting an EOF flag and remove any further incoming data (allow to
continue reading if the filter is removed?).
-Reinitialising the decompressing library (approach of the bzip2
utility) so concatenated bzip2 streams can be unbzipped as the
concatenation of its output.
--
Edit this bug report at http://bugs.php.net/?id=46026&edit=1
#46026 [Ver]: bz2.decompress/zlib.inflate filter tries to decompress after end of stream
ID: 46026
Updated by: [EMAIL PROTECTED]
-Summary: bz2_decompress_filter tries to decompress after end of
stream
Reported By: Keisial at gmail dot com
Status: Verified
Bug Type: Bzip2 Related
Operating System: *
PHP Version: 5.2CVS-2008-09-08 (snap)
Assigned To: cellog
New Comment:
changing summary to reflect addition of zlib problem
Previous Comments:
[2008-10-11 18:25:14] [EMAIL PROTECTED]
In the future, please follow 2 important elements of the coding
standards:
1) use tabs instead of spaces
2) always use {} around if/else blocks
I had to waste 15 minutes just getting the patch formatted correctly
before I could even begin testing it. I don't like wasting time.
[2008-10-11 17:12:10] [EMAIL PROTECTED]
this same bug applies to zlib stream filter, and also happens simply
when trying to read from a filtered stream that contains a limited
amount of compressed data (as in a zip archive with a bz2-compressed
file), as php_stream_fill_read_buffer reads in maxlen data, triggering
the problem you found. I'll try to get this fixed up and put in a few
tests
[2008-09-19 16:47:15] Keisial at gmail dot com
Ok, I have implemented a fix.
Patch: http://pastebin.com/f24d58100
Patch ignoring whitespaces: http://pastebin.com/fb084a7b
When adding a filter to a stream, "bzip2.decompress", $parameters only
indicated if bzlib should use the alternative decompression algorithm
which uses less memory but at the cost of decompressing more slowly,
either as a boolean or as an array("small"=>value). I have extended the
array syntax to also allow a 'concatenated' parameter.
By default, bzip2.decompress filter won't process any data after it has
reached and end-of-stream. However, if you provide
array("concatenated"=>true) it will continue reading as if it has
another bzip2 stream concatenated, just as bzip2 does.
In the future, it would be nice to be able to apply a bzip2.decompress,
read the data, remove the filter, and read non-bzip data appended, but
the stream_filter system would need to be extended to support that.
Additionally, if there is a decompression error, it will show a
warning. Also, bzip2 internal buffers will now be allocated later and
freed sooner.
[2008-09-08 22:58:41] Keisial at gmail dot com
Description:
If the input is larger than the bzip2 stream, bz2_decompress_filter
tries to continue decompressing after it has received a BZ_STREAM_END,
so bzlib returns BZ_SEQUENCE_ERROR and the stream filter finalises with
PSFS_ERR_FATAL, getting no output.
Reproduce code:
---
bz2Decompress.php:
$ echo 'Hello world' > hello.txt
$ bzip2 hello.txt
$ php bz2Decompress.php hello.txt.bz2
Hello world
$ echo '!' >> hello.txt.bz2
$ php bz2Decompress.php hello.txt.bz2
/* No output */
Expected result:
At least the correctly read data should be returned.
Two things can be done on receiving a BZ_STREAM_END:
-Setting an EOF flag and remove any further incoming data (allow to
continue reading if the filter is removed?).
-Reinitialising the decompressing library (approach of the bzip2
utility) so concatenated bzip2 streams can be unbzipped as the
concatenation of its output.
--
Edit this bug report at http://bugs.php.net/?id=46026&edit=1
#46026 [Ver->Csd]: bz2.decompress/zlib.inflate filter tries to decompress after end of stream
ID: 46026
Updated by: [EMAIL PROTECTED]
Reported By: Keisial at gmail dot com
-Status: Verified
+Status: Closed
Bug Type: Bzip2 Related
Operating System: *
PHP Version: 5.2CVS-2008-09-08 (snap)
Assigned To: cellog
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
fixed in PHP 5.2, 5.3, 6.0. Concatenation was only added in PHP 5.3
and 6.0, as new features cannot be added to PHP 5.2
Previous Comments:
[2008-10-11 19:08:35] [EMAIL PROTECTED]
changing summary to reflect addition of zlib problem
[2008-10-11 18:25:14] [EMAIL PROTECTED]
In the future, please follow 2 important elements of the coding
standards:
1) use tabs instead of spaces
2) always use {} around if/else blocks
I had to waste 15 minutes just getting the patch formatted correctly
before I could even begin testing it. I don't like wasting time.
[2008-10-11 17:12:10] [EMAIL PROTECTED]
this same bug applies to zlib stream filter, and also happens simply
when trying to read from a filtered stream that contains a limited
amount of compressed data (as in a zip archive with a bz2-compressed
file), as php_stream_fill_read_buffer reads in maxlen data, triggering
the problem you found. I'll try to get this fixed up and put in a few
tests
[2008-09-19 16:47:15] Keisial at gmail dot com
Ok, I have implemented a fix.
Patch: http://pastebin.com/f24d58100
Patch ignoring whitespaces: http://pastebin.com/fb084a7b
When adding a filter to a stream, "bzip2.decompress", $parameters only
indicated if bzlib should use the alternative decompression algorithm
which uses less memory but at the cost of decompressing more slowly,
either as a boolean or as an array("small"=>value). I have extended the
array syntax to also allow a 'concatenated' parameter.
By default, bzip2.decompress filter won't process any data after it has
reached and end-of-stream. However, if you provide
array("concatenated"=>true) it will continue reading as if it has
another bzip2 stream concatenated, just as bzip2 does.
In the future, it would be nice to be able to apply a bzip2.decompress,
read the data, remove the filter, and read non-bzip data appended, but
the stream_filter system would need to be extended to support that.
Additionally, if there is a decompression error, it will show a
warning. Also, bzip2 internal buffers will now be allocated later and
freed sooner.
[2008-09-08 22:58:41] Keisial at gmail dot com
Description:
If the input is larger than the bzip2 stream, bz2_decompress_filter
tries to continue decompressing after it has received a BZ_STREAM_END,
so bzlib returns BZ_SEQUENCE_ERROR and the stream filter finalises with
PSFS_ERR_FATAL, getting no output.
Reproduce code:
---
bz2Decompress.php:
$ echo 'Hello world' > hello.txt
$ bzip2 hello.txt
$ php bz2Decompress.php hello.txt.bz2
Hello world
$ echo '!' >> hello.txt.bz2
$ php bz2Decompress.php hello.txt.bz2
/* No output */
Expected result:
At least the correctly read data should be returned.
Two things can be done on receiving a BZ_STREAM_END:
-Setting an EOF flag and remove any further incoming data (allow to
continue reading if the filter is removed?).
-Reinitialising the decompressing library (approach of the bzip2
utility) so concatenated bzip2 streams can be unbzipped as the
concatenation of its output.
--
Edit this bug report at http://bugs.php.net/?id=46026&edit=1
#46310 [Opn->Bgs]: Namespace resolution is not done when creating objects of a variable class name
ID: 46310 Updated by: [EMAIL PROTECTED] Reported By: benno at transmog dot com dot au -Status: Open +Status: Bogus Bug Type: Scripting Engine problem Operating System: Linux, but probably irrelevant PHP Version: 5.3.0alpha2 New Comment: When you do this code: PHP automatically "expands" it to: The same is true at definition time. When you do this code: PHP automatically expands it to: In other words, if you want to access "ns::classname" with a dynamic call, you'll need to perform this expansion manually: $a = __NAMESPACE__ . '::' . $classname; return new $a(); $a = "testclass"; $b = new $a(); will always refer to the globally un-namespaced: Previous Comments: [2008-10-16 01:28:42] benno at transmog dot com dot au Description: Suppose you have a namespace that contains: - a function that has "new $blah ();" - the class $blah The instantiation will generate a fatal error if the namespace is not explicitly specified. I assume then that namespace resolution is not done when instantiating an object of a variable class name. This is similar to Bug #45197, but I don't think it's quite the same thing. Classes must know, at runtime, which namespace they belong to for the runtime namespace resolution described in the manual to work - http://php.net/manual/en/language.namespaces.definition.php Please advise either way. Reproduce code: --- Classes (defined in namespace ns): http://transmog.com.au/php/ns.phps Test suite: http://transmog.com.au/php/test.phps Expected result: a: ok b: ok c: ok Actual result: -- a: ok b: ok c: Fatal error: Class 'testclass' not found in /var/www/ns.php on line 7 -- Edit this bug report at http://bugs.php.net/?id=46310&edit=1
#44827 [Asn]: define('::') can be defined
ID: 44827
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Assigned
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 5.2.6
Assigned To: iliaa
New Comment:
now that namespace separator will be \, the fix is simple: grep for
"::" and fail if a user tries to do it.
Previous Comments:
[2008-04-25 10:11:39] [EMAIL PROTECTED]
As a note to this while we're at define().
define() also seems to ignore if you declare a class constant like:
define('test::c', 'test');
Both with and without having a class called 'test' passes this, testing
without the class 'test' like:
var_dump(test::c);
Will result in a fatal error: class 'test' not found. Testing it with a
class called 'test' will issue a fatal error: undefined class constant
'c'.
If the class 'test' already have a constant called 'c' define() will
still ignore it and var_dump() will return the real value of test::c.
[2008-04-25 10:01:38] [EMAIL PROTECTED]
Description:
PHP (5.2.5) allows you to define '::' as a constant without issuing an
E_WARNING, below examples will demonstrate it.
The constant() function will issue an fatal error when recieving '::'
as constant name:
Fatal error: Class '' not found in C:\webserver\www\gd\gd.php on line
91
Which might also be wrong or confusing to the programmer
Reproduce code:
---
Expected result:
A fatal error for each of the calls:
Fatal error: Invalid constant name in test.php on line 2
Fatal error: Invalid constant name in test.php on line 3
Actual result:
--
Fatal error: Class '' not found in C:\webserver\www\gd\gd.php on line
91
None warning or fatal error for define()...
--
Edit this bug report at http://bugs.php.net/?id=44827&edit=1
#43857 [Asn]: --program-suffix not always reflected everywhere
ID: 43857 Updated by: [EMAIL PROTECTED] Reported By: bjoern at xrow dot de Status: Assigned Bug Type: Compile Failure Operating System: linux PHP Version: 5.2.6 Assigned To: cellog New Comment: This is a very difficult problem to solve for all cases. Most fixes I've tried thus far break many other cases. For instance, the calls to "phpize" and "php-config" are done inside the source of PEAR/Builder.php. If we manually modify the source of PEAR/Builder.php, the instant a user calls "pear config-set php_bin /path/to/some/other/php" the whole thing breaks. So, what I am going to do is provide two new options to the "install" "upgrade" and "upgrade-all" commands which are designed to account for --program-suffix or --program-prefix being used, --program-suffix and --program-prefix which will programmatically append/prepend for the phpize/php-config commands. I'll also provide 2 new config variables that can be set to make this automatic. This new feature will not appear until PEAR 1.8.0 is released, which will hopefully be before PHP 5.3.0 Previous Comments: [2008-11-02 13:25:48] [EMAIL PROTECTED] Greg, if you're the wrong person this is assigned to, please assign to the right one. If you are the right person: FIX IT. [2008-02-18 11:05:10] [EMAIL PROTECTED] This is actually PEAR bug, but as it's quite tightly connected to PHP we can keep this here. I don't know where that pecl script is and I don't want to touch it either since there's some new installer cooking..so Greg, can you please fix it to use the provided php-config instead? (note: php-config also might use the --program-prefix and --program-suffix options!) [2008-01-15 17:02:35] bjoern at xrow dot de Description: Hi, I used ./configure --program-suffix=5 --prefix=/usr/local/php5 when i try to run stuff like bin/pecl it fails since the script created by the installer didn`t take the suffix in account for pecl - lines from bin/pecl if test "/usr/local/php5/bin/php" = '@'php_bin'@'; then PHP=php else PHP="/usr/local/php5/bin/php" fi after fixing that manually i tryied it again and it seems also the correct path to phpize is missing with is phpize5 /usr/local/php5/bin/pecl install xdebug ^[[A^[[Adownloading xdebug-2.0.2.tgz ... Starting to download xdebug-2.0.2.tgz (279,621 bytes) .done: 279,621 bytes 65 source files, building running: phpize Configuring for: PHP Api Version: 20020918 Zend Module Api No: 20020429 Zend Extension Api No: 20050606 ERROR: `phpize' failed -- Edit this bug report at http://bugs.php.net/?id=43857&edit=1
#43857 [Asn]: --program-suffix not always reflected everywhere
ID: 43857 Updated by: [EMAIL PROTECTED] Reported By: bjoern at xrow dot de Status: Assigned Bug Type: Compile Failure Operating System: linux PHP Version: 5.2.6 Assigned To: cellog New Comment: this is now fixed in PEAR CVS, but I will keep this open until the install phar in php's source is updated Previous Comments: [2008-11-29 03:43:14] [EMAIL PROTECTED] This is a very difficult problem to solve for all cases. Most fixes I've tried thus far break many other cases. For instance, the calls to "phpize" and "php-config" are done inside the source of PEAR/Builder.php. If we manually modify the source of PEAR/Builder.php, the instant a user calls "pear config-set php_bin /path/to/some/other/php" the whole thing breaks. So, what I am going to do is provide two new options to the "install" "upgrade" and "upgrade-all" commands which are designed to account for --program-suffix or --program-prefix being used, --program-suffix and --program-prefix which will programmatically append/prepend for the phpize/php-config commands. I'll also provide 2 new config variables that can be set to make this automatic. This new feature will not appear until PEAR 1.8.0 is released, which will hopefully be before PHP 5.3.0 [2008-11-02 13:25:48] [EMAIL PROTECTED] Greg, if you're the wrong person this is assigned to, please assign to the right one. If you are the right person: FIX IT. [2008-02-18 11:05:10] [EMAIL PROTECTED] This is actually PEAR bug, but as it's quite tightly connected to PHP we can keep this here. I don't know where that pecl script is and I don't want to touch it either since there's some new installer cooking..so Greg, can you please fix it to use the provided php-config instead? (note: php-config also might use the --program-prefix and --program-suffix options!) [2008-01-15 17:02:35] bjoern at xrow dot de Description: Hi, I used ./configure --program-suffix=5 --prefix=/usr/local/php5 when i try to run stuff like bin/pecl it fails since the script created by the installer didn`t take the suffix in account for pecl - lines from bin/pecl if test "/usr/local/php5/bin/php" = '@'php_bin'@'; then PHP=php else PHP="/usr/local/php5/bin/php" fi after fixing that manually i tryied it again and it seems also the correct path to phpize is missing with is phpize5 /usr/local/php5/bin/pecl install xdebug ^[[A^[[Adownloading xdebug-2.0.2.tgz ... Starting to download xdebug-2.0.2.tgz (279,621 bytes) .done: 279,621 bytes 65 source files, building running: phpize Configuring for: PHP Api Version: 20020918 Zend Module Api No: 20020429 Zend Extension Api No: 20050606 ERROR: `phpize' failed -- Edit this bug report at http://bugs.php.net/?id=43857&edit=1
#46680 [Asn]: Files created in wrong directory (include path vs current working directory)
ID: 46680
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Assigned
Bug Type: Filesystem function related
Operating System: *
PHP Version: 5.3CVS-2008-11-26 (snap)
-Assigned To: cellog
+Assigned To: dmitry
New Comment:
first of all, the change from PHP 5.2 is the addition of
php_resolve_path, which is Dmitry's work. Second of all, most of the
tests are checking for *broken* behavior which is fixed in PHP 5.3.
file_put_contents('blah', 'whatever', FILE_USE_INCLUDE_PATH);
should not arbitrarily create the "blah" file in the first element of
the include_path. file_get_contents('blah', true) does not work this
way, it scans include_path for the file, and if not found, it tries as a
fallback to search in the current directory, and only then does it fail.
This is correct behavior - the file should be created in the current
directory if it does not already exist in the include_path. The
addition of the fallback was added in PHP 5.3, it seems.
The fopen tests also assume that fopen() with include_path parameter
for read will not check the current directory.
So we have a larger dilemma - the default include_path has the current
directory as the first element, and thus the functions that use
include_path for writing were acting as if they were doing the right
thing, when in fact they were making an arbitrary assumption about where
to put things.
None of this behavior is documented, so it is questionable what is the
right way to do things.
In other words, Jani is wrong to imply that anything I did caused the
problem, and should probably apologize, but I won't hold my breath.
I'm assigning to Dmitry under the assumption he will want to do the
ultimate commit, but will raise this on internals@
Previous Comments:
[2008-12-09 13:31:06] [EMAIL PROTECTED]
Looks like all those changes Greg did broke this (too).
[2008-11-26 18:02:36] [EMAIL PROTECTED]
These tests are also now checked into 6.0.
[2008-11-26 10:15:48] [EMAIL PROTECTED]
Description:
The following tests were ported from 5.2.X and do not work as
expected on 5.3. The tests all create a test file and expect it to be
created in an include directory. Instead it looks like the file is
being created elsewhere This particularly affects file_put_contents()
with the FILE_USE_INCLUDE_PATH flag set, and also fopen(...).
Reproduce code:
---
See the tests now checked into CVS:
ext/standard/tests/file/file_put_contents_variation4.phpt
ext/standard/tests/file/file_put_contents_variation5.phpt
ext/standard/tests/file/file_put_contents_variation6.phpt
ext/standard/tests/file/fopen_variation5.phpt
ext/standard/tests/file/fopen_variation7.phpt
ext/standard/tests/file/fopen_variation8.phpt
ext/standard/tests/file/fopen_variation9.phpt
ext/standard/tests/file/fopen_variation12.phpt
ext/standard/tests/file/fopen_variation16.phpt
ext/standard/tests/file/fopen_variation17.phpt
Expected result:
See expected output in the PHPTs.
Actual result:
--
See the test results from running the PHPTs.
--
Edit this bug report at http://bugs.php.net/?id=46680&edit=1
#46939 [Asn->Bgs]: fatal error on new Phar
ID: 46939
Updated by: cel...@php.net
Reported By: lunter at interia dot pl
-Status: Assigned
+Status: Bogus
Bug Type: PHAR related
Operating System: WinXP
PHP Version: 5.3.0alpha3
Assigned To: cellog
New Comment:
This is an intended side effect. .zip and .tar-based phar archives
will not work if .phar is not in the name, and so allowing creation of
them is not allowed. If we allowed this for phar-based phar archives,
it would be inconsistent and confusing.
We are, of course, in alpha stage, but it would be a major change to do
this.
What is the workaround?
blah.phar.php or blah.phar.php5 or blah.phar.php6 all work. If you
would like to discuss alternatives, I am happy to do so, either on
intern...@lists.php.net or through email at cel...@php.net
Previous Comments:
[2008-12-24 16:06:46] lunter at interia dot pl
Description:
This PHP code triggers:
Fatal error: Uncaught exception 'UnexpectedValueException' with message
'Cannot create phar 'core.php', file extension (or combination) not
recognised' in C:\htdocs\a\!phar2.php:2 Stack trace: #0
C:\htdocs\a\!phar2.php(2): Phar->__construct('core.php') #1 {main}
thrown in C:\htdocs\a\!phar2.php on line 2
but *.php files work as good as *.phar
when using:
1) http://web.com/file.php/index.php
2) require('phar://file.php');
Reproduce code:
---
Expected result:
NO Fatal error wheh extension is *.php (*.php5, *.php6)
Actual result:
--
Fatal error wheh extension is *.php (*.php5, *.php6)
--
Edit this bug report at http://bugs.php.net/?id=46939&edit=1
#46979 [Asn]: use with non-compound name *has* effect
ID: 46979 Updated by: cel...@php.net Reported By: ladislav at marek dot su Status: Assigned Bug Type: Scripting Engine problem Operating System: irrelevant PHP Version: 5.3.0alpha3 -Assigned To: cellog +Assigned To: dmitry New Comment: assign to namespace maintainer Previous Comments: [2008-12-31 09:36:09] ladislav at marek dot su Yes, but bug isn't fixed, 'use ArrayObject' is same as 'use \ArrayObject' manual is wrong. Please consider importing non-compound class or namespace names without \ prefix (remove invalid warning). [2008-12-30 23:49:09] fel...@php.net Duplicated of Bug #46755 [2008-12-30 23:38:25] ladislav at marek dot su Description: Currently php throws bogus warning with non-compound name in use statement. Reproduce code: --- namespace My; use Foo; new Foo\Bar; Expected result: Fatal error: Class 'Foo\Bar' not found in ... Actual result: -- Warning: The use statement with non-compound name 'Foo' has no effect in ... Fatal error: Class 'Foo\Bar' not found in ... 'use Foo' has effect, because fully qualified name isn't My\Foo\Bar but Foo\Bar. -- Edit this bug report at http://bugs.php.net/?id=46979&edit=1
#46755 [Asn]: warning: use statement with non-compound name
ID: 46755 Updated by: cel...@php.net Reported By: david at grudl dot com Status: Assigned Bug Type: Scripting Engine problem Operating System: * PHP Version: 5.3.0alpha3 -Assigned To: cellog +Assigned To: dmitry New Comment: assign to namespace maintainer Previous Comments: [2008-12-29 01:41:46] david at grudl dot com 1) The warning says "The use statement with non-compound name 'Foo' has no effect". This is not correct. I have posted example which show it HAS effect. Try it run in PHP. 2) "...the leading backslash is unnecessary and not allowed, as import names must be fully qualified, and are not processed relative to the current namespace." This is nonsense. If they are not processed relative, Foo is fully qualified - why developers MUST use leading backslash in some cases and MUST NOT is other cases - in all cases it is fully qualified. This should be fixed in documentation. Please, change status to Open. [2008-12-28 23:47:02] fel...@php.net "Note that for namespaced names (fully qualified namespace names containing namespace separator, such as Foo\Bar as opposed to global names that do not, such as FooBar), the leading backslash is unnecessary and not allowed, as import names must be fully qualified, and are not processed relative to the current namespace." This explain it. [2008-12-28 23:33:34] david at grudl dot com I have read it. Please, change status to Open. [2008-12-28 21:08:29] fel...@php.net Read: http://docs.php.net/manual/en/language.namespaces.importing.php [2008-12-19 17:19:57] david at grudl dot com It would be very nice if the error was fixed, because it is difficult to test alpha3 with a tons of Warnings: The use statement with non-compound name 'Nette' has no effect :-( The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/46755 -- Edit this bug report at http://bugs.php.net/?id=46755&edit=1
#47085 [Opn->Asn]: rename() returns true even if the file in PHAR does not exist
ID: 47085 Updated by: cel...@php.net Reported By: vr...@php.net -Status: Open +Status: Assigned Bug Type: PHAR related Operating System: Windows PHP Version: 5.3.0alpha3 -Assigned To: +Assigned To: cellog New Comment: didn't realize this one was out there, I'll take a look Previous Comments: [2009-01-13 11:27:03] vr...@php.net Description: rename() returns true with phar:// stream wrapper even if the oldfile doesn't exist. Reproduce code: --- Expected result: bool(false) and some warning Actual result: -- bool(true) -- Edit this bug report at http://bugs.php.net/?id=47085&edit=1
#47265 [Opn->Asn]: generating phar.phar failes because of safe_mode
ID: 47265
Updated by: cel...@php.net
Reported By: lars at larswolter dot de
-Status: Open
+Status: Assigned
Bug Type: PHAR related
Operating System: Linux
PHP Version: 5.3.0beta1
-Assigned To:
+Assigned To: cellog
New Comment:
I'll handle this one
Previous Comments:
[2009-02-01 23:28:33] lars at larswolter dot de
Description:
Compilation failes while generating phar.phar. This happens if php is
configured with safe_mode to on.
Workaround?
Add -d 'safe_mode=0' to PHP_PHARCMD_SETTINGS
Reproduce code:
---
'./configure' '--without-mm' \
'--with-mysql' '--prefix=/usr/lib/php5' \
'--with-mcrypt' \
'--enable-safe-mode' \
'--with-openssl' '--with-zlib' '--enable-calendar' \
'--enable-exif' '--enable-ftp' \
'--with-gd' '--with-imap' '--with-kerberos' \
'--with-imap-ssl' \
'--enable-gd-native-ttf' \
'--enable-force-cgi-redirect' \
'--with-freetype-dir=/usr/include/freetype2' \
'--with-jpeg-dir=/usr/lib' \
'--with-gettext' '--with-iconv' '--enable-mbstring=all' \
'--enable-mbregex' '--with-xsl' '--with-pdo-mysql'
Expected result:
Build complete.
Actual result:
--
Warning: shell_exec(): Cannot execute using backquotes in Safe Mode in
/home/lars/php-5.3.0beta1/ext/phar/phar.php on line 706
Pear package PHP_Archive or Archive.php class file not found.
Warning: Phar::__construct(): SAFE MODE Restriction in effect. The
script whose uid is 0 is not allowed to access
/home/lars/php-5.3.0beta1/ext/phar owned by uid 1001 in
/home/lars/php-5.3.0beta1/ext/phar/phar.php on line 1055
Fatal error: Uncaught exception 'UnexpectedValueException' with message
'Phar creation or opening failed' in
/home/lars/php-5.3.0beta1/ext/phar/phar.php:1055
Stack trace:
#0 /home/lars/php-5.3.0beta1/ext/phar/phar.php(1055):
Phar->__construct('/home/lars/php-5.3.0...', 0, 'pharcommand')
#1 [internal function]: PharCommand->cli_cmd_run_pack(Array)
#2 /home/lars/php-5.3.0beta1/ext/phar/phar.php(225):
call_user_func(Array, Array)
#3 /home/lars/php-5.3.0beta1/ext/phar/phar.php(2078):
CLICommand->__construct(19, Array)
#4 {main}
thrown in /home/lars/php-5.3.0beta1/ext/phar/phar.php on line 1055
make: *** [ext/phar/phar.phar] Fehler 255
--
Edit this bug report at http://bugs.php.net/?id=47265&edit=1
#47265 [Asn->Csd]: generating phar.phar failes because of safe_mode
ID: 47265
Updated by: cel...@php.net
Reported By: lars at larswolter dot de
-Status: Assigned
+Status: Closed
Bug Type: PHAR related
Operating System: Linux
PHP Version: 5.3.0beta1
Assigned To: cellog
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2009-02-03 17:12:29] cel...@php.net
I'll handle this one
[2009-02-01 23:28:33] lars at larswolter dot de
Description:
Compilation failes while generating phar.phar. This happens if php is
configured with safe_mode to on.
Workaround?
Add -d 'safe_mode=0' to PHP_PHARCMD_SETTINGS
Reproduce code:
---
'./configure' '--without-mm' \
'--with-mysql' '--prefix=/usr/lib/php5' \
'--with-mcrypt' \
'--enable-safe-mode' \
'--with-openssl' '--with-zlib' '--enable-calendar' \
'--enable-exif' '--enable-ftp' \
'--with-gd' '--with-imap' '--with-kerberos' \
'--with-imap-ssl' \
'--enable-gd-native-ttf' \
'--enable-force-cgi-redirect' \
'--with-freetype-dir=/usr/include/freetype2' \
'--with-jpeg-dir=/usr/lib' \
'--with-gettext' '--with-iconv' '--enable-mbstring=all' \
'--enable-mbregex' '--with-xsl' '--with-pdo-mysql'
Expected result:
Build complete.
Actual result:
--
Warning: shell_exec(): Cannot execute using backquotes in Safe Mode in
/home/lars/php-5.3.0beta1/ext/phar/phar.php on line 706
Pear package PHP_Archive or Archive.php class file not found.
Warning: Phar::__construct(): SAFE MODE Restriction in effect. The
script whose uid is 0 is not allowed to access
/home/lars/php-5.3.0beta1/ext/phar owned by uid 1001 in
/home/lars/php-5.3.0beta1/ext/phar/phar.php on line 1055
Fatal error: Uncaught exception 'UnexpectedValueException' with message
'Phar creation or opening failed' in
/home/lars/php-5.3.0beta1/ext/phar/phar.php:1055
Stack trace:
#0 /home/lars/php-5.3.0beta1/ext/phar/phar.php(1055):
Phar->__construct('/home/lars/php-5.3.0...', 0, 'pharcommand')
#1 [internal function]: PharCommand->cli_cmd_run_pack(Array)
#2 /home/lars/php-5.3.0beta1/ext/phar/phar.php(225):
call_user_func(Array, Array)
#3 /home/lars/php-5.3.0beta1/ext/phar/phar.php(2078):
CLICommand->__construct(19, Array)
#4 {main}
thrown in /home/lars/php-5.3.0beta1/ext/phar/phar.php on line 1055
make: *** [ext/phar/phar.phar] Fehler 255
--
Edit this bug report at http://bugs.php.net/?id=47265&edit=1
#47085 [Asn->Csd]: rename() returns true even if the file in PHAR does not exist
ID: 47085 Updated by: cel...@php.net Reported By: vr...@php.net -Status: Assigned +Status: Closed Bug Type: PHAR related Operating System: Windows PHP Version: 5.3.0alpha3 Assigned To: cellog New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. fixed and added a new test (tests/bug47085.phpt). This one was easy - I simply hadn't implemented the error on failed rename (oops) Previous Comments: [2009-02-03 17:10:39] cel...@php.net didn't realize this one was out there, I'll take a look [2009-01-13 11:27:03] vr...@php.net Description: rename() returns true with phar:// stream wrapper even if the oldfile doesn't exist. Reproduce code: --- Expected result: bool(false) and some warning Actual result: -- bool(true) -- Edit this bug report at http://bugs.php.net/?id=47085&edit=1
#46026 [Asn->Csd]: bz2.decompress/zlib.inflate filter tries to decompress after end of stream
ID: 46026
Updated by: cel...@php.net
Reported By: Keisial at gmail dot com
-Status: Assigned
+Status: Closed
Bug Type: Bzip2 Related
Operating System: *
PHP Version: 5.2CVS-2008-09-08 (snap)
Assigned To: cellog
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
re-fixed in 5.3 and HEAD
Previous Comments:
[2008-10-11 21:54:13] Keisial at gmail dot com
Wow, thank you very much. :-)
Sorry about the tabs. My editor messed them (I know, I know, real
programmers use butterflies...).
However, consider doing this:
if (SUCCESS == zend_hash_find(HASH_OF(filterparams), "concatenated",
sizeof("concatenated"), (void **) &tmpzval) ) {
-SEPARATE_ZVAL(tmpzval);
-convert_to_boolean_ex(tmpzval);
data->expect_concatenated = Z_LVAL_PP(tmpzval);
-zval_ptr_dtor(tmpzval);
tmpzval = NULL;
}
There were memory corruption problems with the previous patch, and
zval_ptr_dtor seemed to be the source (thanks to rrichards and pajoye
for their help on this on irc). Also, the other zval_ptr_dtor below
(present there since first version by Sara) would be a "good possible
candidate for another possible point of mem corruption".
[2008-10-11 19:15:22] cel...@php.net
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
fixed in PHP 5.2, 5.3, 6.0. Concatenation was only added in PHP 5.3
and 6.0, as new features cannot be added to PHP 5.2
[2008-10-11 19:08:35] cel...@php.net
changing summary to reflect addition of zlib problem
[2008-10-11 18:25:14] cel...@php.net
In the future, please follow 2 important elements of the coding
standards:
1) use tabs instead of spaces
2) always use {} around if/else blocks
I had to waste 15 minutes just getting the patch formatted correctly
before I could even begin testing it. I don't like wasting time.
[2008-10-11 17:12:10] cel...@php.net
this same bug applies to zlib stream filter, and also happens simply
when trying to read from a filtered stream that contains a limited
amount of compressed data (as in a zip archive with a bz2-compressed
file), as php_stream_fill_read_buffer reads in maxlen data, triggering
the problem you found. I'll try to get this fixed up and put in a few
tests
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/46026
--
Edit this bug report at http://bugs.php.net/?id=46026&edit=1
#46984 [Ana]: Strict-Warning when overwriting methods with changed parameters
ID: 46984
Updated by: cel...@php.net
Reported By: d_quijote at web dot de
Status: Analyzed
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 5.3.0alpha3
New Comment:
the error occurs regardless of implementing an interface, and is, I
believe, correct. If $y were optional, there is no problem, and no
error
Previous Comments:
[2009-01-01 00:21:51] fel...@php.net
I agree with you, here is a patch:
http://felipe.ath.cx/diff/bug46984.diff
However it broken some tests, that for me, looks as even they are
wrong.
method overloading with different method signature
[Zend/tests/objects_002.phpt]
method overloading with different method signature
[Zend/tests/objects_003.phpt]
method overloading with different method signature
[Zend/tests/objects_004.phpt]
method overloading with different method signature
[Zend/tests/objects_005.phpt]
method overloading with different method signature
[Zend/tests/objects_006.phpt]
method overloading with different method signature
[Zend/tests/objects_007.phpt]
method overloading with different method signature
[Zend/tests/objects_008.phpt]
method overloading with different method signature
[Zend/tests/objects_009.phpt]
Let's decide the expected behavior, wait...
[2008-12-31 12:52:32] d_quijote at web dot de
Description:
A Strict-Warning is raised when the parameters of the subclass differ
from the parameters of the overwritten superclass method. This error
seems only to occure if any interface is included in the superclass
Reproduce code:
---
class A implements Iterator {
public function current() {}
public function key() {}
public function next() {}
public function rewind() {}
public function valid() {}
public function f($x) {
echo $x.PHP_EOL;
}
}
class B extends A {
public function f($x,$y) {
echo __METHOD__.'('.$x.', '.$y.')'.PHP_EOL;
}
}
$b = new B();
$b->f(1,2);
Expected result:
B::f(1, 2)
Actual result:
--
Strict Standards: Declaration of B::f() should be compatible with that
of A::f() in /index.php on line 19
--
Edit this bug report at http://bugs.php.net/?id=46984&edit=1
#47257 [Csd->Tbd]: SQLite3->__construct has no sane way to detect errors
ID: 47257
Updated by: cel...@php.net
Reported By: cel...@php.net
-Status: Closed
+Status: To be documented
Bug Type: SQLite related
Operating System: *
PHP Version: 5.3.0beta1
Assigned To: scottmac
New Comment:
the constructor throws exceptions (for the doc team)
Previous Comments:
[2009-02-10 00:44:36] scott...@php.net
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2009-02-01 17:51:57] scott...@php.net
I'll add an error mode option and probably default it to an exception.
I'm not a huge fan of heavy exception throwing code, you end up wrapping
huge blocks of code in try {}.
[2009-02-01 17:22:53] crrodriguez at suse dot de
Exceptions only IMHO, it is a "new" OOP only extension, kinda odd that
it throws only notices on errors...
[2009-01-31 19:22:22] cel...@php.net
Description:
SQLite3->__construct does not indicate errors by anything other than an
E_NOTICE. This means we have to set a user error handler just to tell
whether or not this code succeeds:
the constructor should throw an exception, or provide an error string
parameter by reference like the SQLite object.
Reproduce code:
---
Expected result:
exception
Actual result:
--
E_NOTICE error
--
Edit this bug report at http://bugs.php.net/?id=47257&edit=1
#47645 [Opn->Bgs]: PHP_Archive / Archive.php missing
ID: 47645 Updated by: cel...@php.net Reported By: lneve at mail dot nih dot gov -Status: Open +Status: Bogus Bug Type: PHAR related Operating System: Solaris 10 x86 PHP Version: 5.3.0beta1 New Comment: The bug you quote, #45726 was a bug because after not finding PHP_Archive, the build would fail. As your output shows, phar.phar is indeed successfully built without PHP_Archive, which is expected. The difference here is that phar.phar cannot create a phar archive that contains the PHP_Archive class. Otherwise, phar.phar works great. I'm marking this bogus because there is no bug. If you do indeed want to take advantage of PHP_Archive, simply install it: pear install PHP_Archive-beta and then make PHP again. Previous Comments: [2009-03-13 15:07:52] lneve at mail dot nih dot gov Description: This is the same as bug #45726, which was CLOSED but should not have been since the bug persists. Here is the relevant build output: Generating phar.php Generating phar.phar Pear package PHP_Archive or Archive.php class file not found. directorytreeiterator.inc directorygraphiterator.inc clicommand.inc invertedregexiterator.inc pharcommand.inc phar.inc Please let me know what else I can provide to help you troubleshoot and fix this problem. -- Edit this bug report at http://bugs.php.net/?id=47645&edit=1
#47323 [Asn]: strotime warnings in make install
ID: 47323 Updated by: cel...@php.net Reported By: frozenfire at thefrozenfire dot com Status: Assigned Bug Type: PHAR related Operating System: Ubuntu 8.10 2.6.27-11-generic PHP Version: 5.3.0RC1 Assigned To: dufuz New Comment: the bug will be fixed when PEAR 1.8.0 is released, which will be very soon, Helgi is hard at work. You are correct that this should not be closed until the phar archive is released, but Helgi is also correct in that this was fixed in the CVS of PEAR. Complicated stuff. Previous Comments: [2009-03-26 08:25:19] phi...@php.net This bug still exists with 5.3.0RC1 so should remain open until that changes. [2009-02-16 00:48:39] du...@php.net This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. This will be fixed when the next release of the PEAR installer goes live [2009-02-06 03:46:33] frozenfire at thefrozenfire dot com Description: I've configured a vanilla install of PHP 5.3 Beta 1, using ./configure --prefix=/usr/local/php-5.3 --program-suffix=53 After configuring (And resolving some missing dependencies), I did a make, and then a make test (Results submitted). Next, I did a make install, which produced: Warning: strtotime(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Los_Angeles' for 'PST/-8.0/no DST' instead in phar:///home/myuser/php-5.3.0beta1/pear/install-pear-nozlib.phar/PEAR/Validate.php on line 489 About a dozen times during "Installing PEAR environment: /usr/local/php-5.3/lib/php/" I don't know if it's related, but the interactive mode in PHP doesn't work (php53 -a). It prints out "Interactive mode enabled" and then allows input, but doesn't process it in any way, including "exit." Reproduce code: --- sudo ./configure --prefix=/usr/local/php-5.3 --program-suffix=53 sudo make sudo make test sudo make install Expected result: For the make install, I expected none of the warning messages. Actual result: -- Full make install output: http://pastebin.ca/1328662 -- Edit this bug report at http://bugs.php.net/?id=47323&edit=1
#43857 [Asn]: --program-suffix not always reflected everywhere
ID: 43857 Updated by: cel...@php.net Reported By: bjoern at xrow dot de Status: Assigned Bug Type: Compile Failure Operating System: linux PHP Version: 5.2.6 Assigned To: cellog New Comment: this is about to be fixed some time this week, the PEAR version with the fix should be released any day now, and once its stability is verified, we'll update the phar. I will update the Makefile.frag when this happens, and then change the status to Feedback to make sure it works for you (my preliminary testing has it working here) Previous Comments: [2009-01-22 01:16:51] j...@php.net Was the package updated for 5.2.8 or not..? (it's 5.2.9 soon..) [2008-11-29 04:08:17] cel...@php.net this is now fixed in PEAR CVS, but I will keep this open until the install phar in php's source is updated [2008-11-29 03:43:14] cel...@php.net This is a very difficult problem to solve for all cases. Most fixes I've tried thus far break many other cases. For instance, the calls to "phpize" and "php-config" are done inside the source of PEAR/Builder.php. If we manually modify the source of PEAR/Builder.php, the instant a user calls "pear config-set php_bin /path/to/some/other/php" the whole thing breaks. So, what I am going to do is provide two new options to the "install" "upgrade" and "upgrade-all" commands which are designed to account for --program-suffix or --program-prefix being used, --program-suffix and --program-prefix which will programmatically append/prepend for the phpize/php-config commands. I'll also provide 2 new config variables that can be set to make this automatic. This new feature will not appear until PEAR 1.8.0 is released, which will hopefully be before PHP 5.3.0 [2008-02-18 11:05:10] j...@php.net This is actually PEAR bug, but as it's quite tightly connected to PHP we can keep this here. I don't know where that pecl script is and I don't want to touch it either since there's some new installer cooking..so Greg, can you please fix it to use the provided php-config instead? (note: php-config also might use the --program-prefix and --program-suffix options!) [2008-01-15 17:02:35] bjoern at xrow dot de Description: Hi, I used ./configure --program-suffix=5 --prefix=/usr/local/php5 when i try to run stuff like bin/pecl it fails since the script created by the installer didn`t take the suffix in account for pecl - lines from bin/pecl if test "/usr/local/php5/bin/php" = '@'php_bin'@'; then PHP=php else PHP="/usr/local/php5/bin/php" fi after fixing that manually i tryied it again and it seems also the correct path to phpize is missing with is phpize5 /usr/local/php5/bin/pecl install xdebug ^[[A^[[Adownloading xdebug-2.0.2.tgz ... Starting to download xdebug-2.0.2.tgz (279,621 bytes) .done: 279,621 bytes 65 source files, building running: phpize Configuring for: PHP Api Version: 20020918 Zend Module Api No: 20020429 Zend Extension Api No: 20050606 ERROR: `phpize' failed -- Edit this bug report at http://bugs.php.net/?id=43857&edit=1
#44782 [Ver->Bgs]: Problem with namespace and dynamic referencing
ID: 44782 Updated by: [EMAIL PROTECTED] Reported By: deleet at sapo dot pt -Status: Verified +Status: Bogus Bug Type: Class/Object related Operating System: Fedora 6 PHP Version: 5.3CVS-2008-04-19 (snap) New Comment: This is not a bug, for this simple reason. Let's take these two scripts: file1.php: \n"; } } $a = 'Testing'; ?> $file2.php: \n"; } } ?> file3.php: What should the output be? There is no deterministic way to do this. Dynamic class references always must be the fully qualified classname, even within the namespace. The same is true of doing: $a = 'Testing'; $b = new $a; and this is by design, as I understand it. The easy way out is to use $a = __NAMESPACE__ . '::Testing'; as this will allow renaming the namespace without penalty. Previous Comments: [2008-04-19 22:14:14] deleet at sapo dot pt Very well, dynamic referencing it is then :) Thank you for the quick reply, is it possible to get an ETA on the fix? [2008-04-19 21:43:26] [EMAIL PROTECTED] This isn't late static bindings, but it's indeed a bug, probably relying on the fact that Testing::$func(); would have been rewritten in compile time. [2008-04-19 18:34:31] deleet at sapo dot pt Description: Possible problem with the implementation of namespaces and late static binding. Reproduce code: --- \n"; } } Testing::stuff(); $var = 'Testing'; $func = 'stuff'; // No effect: use Something; $var::$func(); ?> Expected result: Output: -- I work! I work! Actual result: -- Output: -- I work! Fatal error: Class 'Testing' not found in //file url// on line 20 -- PHP is not looking for the class inside the defined namespace when using late static binding. It works if I use $var = 'Something::Testing'; but that's not indented behaviour. Also, using the namespace seems to have no effect. -- Edit this bug report at http://bugs.php.net/?id=44782&edit=1
#44990 [Opn->Bgs]: array('word')==array(0) -- true
ID: 44990
Updated by: [EMAIL PROTECTED]
Reported By: design at apostolstudio dot com
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Windows XP
PHP Version: 5.2.6
New Comment:
use ===
'word' is converted to an integer for the comparison, and thus 0 == 0.
try this code:
if(array('word')===array(0)) echo "ERROR";
Previous Comments:
[2008-05-14 02:27:10] design at apostolstudio dot com
Description:
array('word')==array(0) -- return true
Reproduce code:
---
if(array('word')==array(0)) echo "ERROR";
Actual result:
--
ERROR
--
Edit this bug report at http://bugs.php.net/?id=44990&edit=1
