Bug #62303 [Opn->Fbk]: ReflectionClass, getMethods(), getName() empty

2012-07-25 Thread aharvey 
Edit report at https://bugs.php.net/bug.php?id=62303&edit=1

 ID: 62303
 Updated by: ahar...@php.net
 Reported by:v at roxori dot com
 Summary:ReflectionClass, getMethods(), getName() empty
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:Reflection related
 Operating System:   FreeBSD9
 PHP Version:5.4.3
 Block user comment: N
 Private report: N

 New Comment:

Does it still happen if you remove APC?


Previous Comments:

[2012-07-26 06:33:08] v at roxori dot com

Another remarked that in cgi mode, it happens.

#php info.php
ReflectionMethod Object
(
[name] => first
[class] => Foo
)
ReflectionMethod Object
(
[name] => second
[class] => Foo
)


#php-cgi info.php
X-Powered-By: PHP/5.4.3
Content-type: text / html

ReflectionMethod Object
(
[namei ≤ ╔
] => First
[class] => Foo
)
ReflectionMethod Object
(
[namei ≤ ╔
] => Second
[class] => Foo
)

-
apc.so
bz2.so
core.so
ctype.so
curl.so
date.so
dom.so
ereg.so
filter.so
gd.so
hash.so
iconv.so
json.so
libxml.so
mbstring.so
mcrypt.so
mhash.so
mysql.so
mysqli.so
mysqlnd.so
openssl.so
pcre.so
pdo.so
pdo_mysql.so
pdo_sqlite.so
phar.so
posix.so
reflection.so
session.so
simplexml.so
soap.so
sockets.so
spl.so
sqlite.so
sqlite3.so
standard.so
tokenizer.so
xml.so
xmlreader.so
xmlrpc.so
xmlwriter.so
zip.so
zlib.so


[2012-07-26 01:38:23] ahar...@php.net

I also can't reproduce this. What extensions do you have loaded into PHP?


[2012-07-25 12:29:00] f...@php.net

Cannot reproduce.

$ php -v
PHP 5.4.4 (cli) (built: Jun 28 2012 15:38:36)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies

php testp.php
first
second


FreeBSD host.example.org 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan  3 
07:46:30 
UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64


[2012-06-13 08:06:38] v at roxori dot com

Another found that the index broken array, so that probably does not display a 
value.

PHP5.4.3  FreeBSD9
ReflectionMethod Object
(
[namei˜Ґ] => first
[class] => Foo
)
ReflectionMethod Object
(
[namei˜Ґ] => second
[class] => Foo
)

PHP5.4.3 Linux

ReflectionMethod Object
(
[name] => first
[class] => Foo
)
ReflectionMethod Object
(
[name] => second
[class] => Foo
)


[2012-06-12 22:51:40] ni...@php.net

I can't reproduce this: http://3v4l.org/6cvK8#v500

Seems to behave the same on all versions, with no change in between.

Maybe this is OS specific (or specific to something else in your env).




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

https://bugs.php.net/bug.php?id=62303


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=62303&edit=1

Bug #62303 [Fbk->Opn]: ReflectionClass, getMethods(), getName() empty

2012-07-25 Thread v at roxori dot com 
Edit report at https://bugs.php.net/bug.php?id=62303&edit=1

 ID: 62303
 User updated by:v at roxori dot com
 Reported by:v at roxori dot com
 Summary:ReflectionClass, getMethods(), getName() empty
-Status: Feedback
+Status: Open
 Type:   Bug
 Package:Reflection related
 Operating System:   FreeBSD9
 PHP Version:5.4.3
 Block user comment: N
 Private report: N

 New Comment:

Another remarked that in cgi mode, it happens.

#php info.php
ReflectionMethod Object
(
[name] => first
[class] => Foo
)
ReflectionMethod Object
(
[name] => second
[class] => Foo
)


#php-cgi info.php
X-Powered-By: PHP/5.4.3
Content-type: text / html

ReflectionMethod Object
(
[namei ≤ ╔
] => First
[class] => Foo
)
ReflectionMethod Object
(
[namei ≤ ╔
] => Second
[class] => Foo
)

-
apc.so
bz2.so
core.so
ctype.so
curl.so
date.so
dom.so
ereg.so
filter.so
gd.so
hash.so
iconv.so
json.so
libxml.so
mbstring.so
mcrypt.so
mhash.so
mysql.so
mysqli.so
mysqlnd.so
openssl.so
pcre.so
pdo.so
pdo_mysql.so
pdo_sqlite.so
phar.so
posix.so
reflection.so
session.so
simplexml.so
soap.so
sockets.so
spl.so
sqlite.so
sqlite3.so
standard.so
tokenizer.so
xml.so
xmlreader.so
xmlrpc.so
xmlwriter.so
zip.so
zlib.so


Previous Comments:

[2012-07-26 01:38:23] ahar...@php.net

I also can't reproduce this. What extensions do you have loaded into PHP?


[2012-07-25 12:29:00] f...@php.net

Cannot reproduce.

$ php -v
PHP 5.4.4 (cli) (built: Jun 28 2012 15:38:36)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies

php testp.php
first
second


FreeBSD host.example.org 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan  3 
07:46:30 
UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64


[2012-06-13 08:06:38] v at roxori dot com

Another found that the index broken array, so that probably does not display a 
value.

PHP5.4.3  FreeBSD9
ReflectionMethod Object
(
[namei˜Ґ] => first
[class] => Foo
)
ReflectionMethod Object
(
[namei˜Ґ] => second
[class] => Foo
)

PHP5.4.3 Linux

ReflectionMethod Object
(
[name] => first
[class] => Foo
)
ReflectionMethod Object
(
[name] => second
[class] => Foo
)


[2012-06-12 22:51:40] ni...@php.net

I can't reproduce this: http://3v4l.org/6cvK8#v500

Seems to behave the same on all versions, with no change in between.

Maybe this is OS specific (or specific to something else in your env).


[2012-06-12 21:01:45] v at roxori dot com

Description:

After upgrading PHP to 5.4.3 no longer return the name of the method. 
Correspondingly, the library stopped working, namely Zend. Now the issue Fatal 
error: Uncaught exception 'Zend_Amf_Server_Exception' with message 'Duplicate 
method registered: Having sorted out, I realized that the code does not return 
the 
name of the method. In PHP 5.3 all was ok.

---
>From manual page: http://www.php.net/reflectionclass.getname#refsect1-
reflectionclass.getname-description
---

Test script:
---
class Foo {

function first(){

}

function second(){

}
}

$foo = new Foo();

$reflect = new ReflectionClass($foo);

$props   = $reflect->getMethods();

foreach ($props as $prop) {
print $prop->getName() . "\n";
}


Expected result:

first
second

Actual result:
--
(empty)






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=62303&edit=1

Bug #62653 [Opn->Csd]: unset($array[$float]) causes a crash

2012-07-25 Thread laruence 
Edit report at https://bugs.php.net/bug.php?id=62653&edit=1

 ID: 62653
 Updated by: larue...@php.net
 Reported by:davidso1 at rose-hulman dot edu
 Summary:unset($array[$float]) causes a crash
-Status: Open
+Status: Closed
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Windows Server
 PHP Version:5.4.5
-Assigned To:
+Assigned To:laruence
 Block user comment: N
 Private report: N

 New Comment:

This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.

the reason why jpauli and I can not reproduce is (it's silly):
I typo "USE_ZEND_ALLOC *&&* valgrind" at the first time, then I always ctrl+r
and jpauli copied my command from the pastbin :)

thanks


Previous Comments:

[2012-07-26 05:56:24] larue...@php.net

Automatic comment on behalf of laruence
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=eae06100429f37e5297c432e99104daeeed13bad
Log: Fixed bug #62653: (unset($array[$float]) causes a crash)


[2012-07-26 05:53:09] larue...@php.net

Automatic comment on behalf of laruence
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=eae06100429f37e5297c432e99104daeeed13bad
Log: Fixed bug #62653: (unset($array[$float]) causes a crash)


[2012-07-26 02:26:17] ras...@php.net

It is reproducable on 64-bit Ubuntu 12.04 with Valgrind 3.8.0


[2012-07-26 02:16:52] larue...@php.net

still can not reproduce in Ubuntu 11.10 && valgrind 3.6.1 & gcc 4.6.1 & 64bits


[2012-07-25 16:48:21] ni...@php.net

I have a patch for this here: https://github.com/php/php-src/pull/144

If you could test whether it fixes the issue for you it would help a lot.

We had some issues reproducing the problem consistently, so would be nice to 
verify this :)




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

https://bugs.php.net/bug.php?id=62653


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=62653&edit=1

Bug #62661 [Ver->Csd]: Interactive php-cli crashes if include() is used in auto_prepend_file

2012-07-25 Thread laruence 
Edit report at https://bugs.php.net/bug.php?id=62661&edit=1

 ID: 62661
 Updated by: larue...@php.net
 Reported by:pierre at guinoiseau dot eu
 Summary:Interactive php-cli crashes if include() is used in
 auto_prepend_file
-Status: Verified
+Status: Closed
 Type:   Bug
 Package:Reproducible crash
 Operating System:   FreeBSD / Ubuntu
 PHP Version:5.4.5
-Assigned To:
+Assigned To:laruence
 Block user comment: N
 Private report: N

 New Comment:

This bug has been fixed in SVN.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.




Previous Comments:

[2012-07-26 04:43:04] larue...@php.net

Automatic comment on behalf of laruence
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=b4b3a65f5518803c4a3bca34ac67e139b2547133
Log: Fixed bug #62661 (Interactive php-cli crashes if include() is used in 
auto_prepend_file)


[2012-07-26 04:42:05] larue...@php.net

Automatic comment on behalf of laruence
Revision: 
http://git.php.net/?p=php-src.git;a=commit;h=b4b3a65f5518803c4a3bca34ac67e139b2547133
Log: Fixed bug #62661 (Interactive php-cli crashes if include() is used in 
auto_prepend_file)


[2012-07-26 01:47:43] ahar...@php.net

Verified on a current 5.4 build.

Backtrace for the prepend_segfault.php case:

#0  0x00a423d6 in ZEND_DO_FCALL_SPEC_CONST_HANDLER 
(execute_data=0x77f7b240)
at /home/adam/trees/php-src/5.4/Zend/zend_vm_execute.h:2209
#1  0x00a3935d in execute (op_array=0x77fb3920)
at /home/adam/trees/php-src/5.4/Zend/zend_vm_execute.h:410
#2  0x009e5d5a in execute_new_code ()
at /home/adam/trees/php-src/5.4/Zend/zend_execute_API.c:1322
#3  0x009932cc in zendparse () at 
/home/adam/trees/php-src/5.4/Zend/zend_language_parser.y:218
#4  0x0099b1af in compile_file (file_handle=0x7fffa620, type=2)
at Zend/zend_language_scanner.l:582
#5  0x007335b1 in phar_compile_file (file_handle=0x7fffa620, type=2)
at /home/adam/trees/php-src/5.4/ext/phar/phar.c:3391
#6  0x0099b367 in compile_filename (type=2, filename=0x77fb2ca8)
at Zend/zend_language_scanner.l:625
#7  0x00a432e7 in ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLER 
(execute_data=0x77f7b0e8)
at /home/adam/trees/php-src/5.4/Zend/zend_vm_execute.h:2592
#8  0x00a3935d in execute (op_array=0x77fb1d40)
at /home/adam/trees/php-src/5.4/Zend/zend_vm_execute.h:410
#9  0x009f8d57 in zend_execute_scripts (type=8, retval=0x0, 
file_count=3)
at /home/adam/trees/php-src/5.4/Zend/zend.c:1279
#10 0x0095f0e1 in php_execute_script (primary_file=0x7fffce60)
at /home/adam/trees/php-src/5.4/main/main.c:2473
#11 0x00b4b9c7 in do_cli (argc=5, argv=0x7fffe248)
at /home/adam/trees/php-src/5.4/sapi/cli/php_cli.c:988
#12 0x00b4cc4a in main (argc=5, argv=0x7fffe248)
at /home/adam/trees/php-src/5.4/sapi/cli/php_cli.c:1364

prepend_twotimes.php executes as described for me (with the double output from 
prepend_twotimes.php itself), then blocks on a read() syscall. The strace 
output is at https://gist.github.com/852ba3b100a4a7437e53


[2012-07-25 16:12:20] pierre at guinoiseau dot eu

Description:

Hello,

this bug may be related to bug #49000. php-cli crashes in interactive mode if 
you do an include() in auto_prepend_file. An example will explain it better 
(see 
test scripts):
  % php -d auto_prepend_file=prepend.php -a
  Interactive mode enabled
  
  test 1
  test 2
  Ran out of opcode space!
  You should probably consider writing this huge script into a file!

This was tested with PHP 5.4.5 (from ports) on FreeBSD 8.1 and PHP 5.4.4 (from 
Debian Git repository) on Ubuntu 12.04.

No error if the include file is missing (only the usual warning).

Also, I got another very weird case...
The provided prepend_segfault.php segfaults instead of the error above:
  % php -d auto_prepend_file=prepend_segfault.php -a
  Interactive shell
  
  test 1
  zsh: segmentation fault (core dumped)  php -d 
auto_prepend_file=prepend_segfault.php -a

But there is no segfault and no errors if I remove "$toto = 1".

If I replace one (or both) if/elseif conditions with true or false, it execute 
the script 2 times instead on 5.4.4 (and it segfaults on 5.4.5):
% php -d auto_prepend_file=prepend_towtimes.php -a
  Interactive shell
  
  test 1
  test 1 bis
  test 1
  test 1 bis
  test 2

Bug #62653 [Opn]: unset($array[$float]) causes a crash

2012-07-25 Thread rasmus 
Edit report at https://bugs.php.net/bug.php?id=62653&edit=1

 ID: 62653
 Updated by: ras...@php.net
 Reported by:davidso1 at rose-hulman dot edu
 Summary:unset($array[$float]) causes a crash
 Status: Open
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Windows Server
 PHP Version:5.4.5
 Block user comment: N
 Private report: N

 New Comment:

It is reproducable on 64-bit Ubuntu 12.04 with Valgrind 3.8.0


Previous Comments:

[2012-07-26 02:16:52] larue...@php.net

still can not reproduce in Ubuntu 11.10 && valgrind 3.6.1 & gcc 4.6.1 & 64bits


[2012-07-25 16:48:21] ni...@php.net

I have a patch for this here: https://github.com/php/php-src/pull/144

If you could test whether it fixes the issue for you it would help a lot.

We had some issues reproducing the problem consistently, so would be nice to 
verify this :)


[2012-07-25 15:55:10] jpa...@php.net

Switch to Scripting Engine Problem as bug type


[2012-07-25 13:40:44] larue...@php.net

I can no reproduce this on Linux redhat


[2012-07-24 19:27:22] s...@php.net

The testcase produces invalid reads & writes in valgrind.




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

https://bugs.php.net/bug.php?id=62653


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=62653&edit=1

Bug #62653 [Opn]: unset($array[$float]) causes a crash

2012-07-25 Thread laruence 
Edit report at https://bugs.php.net/bug.php?id=62653&edit=1

 ID: 62653
 Updated by: larue...@php.net
 Reported by:davidso1 at rose-hulman dot edu
 Summary:unset($array[$float]) causes a crash
 Status: Open
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Windows Server
 PHP Version:5.4.5
 Block user comment: N
 Private report: N

 New Comment:

still can not reproduce in Ubuntu 11.10 && valgrind 3.6.1 & gcc 4.6.1 & 64bits


Previous Comments:

[2012-07-25 16:48:21] ni...@php.net

I have a patch for this here: https://github.com/php/php-src/pull/144

If you could test whether it fixes the issue for you it would help a lot.

We had some issues reproducing the problem consistently, so would be nice to 
verify this :)


[2012-07-25 15:55:10] jpa...@php.net

Switch to Scripting Engine Problem as bug type


[2012-07-25 13:40:44] larue...@php.net

I can no reproduce this on Linux redhat


[2012-07-24 19:27:22] s...@php.net

The testcase produces invalid reads & writes in valgrind.


[2012-07-24 16:16:05] davidso1 at rose-hulman dot edu

Description:

The test code crashes apache in the 5.4+ environment.
$foo starts as a string, gets interpreted as a double but it isn't I guess.

unset($array[(double) $foo]) works as expected

Test script:
---
$array = array("5"=>"bar");
$foo = "10."; // gettype($foo) = "string"
$foo /= 2; //Makes $foo = 5 but still gettype($foo) = "double"
unset($array[$foo]);
print_r($array);

Expected result:

Array()

Actual result:
--
Error 101 (net::ERR_CONNECTION_RESET): The connection was reset.






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=62653&edit=1

Req #32100 [ReO]: Request 'finally' support for exceptions

2012-07-25 Thread laruence 
Edit report at https://bugs.php.net/bug.php?id=32100&edit=1

 ID: 32100
 Updated by: larue...@php.net
 Reported by:ceefour at gauldong dot net
 Summary:Request 'finally' support for exceptions
 Status: Re-Opened
 Type:   Feature/Change Request
 Package:*General Issues
 Operating System:   *
 PHP Version:5.*
 Assigned To:laruence
 Block user comment: N
 Private report: N

 New Comment:

RFC complete, https://wiki.php.net/rfc/finally


Previous Comments:

[2012-07-25 23:44:07] pravdin at vl dot ru

We are writing large web application on PHP using the OOP and programming 
patterns. Exceptions are not only error reporting mechanism but also very 
important program flow mechanism. So, try...finally is commonly needed. Please 
add 
this feature. I know, PHP is not OOP, but I think there is no reason to limit 
developers needs, especially when this needs are not for just a few single 
developers.


[2012-07-24 10:59:57] larue...@php.net

I will try to make a implemention.


[2012-07-18 23:13:07] pieceofchum at yahoo dot com

Hello I am a Java developer and would like to move over to PHP for my current 
personal projects. The use of finally in Java is extremely powerful as it 
ensures that a unit of work that uses any resources that need to be managed are 
guaranteed to be handled before leaving the method even whent here is a catch 
clause. This has nothing to do with control flow and exception handling it has 
everything to do with contract based blocks of code in fact finally is a 
totally unique construct which greatly simplifies algorithms where one needs a 
guarantee of certain code running (usually to handle external resources) no 
matter what happens outside of course of an error (error defined as something 
that breaks the interpreter/compiler/environmen). It is not a mistake of design 
but a vast improvement in code clarity and application of the DRY principle 
which is correct programming and has nothing at all to do with improper control 
flow. It is not a mistake that it is in some form in Python, Ruby, Java etc... 
Please please recondsider adding this extremely important construct to PHP. 

Thanks for your consideration in this matter


[2012-07-05 20:17:57] angelo at camargo dot ws

++ for finally in PHP


[2012-06-07 09:16:55] jl235 at kent dot ac dot uk

Most of the exceptions people come across in their PHP code tends to be for 
either File IO, or database access. Both of these need a finally to ensure the 
handle/connection/whatever gets closed, or dealt with in some other way. Using 
try/catch is already a lot more cumbersome then a world without Exceptions, but 
without finally, it adds a lot duplication and state management.

For example in my own code I do something along the lines of ...



$time = microtime( true );
$sql = generateSQLQuery();
$conn = openDBConnection();
$ex = null;

try {
$result = runSQLQuery( $conn, $sql );
} catch ( Exception $ex ) { /* do nothing */ }

closeDBConnection( $conn );
logSQLQuery( $sql, microtime(true) - $time );

if ( $ex !== null ) {
throw $ex;
}



... which could just be ...



$time = microtime( true );
$sql  = generateSQLQuery();
$conn = openDBConnection();

try {
$result = runSQLQuery( $conn, $sql );
} finally {
closeDBConnection( $conn );
logSQLQuery( $sql, microtime(true) - $time );
}



Simpler to write, easier to read, harder to get wrong, and more elegant.

Please re-open this.




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

https://bugs.php.net/bug.php?id=32100


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=32100&edit=1

Req #62663 [Wfx]: Backtick operators are an ugly language construct

2012-07-25 Thread eldmannen+php at gmail dot com 
Edit report at https://bugs.php.net/bug.php?id=62663&edit=1

 ID: 62663
 User updated by:eldmannen+php at gmail dot com
 Reported by:eldmannen+php at gmail dot com
 Summary:Backtick operators are an ugly language construct
 Status: Wont fix
 Type:   Feature/Change Request
 Package:Scripting Engine problem
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

I think it should throw a E_DEPRECATED warning suggesting the use of 
shell_exec().


Previous Comments:

[2012-07-26 01:49:32] ahar...@php.net

Given how long backticks have been part of the language, there's no chance 
they'll be removed, given backward compatibility concerns. Sorry.


[2012-07-26 00:36:43] eldmannen+php at gmail dot com

Description:

The backtick operator construct is an ugly construct.

The shell_exec() function should be used instead.

I propose the removal of the backtick operator construct.

Test script:
---








-- 
Edit this bug report at https://bugs.php.net/bug.php?id=62663&edit=1

Req #62663 [Opn->Wfx]: Backtick operators are an ugly language construct

2012-07-25 Thread aharvey 
Edit report at https://bugs.php.net/bug.php?id=62663&edit=1

 ID: 62663
 Updated by: ahar...@php.net
 Reported by:eldmannen+php at gmail dot com
 Summary:Backtick operators are an ugly language construct
-Status: Open
+Status: Wont fix
 Type:   Feature/Change Request
 Package:Scripting Engine problem
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

Given how long backticks have been part of the language, there's no chance 
they'll be removed, given backward compatibility concerns. Sorry.


Previous Comments:

[2012-07-26 00:36:43] eldmannen+php at gmail dot com

Description:

The backtick operator construct is an ugly construct.

The shell_exec() function should be used instead.

I propose the removal of the backtick operator construct.

Test script:
---








-- 
Edit this bug report at https://bugs.php.net/bug.php?id=62663&edit=1

Bug #62661 [Opn->Ver]: Interactive php-cli crashes if include() is used in auto_prepend_file

2012-07-25 Thread aharvey 
Edit report at https://bugs.php.net/bug.php?id=62661&edit=1

 ID: 62661
 Updated by: ahar...@php.net
 Reported by:pierre at guinoiseau dot eu
 Summary:Interactive php-cli crashes if include() is used in
 auto_prepend_file
-Status: Open
+Status: Verified
 Type:   Bug
 Package:Reproducible crash
 Operating System:   FreeBSD / Ubuntu
 PHP Version:5.4.5
 Block user comment: N
 Private report: N

 New Comment:

Verified on a current 5.4 build.

Backtrace for the prepend_segfault.php case:

#0  0x00a423d6 in ZEND_DO_FCALL_SPEC_CONST_HANDLER 
(execute_data=0x77f7b240)
at /home/adam/trees/php-src/5.4/Zend/zend_vm_execute.h:2209
#1  0x00a3935d in execute (op_array=0x77fb3920)
at /home/adam/trees/php-src/5.4/Zend/zend_vm_execute.h:410
#2  0x009e5d5a in execute_new_code ()
at /home/adam/trees/php-src/5.4/Zend/zend_execute_API.c:1322
#3  0x009932cc in zendparse () at 
/home/adam/trees/php-src/5.4/Zend/zend_language_parser.y:218
#4  0x0099b1af in compile_file (file_handle=0x7fffa620, type=2)
at Zend/zend_language_scanner.l:582
#5  0x007335b1 in phar_compile_file (file_handle=0x7fffa620, type=2)
at /home/adam/trees/php-src/5.4/ext/phar/phar.c:3391
#6  0x0099b367 in compile_filename (type=2, filename=0x77fb2ca8)
at Zend/zend_language_scanner.l:625
#7  0x00a432e7 in ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLER 
(execute_data=0x77f7b0e8)
at /home/adam/trees/php-src/5.4/Zend/zend_vm_execute.h:2592
#8  0x00a3935d in execute (op_array=0x77fb1d40)
at /home/adam/trees/php-src/5.4/Zend/zend_vm_execute.h:410
#9  0x009f8d57 in zend_execute_scripts (type=8, retval=0x0, 
file_count=3)
at /home/adam/trees/php-src/5.4/Zend/zend.c:1279
#10 0x0095f0e1 in php_execute_script (primary_file=0x7fffce60)
at /home/adam/trees/php-src/5.4/main/main.c:2473
#11 0x00b4b9c7 in do_cli (argc=5, argv=0x7fffe248)
at /home/adam/trees/php-src/5.4/sapi/cli/php_cli.c:988
#12 0x00b4cc4a in main (argc=5, argv=0x7fffe248)
at /home/adam/trees/php-src/5.4/sapi/cli/php_cli.c:1364

prepend_twotimes.php executes as described for me (with the double output from 
prepend_twotimes.php itself), then blocks on a read() syscall. The strace 
output is at https://gist.github.com/852ba3b100a4a7437e53


Previous Comments:

[2012-07-25 16:12:20] pierre at guinoiseau dot eu

Description:

Hello,

this bug may be related to bug #49000. php-cli crashes in interactive mode if 
you do an include() in auto_prepend_file. An example will explain it better 
(see 
test scripts):
  % php -d auto_prepend_file=prepend.php -a
  Interactive mode enabled
  
  test 1
  test 2
  Ran out of opcode space!
  You should probably consider writing this huge script into a file!

This was tested with PHP 5.4.5 (from ports) on FreeBSD 8.1 and PHP 5.4.4 (from 
Debian Git repository) on Ubuntu 12.04.

No error if the include file is missing (only the usual warning).

Also, I got another very weird case...
The provided prepend_segfault.php segfaults instead of the error above:
  % php -d auto_prepend_file=prepend_segfault.php -a
  Interactive shell
  
  test 1
  zsh: segmentation fault (core dumped)  php -d 
auto_prepend_file=prepend_segfault.php -a

But there is no segfault and no errors if I remove "$toto = 1".

If I replace one (or both) if/elseif conditions with true or false, it execute 
the script 2 times instead on 5.4.4 (and it segfaults on 5.4.5):
% php -d auto_prepend_file=prepend_towtimes.php -a
  Interactive shell
  
  test 1
  test 1 bis
  test 1
  test 1 bis
  test 2
  php > 

Of course if I remove the include() line, everything is back to normal.

Something is very wrong, isn't it? :)

Test script:
---
// prepend.php => weird error


// include.php


// prepend_segfault.php => segfaults


// prepend_towtimes.php => script is executed two times (5.4.4) or segfaults 
(5.4.5)



Expected result:

No weird behaviour and not segfaults when I use include() in an 
auto_prepend_file 
in interactive mode.







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=62661&edit=1

Bug #62303 [Opn->Fbk]: ReflectionClass, getMethods(), getName() empty

2012-07-25 Thread aharvey 
Edit report at https://bugs.php.net/bug.php?id=62303&edit=1

 ID: 62303
 Updated by: ahar...@php.net
 Reported by:v at roxori dot com
 Summary:ReflectionClass, getMethods(), getName() empty
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:Reflection related
 Operating System:   FreeBSD9
 PHP Version:5.4.3
 Block user comment: N
 Private report: N

 New Comment:

I also can't reproduce this. What extensions do you have loaded into PHP?


Previous Comments:

[2012-07-25 12:29:00] f...@php.net

Cannot reproduce.

$ php -v
PHP 5.4.4 (cli) (built: Jun 28 2012 15:38:36)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies

php testp.php
first
second


FreeBSD host.example.org 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan  3 
07:46:30 
UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64


[2012-06-13 08:06:38] v at roxori dot com

Another found that the index broken array, so that probably does not display a 
value.

PHP5.4.3  FreeBSD9
ReflectionMethod Object
(
[namei˜Ґ] => first
[class] => Foo
)
ReflectionMethod Object
(
[namei˜Ґ] => second
[class] => Foo
)

PHP5.4.3 Linux

ReflectionMethod Object
(
[name] => first
[class] => Foo
)
ReflectionMethod Object
(
[name] => second
[class] => Foo
)


[2012-06-12 22:51:40] ni...@php.net

I can't reproduce this: http://3v4l.org/6cvK8#v500

Seems to behave the same on all versions, with no change in between.

Maybe this is OS specific (or specific to something else in your env).


[2012-06-12 21:01:45] v at roxori dot com

Description:

After upgrading PHP to 5.4.3 no longer return the name of the method. 
Correspondingly, the library stopped working, namely Zend. Now the issue Fatal 
error: Uncaught exception 'Zend_Amf_Server_Exception' with message 'Duplicate 
method registered: Having sorted out, I realized that the code does not return 
the 
name of the method. In PHP 5.3 all was ok.

---
>From manual page: http://www.php.net/reflectionclass.getname#refsect1-
reflectionclass.getname-description
---

Test script:
---
class Foo {

function first(){

}

function second(){

}
}

$foo = new Foo();

$reflect = new ReflectionClass($foo);

$props   = $reflect->getMethods();

foreach ($props as $prop) {
print $prop->getName() . "\n";
}


Expected result:

first
second

Actual result:
--
(empty)






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=62303&edit=1

[PHP-BUG] Req #62663 [NEW]: Backtick operators are an ugly language construct

2012-07-25 Thread eldmannen+php at gmail dot com 
From: eldmannen+php at gmail dot com
Operating system: 
PHP version:  Irrelevant
Package:  Scripting Engine problem
Bug Type: Feature/Change Request
Bug description:Backtick operators are an ugly language construct

Description:

The backtick operator construct is an ugly construct.

The shell_exec() function should be used instead.

I propose the removal of the backtick operator construct.

Test script:
---



-- 
Edit bug report at https://bugs.php.net/bug.php?id=62663&edit=1
-- 
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=62663&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=62663&r=trysnapshot53
Try a snapshot (trunk):  
https://bugs.php.net/fix.php?id=62663&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=62663&r=fixed
Fixed in SVN and need be documented: 
https://bugs.php.net/fix.php?id=62663&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=62663&r=alreadyfixed
Need backtrace:  
https://bugs.php.net/fix.php?id=62663&r=needtrace
Need Reproduce Script:   
https://bugs.php.net/fix.php?id=62663&r=needscript
Try newer version:   
https://bugs.php.net/fix.php?id=62663&r=oldversion
Not developer issue: 
https://bugs.php.net/fix.php?id=62663&r=support
Expected behavior:   
https://bugs.php.net/fix.php?id=62663&r=notwrong
Not enough info: 
https://bugs.php.net/fix.php?id=62663&r=notenoughinfo
Submitted twice: 
https://bugs.php.net/fix.php?id=62663&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=62663&r=globals
PHP 4 support discontinued:  
https://bugs.php.net/fix.php?id=62663&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=62663&r=dst
IIS Stability:   
https://bugs.php.net/fix.php?id=62663&r=isapi
Install GNU Sed: 
https://bugs.php.net/fix.php?id=62663&r=gnused
Floating point limitations:  
https://bugs.php.net/fix.php?id=62663&r=float
No Zend Extensions:  
https://bugs.php.net/fix.php?id=62663&r=nozend
MySQL Configuration Error:   
https://bugs.php.net/fix.php?id=62663&r=mysqlcfg

Req #32100 [Com]: Request 'finally' support for exceptions

2012-07-25 Thread pravdin at vl dot ru 
Edit report at https://bugs.php.net/bug.php?id=32100&edit=1

 ID: 32100
 Comment by: pravdin at vl dot ru
 Reported by:ceefour at gauldong dot net
 Summary:Request 'finally' support for exceptions
 Status: Re-Opened
 Type:   Feature/Change Request
 Package:*General Issues
 Operating System:   *
 PHP Version:5.*
 Assigned To:laruence
 Block user comment: N
 Private report: N

 New Comment:

We are writing large web application on PHP using the OOP and programming 
patterns. Exceptions are not only error reporting mechanism but also very 
important program flow mechanism. So, try...finally is commonly needed. Please 
add 
this feature. I know, PHP is not OOP, but I think there is no reason to limit 
developers needs, especially when this needs are not for just a few single 
developers.


Previous Comments:

[2012-07-24 10:59:57] larue...@php.net

I will try to make a implemention.


[2012-07-18 23:13:07] pieceofchum at yahoo dot com

Hello I am a Java developer and would like to move over to PHP for my current 
personal projects. The use of finally in Java is extremely powerful as it 
ensures that a unit of work that uses any resources that need to be managed are 
guaranteed to be handled before leaving the method even whent here is a catch 
clause. This has nothing to do with control flow and exception handling it has 
everything to do with contract based blocks of code in fact finally is a 
totally unique construct which greatly simplifies algorithms where one needs a 
guarantee of certain code running (usually to handle external resources) no 
matter what happens outside of course of an error (error defined as something 
that breaks the interpreter/compiler/environmen). It is not a mistake of design 
but a vast improvement in code clarity and application of the DRY principle 
which is correct programming and has nothing at all to do with improper control 
flow. It is not a mistake that it is in some form in Python, Ruby, Java etc... 
Please please recondsider adding this extremely important construct to PHP. 

Thanks for your consideration in this matter


[2012-07-05 20:17:57] angelo at camargo dot ws

++ for finally in PHP


[2012-06-07 09:16:55] jl235 at kent dot ac dot uk

Most of the exceptions people come across in their PHP code tends to be for 
either File IO, or database access. Both of these need a finally to ensure the 
handle/connection/whatever gets closed, or dealt with in some other way. Using 
try/catch is already a lot more cumbersome then a world without Exceptions, but 
without finally, it adds a lot duplication and state management.

For example in my own code I do something along the lines of ...



$time = microtime( true );
$sql = generateSQLQuery();
$conn = openDBConnection();
$ex = null;

try {
$result = runSQLQuery( $conn, $sql );
} catch ( Exception $ex ) { /* do nothing */ }

closeDBConnection( $conn );
logSQLQuery( $sql, microtime(true) - $time );

if ( $ex !== null ) {
throw $ex;
}



... which could just be ...



$time = microtime( true );
$sql  = generateSQLQuery();
$conn = openDBConnection();

try {
$result = runSQLQuery( $conn, $sql );
} finally {
closeDBConnection( $conn );
logSQLQuery( $sql, microtime(true) - $time );
}



Simpler to write, easier to read, harder to get wrong, and more elegant.

Please re-open this.


[2012-06-05 11:19:41] sgnezdov at fastmail dot fm

Finally is absolutely necessary for proper management of disposable resources.

There is no easy to read workaround for

try { 
 causeException();
} finally {
 releaseResource();
}

others pointed out that solving this issue kills re-throw, which is equally 
important.




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

https://bugs.php.net/bug.php?id=32100


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=32100&edit=1

Bug #62444 [Com]: Handle leak in is_readable

2012-07-25 Thread smiles_indonesia at yahoo dot co dot id 
Edit report at https://bugs.php.net/bug.php?id=62444&edit=1

 ID: 62444
 Comment by: smiles_indonesia at yahoo dot co dot id
 Reported by:sergio dot nalin at gmail dot com
 Summary:Handle leak in is_readable
 Status: Open
 Type:   Bug
 Package:Filesystem function related
 Operating System:   Win 7 64bit
 PHP Version:5.3.14
 Block user comment: N
 Private report: N

 New Comment:

It seems happened since introduction of php 5.3.0. If you see in the changelogs:

http://www.php.net/ChangeLog-5.php

Added support for ACL (is_writable, is_readable, reports now correct results) 
on Windows. (Pierre, Venkat Raman Don, Kanwaljeet Singla)

This issue is very critical, because it makes php running on windows production 
server impractical / unusable...

My quad xeon box becomes very slow after some days, the ram usage is 
mysteriously increased (httpd process usage still remains the same, I thought 
handle consumes kernel spaces)...

If your webserver servers 1 million request, then there will be about 1 million 
handle opened... Usual application only consumes 20 to 2000 handles...


Previous Comments:

[2012-06-29 00:10:17] sergio dot nalin at gmail dot com

Description:

PHP vc9 5.3.14, thread safe version + Apache Httpd 2.2.22 + Win 7/Win Server 
2008 
R2

Each time is_readable in invoked, it leaves an open handle in the httpd process.



Test script:
---
for($i=0; $i<100;$i++) {
  is_readable("c:\\temp");
}

NOTE: the folder/file must exist for the leak to happen.

Expected result:

No leaked handles

Actual result:
--
100 leaked handles






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=62444&edit=1

Req #62662 [Com]: ArrayObject applied deep inside the array

2012-07-25 Thread klaussantana at gmail dot com 
Edit report at https://bugs.php.net/bug.php?id=62662&edit=1

 ID: 62662
 Comment by: klaussantana at gmail dot com
 Reported by:klaussantana at gmail dot com
 Summary:ArrayObject applied deep inside the array
 Status: Open
 Type:   Feature/Change Request
 Package:SPL related
 Operating System:   All
 PHP Version:Irrelevant
 Block user comment: N
 Private report: N

 New Comment:

The example above is a simple case to show that it not work.

The new flag would unleash a tons of possibilities of application like when 
you're 
mapping a database with object orientation.

database->table->column; ?>


Previous Comments:

[2012-07-25 19:10:44] klaussantana at gmail dot com

Description:

New flag to ArrayObject: DEEP_CONVERSION.

This flag would make ArrayObject inspect the array $input indexes for others 
arrays and also instantiate an ArrayObject with the index array also with the 
same 
$flags and the same $iterator_class.

Test script:
---
matrix->matrix[0][1][0];

?>

Expected result:

string

Actual result:
--
(!) Notice: Trying to get property of non-object in D:\WWW\sandbox.php on line 
32






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=62662&edit=1

[PHP-BUG] Req #62662 [NEW]: ArrayObject applied deep inside the array

2012-07-25 Thread klaussantana at gmail dot com 
From: klaussantana at gmail dot com
Operating system: All
PHP version:  Irrelevant
Package:  SPL related
Bug Type: Feature/Change Request
Bug description:ArrayObject applied deep inside the array

Description:

New flag to ArrayObject: DEEP_CONVERSION.

This flag would make ArrayObject inspect the array $input indexes for
others 
arrays and also instantiate an ArrayObject with the index array also with
the same 
$flags and the same $iterator_class.

Test script:
---
matrix->matrix[0][1][0];

?>

Expected result:

string

Actual result:
--
(!) Notice: Trying to get property of non-object in D:\WWW\sandbox.php on
line 32

-- 
Edit bug report at https://bugs.php.net/bug.php?id=62662&edit=1
-- 
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=62662&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=62662&r=trysnapshot53
Try a snapshot (trunk):  
https://bugs.php.net/fix.php?id=62662&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=62662&r=fixed
Fixed in SVN and need be documented: 
https://bugs.php.net/fix.php?id=62662&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=62662&r=alreadyfixed
Need backtrace:  
https://bugs.php.net/fix.php?id=62662&r=needtrace
Need Reproduce Script:   
https://bugs.php.net/fix.php?id=62662&r=needscript
Try newer version:   
https://bugs.php.net/fix.php?id=62662&r=oldversion
Not developer issue: 
https://bugs.php.net/fix.php?id=62662&r=support
Expected behavior:   
https://bugs.php.net/fix.php?id=62662&r=notwrong
Not enough info: 
https://bugs.php.net/fix.php?id=62662&r=notenoughinfo
Submitted twice: 
https://bugs.php.net/fix.php?id=62662&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=62662&r=globals
PHP 4 support discontinued:  
https://bugs.php.net/fix.php?id=62662&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=62662&r=dst
IIS Stability:   
https://bugs.php.net/fix.php?id=62662&r=isapi
Install GNU Sed: 
https://bugs.php.net/fix.php?id=62662&r=gnused
Floating point limitations:  
https://bugs.php.net/fix.php?id=62662&r=float
No Zend Extensions:  
https://bugs.php.net/fix.php?id=62662&r=nozend
MySQL Configuration Error:   
https://bugs.php.net/fix.php?id=62662&r=mysqlcfg

Bug #62653 [Com]: unset($array[$float]) causes a crash

2012-07-25 Thread ni...@php.net 
Edit report at https://bugs.php.net/bug.php?id=62653&edit=1

 ID: 62653
 Comment by: ni...@php.net
 Reported by:davidso1 at rose-hulman dot edu
 Summary:unset($array[$float]) causes a crash
 Status: Open
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Windows Server
 PHP Version:5.4.5
 Block user comment: N
 Private report: N

 New Comment:

I have a patch for this here: https://github.com/php/php-src/pull/144

If you could test whether it fixes the issue for you it would help a lot.

We had some issues reproducing the problem consistently, so would be nice to 
verify this :)


Previous Comments:

[2012-07-25 15:55:10] jpa...@php.net

Switch to Scripting Engine Problem as bug type


[2012-07-25 13:40:44] larue...@php.net

I can no reproduce this on Linux redhat


[2012-07-24 19:27:22] s...@php.net

The testcase produces invalid reads & writes in valgrind.


[2012-07-24 16:16:05] davidso1 at rose-hulman dot edu

Description:

The test code crashes apache in the 5.4+ environment.
$foo starts as a string, gets interpreted as a double but it isn't I guess.

unset($array[(double) $foo]) works as expected

Test script:
---
$array = array("5"=>"bar");
$foo = "10."; // gettype($foo) = "string"
$foo /= 2; //Makes $foo = 5 but still gettype($foo) = "double"
unset($array[$foo]);
print_r($array);

Expected result:

Array()

Actual result:
--
Error 101 (net::ERR_CONNECTION_RESET): The connection was reset.






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=62653&edit=1

[PHP-BUG] Bug #62661 [NEW]: Interactive php-cli crashes if include() is used in auto_prepend_file

2012-07-25 Thread pierre at guinoiseau dot eu 
From: pierre at guinoiseau dot eu
Operating system: FreeBSD / Ubuntu
PHP version:  5.4.5
Package:  Reproducible crash
Bug Type: Bug
Bug description:Interactive php-cli crashes if include() is used in 
auto_prepend_file

Description:

Hello,

this bug may be related to bug #49000. php-cli crashes in interactive mode
if 
you do an include() in auto_prepend_file. An example will explain it better
(see 
test scripts):
  % php -d auto_prepend_file=prepend.php -a
  Interactive mode enabled
  
  test 1
  test 2
  Ran out of opcode space!
  You should probably consider writing this huge script into a file!

This was tested with PHP 5.4.5 (from ports) on FreeBSD 8.1 and PHP 5.4.4
(from 
Debian Git repository) on Ubuntu 12.04.

No error if the include file is missing (only the usual warning).

Also, I got another very weird case...
The provided prepend_segfault.php segfaults instead of the error above:
  % php -d auto_prepend_file=prepend_segfault.php -a
  Interactive shell
  
  test 1
  zsh: segmentation fault (core dumped)  php -d 
auto_prepend_file=prepend_segfault.php -a

But there is no segfault and no errors if I remove "$toto = 1".

If I replace one (or both) if/elseif conditions with true or false, it
execute 
the script 2 times instead on 5.4.4 (and it segfaults on 5.4.5):
% php -d auto_prepend_file=prepend_towtimes.php -a
  Interactive shell
  
  test 1
  test 1 bis
  test 1
  test 1 bis
  test 2
  php > 

Of course if I remove the include() line, everything is back to normal.

Something is very wrong, isn't it? :)

Test script:
---
// prepend.php => weird error


// include.php


// prepend_segfault.php => segfaults


// prepend_towtimes.php => script is executed two times (5.4.4) or
segfaults (5.4.5)



Expected result:

No weird behaviour and not segfaults when I use include() in an
auto_prepend_file 
in interactive mode.


-- 
Edit bug report at https://bugs.php.net/bug.php?id=62661&edit=1
-- 
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=62661&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=62661&r=trysnapshot53
Try a snapshot (trunk):  
https://bugs.php.net/fix.php?id=62661&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=62661&r=fixed
Fixed in SVN and need be documented: 
https://bugs.php.net/fix.php?id=62661&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=62661&r=alreadyfixed
Need backtrace:  
https://bugs.php.net/fix.php?id=62661&r=needtrace
Need Reproduce Script:   
https://bugs.php.net/fix.php?id=62661&r=needscript
Try newer version:   
https://bugs.php.net/fix.php?id=62661&r=oldversion
Not developer issue: 
https://bugs.php.net/fix.php?id=62661&r=support
Expected behavior:   
https://bugs.php.net/fix.php?id=62661&r=notwrong
Not enough info: 
https://bugs.php.net/fix.php?id=62661&r=notenoughinfo
Submitted twice: 
https://bugs.php.net/fix.php?id=62661&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=62661&r=globals
PHP 4 support discontinued:  
https://bugs.php.net/fix.php?id=62661&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=62661&r=dst
IIS Stability:   
https://bugs.php.net/fix.php?id=62661&r=isapi
Install GNU Sed: 
https://bugs.php.net/fix.php?id=62661&r=gnused
Floating point limitations:  
https://bugs.php.net/fix.php?id=62661&r=float
No Zend Extensions:  
https://bugs.php.net/fix.php?id=62661&r=nozend
MySQL Configuration Error:   
https://bugs.php.net/fix.php?id=62661&r=mysqlcfg

Bug #62653 [Opn]: unset($array[$float]) causes a crash

2012-07-25 Thread jpauli 
Edit report at https://bugs.php.net/bug.php?id=62653&edit=1

 ID: 62653
 Updated by: jpa...@php.net
 Reported by:davidso1 at rose-hulman dot edu
 Summary:unset($array[$float]) causes a crash
 Status: Open
 Type:   Bug
-Package:Apache2 related
+Package:Scripting Engine problem
 Operating System:   Windows Server
 PHP Version:5.4.5
 Block user comment: N
 Private report: N

 New Comment:

Switch to Scripting Engine Problem as bug type


Previous Comments:

[2012-07-25 13:40:44] larue...@php.net

I can no reproduce this on Linux redhat


[2012-07-24 19:27:22] s...@php.net

The testcase produces invalid reads & writes in valgrind.


[2012-07-24 16:16:05] davidso1 at rose-hulman dot edu

Description:

The test code crashes apache in the 5.4+ environment.
$foo starts as a string, gets interpreted as a double but it isn't I guess.

unset($array[(double) $foo]) works as expected

Test script:
---
$array = array("5"=>"bar");
$foo = "10."; // gettype($foo) = "string"
$foo /= 2; //Makes $foo = 5 but still gettype($foo) = "double"
unset($array[$foo]);
print_r($array);

Expected result:

Array()

Actual result:
--
Error 101 (net::ERR_CONNECTION_RESET): The connection was reset.






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=62653&edit=1

[PHP-BUG] Bug #62660 [NEW]: PHP error logging with FPM fails to display an IP address and correct time

2012-07-25 Thread joe at cirkuit dot net 
From: joe at cirkuit dot net
Operating system: FreeBSD 8.1
PHP version:  5.3.15
Package:  FPM related
Bug Type: Bug
Bug description:PHP error logging with FPM fails to display an IP address and 
correct time

Description:

This only happens under a specific condition. If the error_log file being
written 
to is world readable/writable (didn't test other cases), then any php 
errors/warnings/notices that are logged have no IP address and have a UTC 
timestamp.

Changing permissions from 777 to 644 resolves this issue.

I know the error log should probably never be world writable, but it's
strange how 
strengthening the permissions caused the IP and correct timestamp log
correctly.

Test script:
---
chmod 777 /usr/local/apache/logs/error_log
[create any php script that produces an error or notice]
[run the php script via www (using fastcgi, not sure if this matters)]
tail /usr/local/apache/logs/error_log

fixed when:
chmod 644 /usr/local/apache/logs/error_log


-- 
Edit bug report at https://bugs.php.net/bug.php?id=62660&edit=1
-- 
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=62660&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=62660&r=trysnapshot53
Try a snapshot (trunk):  
https://bugs.php.net/fix.php?id=62660&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=62660&r=fixed
Fixed in SVN and need be documented: 
https://bugs.php.net/fix.php?id=62660&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=62660&r=alreadyfixed
Need backtrace:  
https://bugs.php.net/fix.php?id=62660&r=needtrace
Need Reproduce Script:   
https://bugs.php.net/fix.php?id=62660&r=needscript
Try newer version:   
https://bugs.php.net/fix.php?id=62660&r=oldversion
Not developer issue: 
https://bugs.php.net/fix.php?id=62660&r=support
Expected behavior:   
https://bugs.php.net/fix.php?id=62660&r=notwrong
Not enough info: 
https://bugs.php.net/fix.php?id=62660&r=notenoughinfo
Submitted twice: 
https://bugs.php.net/fix.php?id=62660&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=62660&r=globals
PHP 4 support discontinued:  
https://bugs.php.net/fix.php?id=62660&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=62660&r=dst
IIS Stability:   
https://bugs.php.net/fix.php?id=62660&r=isapi
Install GNU Sed: 
https://bugs.php.net/fix.php?id=62660&r=gnused
Floating point limitations:  
https://bugs.php.net/fix.php?id=62660&r=float
No Zend Extensions:  
https://bugs.php.net/fix.php?id=62660&r=nozend
MySQL Configuration Error:   
https://bugs.php.net/fix.php?id=62660&r=mysqlcfg

Bug #62420 [Wfx]: Exception::__toString() creates message in wrong order if prev exception exists

2012-07-25 Thread bugs dot php at mohiva dot com 
Edit report at https://bugs.php.net/bug.php?id=62420&edit=1

 ID: 62420
 User updated by:bugs dot php at mohiva dot com
 Reported by:bugs dot php at mohiva dot com
 Summary:Exception::__toString() creates message in wrong
 order if prev exception exists
 Status: Wont fix
 Type:   Bug
 Package:*General Issues
 Operating System:   Gentoo Linux
 PHP Version:5.4.4
 Block user comment: N
 Private report: N

 New Comment:

I think with this behaviour it is really hard to find bugs and it has a huge 
WTF factor when you look into your log files and then you see the exception 
messages in a reverse order.

Is it really too hard to fix?


Previous Comments:

[2012-07-24 08:28:41] f...@php.net

While you are correct that it might be more logical to reverse the order, this 
isn't a huge problem.


[2012-06-26 11:56:09] bugs dot php at mohiva dot com

Description:

The method Exception::__toString() creates the message in the wrong order if a 
previous exception exists in the Exception object.

The message contains the message from the previous exception as first and then 
marked as next exception the message from the exception object itself. Normally 
the message from the current exception should be the first message followed by 
the previous message and so one.

Test script:
---
getPrevious()->getMessage() . '';
echo 'Current:' . $current->getMessage() . '';
echo 'String:' . $current->__toString() . '';
}


Expected result:

Previous: Previous exception
--
Current: Current exception
--
String: exception 'Exception' with message 'Current exception' in 
exception.php:4 Stack trace: #0 {main} Next exception 'Exception' with message 
'Previous exception' in exception.php:6 Stack trace: #0 {main}

Actual result:
--
Previous: Previous exception
--
Current: Current exception
--
String: exception 'Exception' with message 'Previous exception' in 
exception.php:4 Stack trace: #0 {main} Next exception 'Exception' with message 
'Current exception' in exception.php:6 Stack trace: #0 {main}






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=62420&edit=1

Bug #62653 [Opn]: unset(array($foo)) crashes apache depending on $foo

2012-07-25 Thread laruence 
Edit report at https://bugs.php.net/bug.php?id=62653&edit=1

 ID: 62653
 Updated by: larue...@php.net
 Reported by:davidso1 at rose-hulman dot edu
 Summary:unset(array($foo)) crashes apache depending on $foo
 Status: Open
 Type:   Bug
 Package:Apache2 related
 Operating System:   Windows Server
 PHP Version:5.4.5
 Block user comment: N
 Private report: N

 New Comment:

I can no reproduce this on Linux redhat


Previous Comments:

[2012-07-24 19:27:22] s...@php.net

The testcase produces invalid reads & writes in valgrind.


[2012-07-24 16:16:05] davidso1 at rose-hulman dot edu

Description:

The test code crashes apache in the 5.4+ environment.
$foo starts as a string, gets interpreted as a double but it isn't I guess.

unset($array[(double) $foo]) works as expected

Test script:
---
$array = array("5"=>"bar");
$foo = "10."; // gettype($foo) = "string"
$foo /= 2; //Makes $foo = 5 but still gettype($foo) = "double"
unset($array[$foo]);
print_r($array);

Expected result:

Array()

Actual result:
--
Error 101 (net::ERR_CONNECTION_RESET): The connection was reset.






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=62653&edit=1

Bug #62076 [Opn->Wfx]: Global/namespace constants are not hoisted

2012-07-25 Thread fa 
Edit report at https://bugs.php.net/bug.php?id=62076&edit=1

 ID: 62076
 Updated by: f...@php.net
 Reported by:phplists at stanvassilev dot com
 Summary:Global/namespace constants are not hoisted
-Status: Open
+Status: Wont fix
 Type:   Bug
 Package:Scripting Engine problem
 PHP Version:5.4.3
 Block user comment: N
 Private report: N

 New Comment:

You can still assign a define()d constant to const, so the argument is kind of 
moot imho. 

See example below:




which yields:

PHP Notice:  Use of undefined constant NOT_HOISTED - assumed 'NOT_HOISTED' in 
b62076.php on line 14
PHP Notice:  Use of undefined constant XXX - assumed 'XXX' in b62076.php on 
line 
14
NOT_HOISTED XXX
asdf.2 asdf.2


Previous Comments:

[2012-05-20 10:40:18] phplists at stanvassilev dot com

My full argument why const should be hoisted, while define() can't and 
shouldn't 
be:

const FOO = val; is a construct that doesn't depend on runtime conditions, much 
like class constants. It can't accept expressions, variables and can't be 
placed 
in conditional blocks, while define() is a function call that can accept 
variables and expressions and be placed in conditional blocks.

Therefore regardless of their opcode implementation, they are exposed in a 
fundamentally 
different way, and define() hoisting isn't expected while const hoisting is 
expected (as 
a static declaration, and similar to class const declaration, their position in 
the class DOES NOT matter).

Therefore I believe const should act like class constants, and not like 
define(), as this matches user expectations better.


[2012-05-20 10:28:28] phplists at stanvassilev dot com

Description:

"const" Declarations outside a class were introduced in PHP 5.3, and they only 
support static "compile-time" expressions, unlike define().

Function and classes declarations are hoisted to the top of the file, so you 
can 
call them before the line they are defined in. This doesn't happen 
with "const", although it's expected as a matter of consistency. This leads to 
the following odd problem: 

https://bugs.php.net/bug.php?id=62076&edit=1

Bug #62634 [Opn]: Incorrect serialization with circular references

2012-07-25 Thread fa 
Edit report at https://bugs.php.net/bug.php?id=62634&edit=1

 ID: 62634
 Updated by: f...@php.net
 Reported by:phplists at stanvassilev dot com
 Summary:Incorrect serialization with circular references
 Status: Open
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   Any
 PHP Version:5.4.5
 Block user comment: N
 Private report: N

 New Comment:

Maybe related to https://bugs.php.net/bug.php?id=62189


Previous Comments:

[2012-07-22 21:58:45] phplists at stanvassilev dot com

There's a small error in my code example, please replace this line:

$duplicate = unserialize(serialize($x));

With this line:

$duplicate = unserialize(serialize($original));


[2012-07-22 21:54:54] phplists at stanvassilev dot com

Description:

The documentation says references and circular references should serialize 
properly. I've found that serialize would first copy the referenced variable, 
before detecting the reference.

This not only doubles the serialized output, but produced incorrect copy when 
unserialized.

Test script:
---
$original = array('hello');
$original[] = & $original;

echo serialize($original);
// Output (notice the duplication):
// "a:2:{i:0;s:5:"hello";i:1;a:2:{i:0;s:5:"hello";i:1;R:3;}}"

$duplicate = unserialize(serialize($x));

// Now I modify both the original and the duplicate in an identical way.
// But I get different results, because the duplicate points to a copy of
// itself, instead of pointing to itself.

$original[0] = 'world';
$duplicate[0] = 'world';

var_dump($original);
// Produces (notice it says "world" both times, i.e. it points to itself):
// array(2) { [0]=> string(5) "world" [1]=> &array(2) { [0]=> string(5) "world" 
[1]=> *RECURSION* } } 

var_dump($duplicate);
// Produces (notice the second time it says "hello" i.e. it's a copy):
// array(2) { [0]=> string(5) "world" [1]=> &array(2) { [0]=> string(5) "hello" 
[1]=> *RECURSION* } }

Expected result:

There should be NO copies of "hello" left:

array(2) { [0]=> string(5) "world" [1]=> &array(2) { [0]=> string(5) "world" 
[1]=> 
*RECURSION* } }

There should be NO duplication in the serialized output:

"a:2:{i:0;s:5:"hello";i:1;???;}" (Fill-in the "???" appropriately :) )

Actual result:
--
A copy of "hello" is left:

array(2) { [0]=> string(5) "world" [1]=> &array(2) { [0]=> string(5) "hello" 
[1]=> 
*RECURSION* } }

There is duplication in the serialized output:

"a:2:{i:0;s:5:"hello";i:1;a:2:{i:0;s:5:"hello";i:1;R:3;}}"






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=62634&edit=1

Bug #62303 [Opn]: ReflectionClass, getMethods(), getName() empty

2012-07-25 Thread fa 
Edit report at https://bugs.php.net/bug.php?id=62303&edit=1

 ID: 62303
 Updated by: f...@php.net
 Reported by:v at roxori dot com
 Summary:ReflectionClass, getMethods(), getName() empty
 Status: Open
 Type:   Bug
 Package:Reflection related
 Operating System:   FreeBSD9
 PHP Version:5.4.3
 Block user comment: N
 Private report: N

 New Comment:

Cannot reproduce.

$ php -v
PHP 5.4.4 (cli) (built: Jun 28 2012 15:38:36)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies

php testp.php
first
second


FreeBSD host.example.org 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan  3 
07:46:30 
UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64


Previous Comments:

[2012-06-13 08:06:38] v at roxori dot com

Another found that the index broken array, so that probably does not display a 
value.

PHP5.4.3  FreeBSD9
ReflectionMethod Object
(
[namei˜Ґ] => first
[class] => Foo
)
ReflectionMethod Object
(
[namei˜Ґ] => second
[class] => Foo
)

PHP5.4.3 Linux

ReflectionMethod Object
(
[name] => first
[class] => Foo
)
ReflectionMethod Object
(
[name] => second
[class] => Foo
)


[2012-06-12 22:51:40] ni...@php.net

I can't reproduce this: http://3v4l.org/6cvK8#v500

Seems to behave the same on all versions, with no change in between.

Maybe this is OS specific (or specific to something else in your env).


[2012-06-12 21:01:45] v at roxori dot com

Description:

After upgrading PHP to 5.4.3 no longer return the name of the method. 
Correspondingly, the library stopped working, namely Zend. Now the issue Fatal 
error: Uncaught exception 'Zend_Amf_Server_Exception' with message 'Duplicate 
method registered: Having sorted out, I realized that the code does not return 
the 
name of the method. In PHP 5.3 all was ok.

---
>From manual page: http://www.php.net/reflectionclass.getname#refsect1-
reflectionclass.getname-description
---

Test script:
---
class Foo {

function first(){

}

function second(){

}
}

$foo = new Foo();

$reflect = new ReflectionClass($foo);

$props   = $reflect->getMethods();

foreach ($props as $prop) {
print $prop->getName() . "\n";
}


Expected result:

first
second

Actual result:
--
(empty)






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=62303&edit=1

Bug #62627 [Opn->Fbk]: Zlib output handler enabled randomly

2012-07-25 Thread laruence 
Edit report at https://bugs.php.net/bug.php?id=62627&edit=1

 ID: 62627
 Updated by: larue...@php.net
 Reported by:roctom at gmail dot com
 Summary:Zlib output handler enabled randomly
-Status: Open
+Status: Feedback
 Type:   Bug
 Package:*Compression related
 Operating System:   Debian 2.6.32-5-xen-amd64
 PHP Version:5.4.5
 Block user comment: N
 Private report: N

 New Comment:

Please try using this snapshot:

  http://snaps.php.net/php-trunk-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/

a bug #55544  has been fixed recently, please try with the snapshot


Previous Comments:

[2012-07-25 08:42:59] indey...@php.net

experienced the same on 5.4.4, CentOS/6.3


[2012-07-21 05:08:48] roctom at gmail dot com

Description:

Having upgraded from 5.4.0 to 5.4.5, I now get the zlib output compression 
handler 
as part of ob_list_handlers() randomly which generates issues with ob_start().

zlib.output_compression is set to off.

'./configure' '--sysconfdir=/etc' '--with-config-file-path=/etc' '--with-config-
file-scan-dir=/etc/php.d' '--with-apxs2=/usr/sbin/apxs' '--with-openssl' 
'--with-
gd' '--with-curl=/usr/src/curl-7.21.7/include' '--with-zlib' 
'--enable-calendar' 
'--enable-mbstring' '--enable-zip' '--enable-sockets' '--with-mcrypt' '--with-
mysql=mysqlnd' '--with-mysqli=mysqlnd' '--with-pdo-mysql=mysqlnd' '--with-
kerberos' '--enable-ftp' '--disable-posix' '--enable-bcmath' 
'--enable-gd-native-
ttf' '--with-freetype-dir' '--with-jpeg-dir=/usr/local' '--with-png-
dir=/usr/local' '--with-xsl=/usr/local/lib' '--enable-exif'

Test script:
---
 default output handler
)

Array
(
[0] => ob_gzhandler
)

Array
(
[0] => default output handler
)

Actual result:
--
First execution (in browser)
Array
(
[0] => default output handler
)
Array
(
[0] => ob_gzhandler
)
Array
(
[0] => 
)

Second execution (in browser)
Firefox 16.1a
Array
(
[0] => default output handler
[1] => zlib output compression
)


Chrome 2.0.1132.57
Array
(
[0] => default output handler
[1] => zlib output compression
)
‹s,*J¬äÒàR‚hƒX[;…”Ô´ÄÒœ…üÒ’‚Ò…ŒÄ¼”œÔ"ˆ
C°Šü¤øô*˜¸&HùÓàDArray
(
[0] => default output handler
[1] => 
)






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=62627&edit=1

[PHP-BUG] Bug #62658 [NEW]: When enable –with-curlwrappers option, stream_get_contents() may cpu 100%

2012-07-25 Thread sopl dot wang at gmail dot com 
From: sopl dot wang at gmail dot com
Operating system: ALL
PHP version:  master-Git-2012-07-25 (Git)
Package:  cURL related
Bug Type: Bug
Bug description:When enable –with-curlwrappers option, stream_get_contents() 
may cpu 100%

Description:

When enable `–with-curlwrappers` option, with http(s)/ftp(s)/other
curl-wrapped 
stream protocols, file_get_contents(), stream_get_contents() and alike
functions 
may lead consume 100% cpu cycle on waiting for receive.

When `strace` problem php process, following will be develop:


select(7, [6], [6], [], {15, 0})= 1 (out [6], left {15, 0})
poll([{fd=6, events=POLLIN}], 1, 0) = 0 (Timeout)
select(7, [6], [6], [], {15, 0})= 1 (out [6], left {15, 0})
poll([{fd=6, events=POLLIN}], 1, 0) = 0 (Timeout)
select(7, [6], [6], [], {15, 0})= 1 (out [6], left {15, 0})
poll([{fd=6, events=POLLIN}], 1, 0) = 0 (Timeout)
select(7, [6], [6], [], {15, 0})= 1 (out [6], left {15, 0})
poll([{fd=6, events=POLLIN}], 1, 0) = 0 (Timeout)
select(7, [6], [6], [], {15, 0})= 1 (out [6], left {15, 0})
poll([{fd=6, events=POLLIN}], 1, 0) = 0 (Timeout)
select(7, [6], [6], [], {15, 0})= 1 (out [6], left {15, 0})
poll([{fd=6, events=POLLIN}], 1, 0) = 0 (Timeout)
select(7, [6], [6], [], {15, 0})= 1 (out [6], left {15, 0})
poll([{fd=6, events=POLLIN}], 1, 0) = 0 (Timeout)
select(7, [6], [6], [], {15, 0})= 1 (out [6], left {15, 0})
poll([{fd=6, events=POLLIN}], 1, 0) = 0 (Timeout)
select(7, [6], [6], [], {15, 0})= 1 (out [6], left {15, 0})
poll([{fd=6, events=POLLIN}], 1, 0) = 0 (Timeout)
select(7, [6], [6], [], {15, 0})= 1 (out [6], left {15, 0})
poll([{fd=6, events=POLLIN}], 1, 0) = 0 (Timeout)


The reason we found is in 'ext/curl/streams.c', function
php_curl_stream_read(), 
line 174:


  select(curlstream->maxfd + 1, &curlstream->readfds,
&curlstream->writefds, 
&curlstream->excfds, &tv)


When select(), `writefds` always can write and immediate return, no block
at 
here and, upper module will detect that no data could read and re-invoke
this 
function (`php_curl_stream_read()`), a nonblock loop, lead this consume
100% cpu 
bug.

If the link very slow, this 100% cpu problem may take the system load very
high.

Test script:
---
Enable `–with-curlwrappers` and test:


http://soplwang.com');


Expected result:

Expect the behavior like native php does…

When `strace`, native php generate:


poll([{fd=3, events=POLLIN|POLLERR|POLLHUP}], 1, 6) = 1 ([{fd=3, 
revents=POLLIN}])


Actual result:
--
When `strace`, generate:


select(4, [3], [3], [], {15, 0})= 1 (out [3], left {15, 0})
poll([{fd=3, events=POLLIN}], 1, 0) = 0 (Timeout)
select(4, [3], [3], [], {15, 0})= 1 (out [3], left {15, 0})
poll([{fd=3, events=POLLIN}], 1, 0) = 0 (Timeout)
select(4, [3], [3], [], {15, 0})= 1 (out [3], left {15, 0})
poll([{fd=3, events=POLLIN}], 1, 0) = 0 (Timeout)
select(4, [3], [3], [], {15, 0})= 1 (out [3], left {15, 0})
poll([{fd=3, events=POLLIN}], 1, 0) = 0 (Timeout)
select(4, [3], [3], [], {15, 0})= 1 (out [3], left {15, 0})
poll([{fd=3, events=POLLIN}], 1, 0) = 0 (Timeout)
...


-- 
Edit bug report at https://bugs.php.net/bug.php?id=62658&edit=1
-- 
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=62658&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=62658&r=trysnapshot53
Try a snapshot (trunk):  
https://bugs.php.net/fix.php?id=62658&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=62658&r=fixed
Fixed in SVN and need be documented: 
https://bugs.php.net/fix.php?id=62658&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=62658&r=alreadyfixed
Need backtrace:  
https://bugs.php.net/fix.php?id=62658&r=needtrace
Need Reproduce Script:   
https://bugs.php.net/fix.php?id=62658&r=needscript
Try newer version:   
https://bugs.php.net/fix.php?id=62658&r=oldversion
Not developer issue: 
https://bugs.php.net/fix.php?id=62658&r=support
Expected behavior:   
https://bugs.php.net/fix.php?id=62658&r=notwrong
Not enough info: 
https://bugs.php.net/fix.php?id=62658&r=notenoughinfo
Submitted twice: 
https://bugs.php.net/fix.php?id=62658&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=62658&r=globals
PHP 4 support discontinued:  
https://bugs.php.net/fix.php?id=62658&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=62658&r=dst
IIS Stability:   
https://bugs.php.net/fix.php?id=62658&r=isapi
Install GNU Sed: 
https://bugs.php.net/fix.php?id=62658&r=gnused
Floating point limitations:  
http

Bug #30355 [Com]: Weird Behaviour calling non-static method statically

2012-07-25 Thread baptiste33 at gmail dot com 
Edit report at https://bugs.php.net/bug.php?id=30355&edit=1

 ID: 30355
 Comment by: baptiste33 at gmail dot com
 Reported by:info at rhalff dot com
 Summary:Weird Behaviour calling non-static method statically
 Status: Wont fix
 Type:   Bug
 Package:Scripting Engine problem
 Operating System:   *
 PHP Version:5.0.2
 Block user comment: N
 Private report: N

 New Comment:

A few years later.. It's it planned to keep this "bug" as the documentation 
still 
says :

"Calling non-static methods statically generates an E_STRICT level warning."

Which is obviously not true.


Previous Comments:

[2011-02-03 14:51:26] carlos dot vini at gmail dot com

This bug can be exploited for creating a kind of "multiple inheritance":

name;   
}
public function getPosition() {
return '- Air.';
}
}

class Car {
public function getName() {
return 'Car ' . $this->name;
}
public function getPosition() {
return '- Ground.';
}
}

class FlyingCar extends Car {
public function getName() {
return Airplane::getName();
}
}

$a = new FlyingCar();
$a->name = 'Example';
echo $a->getName();
echo $a->getPosition();
?>

Expected result:

$this does not exist in a static context


Actual result:
---
It echoes: Airplane Example - Ground.


[2004-10-08 21:14:33] he...@php.net

For BC reasons calling a non static method statically keeps $this. 

This is not my decision - often enough i suggested to fix static member 
behavior now that we can declare them in PHP 5. If you ask me there is no OO in 
PHP 4 and hence we should never have taken care of BC with 4.


[2004-10-08 08:55:39] der...@php.net

Marcus, can you explain why there is no bug here?


[2004-10-07 22:51:52] info at rhalff dot com

Description:

I think the behaviour below is allready known and it can be fixed declaring the 
method 'static', however I still think this is a bug. The script should fail 
instead of continuing incorrect behaviour.

Related to Bug #9005, #12622, #20089, #25220, #29206

Because $this behaviour was allready there in 2001, I thought $this would be a 
good reminder $this feature is still present in 5.0.2


Reproduce code:
---
setValue('huh?');
}

public function test2()
{   
$this->nonExistent();
}

}   

class B {

public function test()
{   
A::test();
}
public function setValue($v)
{   
echo "$v";
}

public function test2()
{   
A::test2();
}



}

$B = new B;
$B->test();
$B->test2();


?>

Expected result:

script should fail, cannot call a non-static method statically.




Actual result:
--
huh?
Fatal error: Call to undefined method B::nonExistent() in 
/var/www/hosts/gedicht.nu/docs/static/test.php on line 12






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=30355&edit=1

Bug #62627 [Com]: Zlib output handler enabled randomly

2012-07-25 Thread indey...@php.net 
Edit report at https://bugs.php.net/bug.php?id=62627&edit=1

 ID: 62627
 Comment by: indey...@php.net
 Reported by:roctom at gmail dot com
 Summary:Zlib output handler enabled randomly
 Status: Open
 Type:   Bug
 Package:*Compression related
 Operating System:   Debian 2.6.32-5-xen-amd64
 PHP Version:5.4.5
 Block user comment: N
 Private report: N

 New Comment:

experienced the same on 5.4.4, CentOS/6.3


Previous Comments:

[2012-07-21 05:08:48] roctom at gmail dot com

Description:

Having upgraded from 5.4.0 to 5.4.5, I now get the zlib output compression 
handler 
as part of ob_list_handlers() randomly which generates issues with ob_start().

zlib.output_compression is set to off.

'./configure' '--sysconfdir=/etc' '--with-config-file-path=/etc' '--with-config-
file-scan-dir=/etc/php.d' '--with-apxs2=/usr/sbin/apxs' '--with-openssl' 
'--with-
gd' '--with-curl=/usr/src/curl-7.21.7/include' '--with-zlib' 
'--enable-calendar' 
'--enable-mbstring' '--enable-zip' '--enable-sockets' '--with-mcrypt' '--with-
mysql=mysqlnd' '--with-mysqli=mysqlnd' '--with-pdo-mysql=mysqlnd' '--with-
kerberos' '--enable-ftp' '--disable-posix' '--enable-bcmath' 
'--enable-gd-native-
ttf' '--with-freetype-dir' '--with-jpeg-dir=/usr/local' '--with-png-
dir=/usr/local' '--with-xsl=/usr/local/lib' '--enable-exif'

Test script:
---
 default output handler
)

Array
(
[0] => ob_gzhandler
)

Array
(
[0] => default output handler
)

Actual result:
--
First execution (in browser)
Array
(
[0] => default output handler
)
Array
(
[0] => ob_gzhandler
)
Array
(
[0] => 
)

Second execution (in browser)
Firefox 16.1a
Array
(
[0] => default output handler
[1] => zlib output compression
)


Chrome 2.0.1132.57
Array
(
[0] => default output handler
[1] => zlib output compression
)
‹s,*J¬äÒàR‚hƒX[;…”Ô´ÄÒœ…üÒ’‚Ò…ŒÄ¼”œÔ"ˆ
C°Šü¤øô*˜¸&HùÓàDArray
(
[0] => default output handler
[1] => 
)






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=62627&edit=1