SCRIPT:

ob_start("my_callback");
echo "foo<br>\n";
ob_end_flush();

function my_callback($buffer)
{
	ob_start();
        echo "bar<br>\n";
        $bar = ob_get_contents();
        ob_end_clean();
	$buffer .= $baz;
}


BEHAVIOR:

PHP (static command-line, or as an Apache module) goes
into some sort of loop (I can guess which sort, see below)
and begins sucking CPU like a cyber-hooker.


CONFIGURE:

'./configure' '--prefix=/d/test_make/php'
                  '--with-config-file-path=/d/test_make/php'
                  '--with-apache=/home/rick/corengine-2.0.1pre1/src/apache_1.3.12'
                  '--with-mysql=/usr'



Looks to me like some sort of scoping/context issue (can't
start a new buffer inside the callback) -- in the callback
ob_start is getting called but when ob_end_clean is
called I'd guess that the state (the callback == "my_callback") has not been properly restricted to the
enclosing buffering (does that sentence parse?) and the
callback from the outer buffering is applied to the inner.
When that happens... infinite loop (and depending upon how
it's implemented it may not even be grabbing stack space
which would make it truly a CPU-sucker).

Why did this come up?

I had some object functionality with a "render" method
which simply printed out its output.  I moved a system to 
using buffered output and found that it would be more 
efficient to call the object->render() method after the
buffering was done (with a search & replace) since I then
had more information and could do less computation.  So, 
rather than rewrite the render method to return its output
I decided to nest a buffer and just capture the output (the
render method delegates to other objects which makes buffering even more attractive in this case).  Since the
best time to capture the buffer is when I'm cleaning up the
other one... boom I hit this bug.

I currently do not have PHP > 4.0.4pl1 installed so this
bug may be present in later releases I just haven't been
able to check yet.