Changed summary from "Memory leak during using ob_*"

Test script can be even simplier:

<?php
 ob_start('foo');
 function foo() { ob_end_clean(); }
?>

I've sent a pull request to fix this. @see https://github.com/php/php-src/pull/25
this makes php raise fatal error instead of segfault.

This seems to be a logic error when clean/flush output will cause the callback 
called and then endless function call.

@grzegorz129 maybe the title can be more specific: eg: Segfault using 
ob_clean/flush* functions in output_callback function

@reeze - thanks for patch & title suggestion.
Is there any way to catch E_PARSE? As you can see ob_* is dead end ;)

This should work. Assign to myself.

Why has the PHP version of the report been changed?

This code works fine in PHP-5.4+

--------
[yohgaki@dev php-src]$ cat t.php 
<?php
 ob_start('foo');
  function foo() { ob_end_clean(); }
  ?>
-------

This kind of code worked since the output buffer was introduced. i.e. Works from 
PHP 4.0.

It seems PHP5.4+ has newer API, but it just raise fatal error.
I was surprised now it's not working, so I'll fix this.

-------
[yohgaki@dev php-src]$ php -v
PHP 5.4.1RC1-dev (cli) (built: Mar 22 2012 17:06:46) 
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies
[yohgaki@dev php-src]$ php t.php

Fatal error: ob_end_clean(): Cannot use output buffering in output buffering 
display handlers in /home/yohgaki/ext/git/oss/php.net/php-src/t.php on line 3
-------

Sure, it raises a fatal error, because I don't like crashes.

@mike - nooone like crashes but it should work instead of throwing E_FATAL. This 
kind of (tricky) code as I know is only way to catch errors which 
set_error_handler() just can't catch. If you know another way to do this propose, 
please.

I thought it worked for old PHPs, but it's not. So it would be OK to raise fatal 
error. Restored version.

I'll just add recursive call error to 5.3.

patch is merged. 
Thank you.