Use "View source" to see what exactly you got from the server.
Did you try a working browser instead of IE?

I've tried all the browsers I have access to. Each seems to break during phpinfo() in it's own unique way.

In Firefox 2.0.0.3, the output of phpinfo is truncated when viewing source. The output stops after SCRIPT_FILENAME. There is a closing TD and an opening TD tag following SCRIPT_FILENAME. 

In Opera 9.10, something similar happens, although in a slightly different spot (immediately after GATEWAY_INTERFACE)

--- 

Regarding the script we developed (that generates about 1000 html rows with 8 columns) seems to go weird somewhere after 6,000 lines of output. When viewing source, I see <??????????????????????????????????? inserted in a 'random' spot. I also experienced this using wget, but currently cannot seem to reproduce that behavior. Currently, the output just stops -- but only when using a browser. wget retrieves the entire thing just fine. The one time I observed this, the 300kb html file was bloated to 6MB and contained a huge middle section of <????????

Could this have something to do with the interplay of the browser and our php distribution or configuration? We use output buffering quite extensively... 

Thanks. Please let me know if you need anything else.

Here's another tidbit that may be helpful.

I tried a simple test that works flawlessly on another server that we have. On the troublemaker, PHP seems to start having trouble at about 16Kb of output. Just like with phpinfo and our main script, this test works fine as long as you access it using wget or the CLI. 

<?php
   for($i=0;$i<1000;$i++) {
      echo 'start row:'.$i;
      for($j=0;$j<9;$j++) {
         echo 'cell:'.$j;
      }
      echo 'end row:'.$i;
   }
?>

I'd like to rule this out as being a bug. There's a good chance it's not, but I can't seem to prove it either way.

Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.2-win32-latest.zip

Make sure you disabled all zend_extensions and try the snapshot above.

Make failed. Any suggestions except for trying it without GD?

ext/gd/.libs/gd.o(.text+0x537): In function `zm_shutdown_gd':
/usr/local/src/php5.2-200704041430/ext/gd/gd.c:1208: undefined reference to `gdFontCacheMutexShutdown'
ext/gd/.libs/gd.o(.text+0x57a): In function `zm_startup_gd':
/usr/local/src/php5.2-200704041430/ext/gd/gd.c:1223: undefined reference to `gdFontCacheMutexSetup'
collect2: ld returned 1 exit status
make: *** [sapi/cli/php] Error 1

Is GD required to reproduce it?

I've just compiled the same extension without problem, what's the exact configure line that you used?

I compiled without GD, and tested the latest snapshot as you requested. I'm experiencing the same behavior as I described before. 

I used the configure line I pasted in the original bug report.

The only thing I changed was the prefix. /usr/local/php5-snapshot

In any case, GD is not required to reproduce the behavior.

I'm still unable to replicate it.

Is there some interplay between apache and PHP that might be required to reproduce this? 

For apache, we used 2.2.4 sources with

./configure --prefix=/usr/local/apache-2.2.4 -without-suexec-userdir -with-mpm=prefork --enable-so --enable-rewrite

Is the data received by the browser correct?
Are there any firewalls or filters between the server and the browser?
Where can I see the problem? (is there a public http server?)

Tony,

I sent you an email with info on how to access the misbehaving page, since this is a project for an internal admin page.

If you look at the source of the page, you'd see lots of null bytes.
Make sure you don't have any firewalls (including hardware ones) or anything else that might affect the output.
And try to rebuild Apache using minimal configuration.
Doesn't seem to be PHP problem, PHP doesn't insert 600K of null bytes in phpinfo().

We have a rack with a hardware firewall, and have iptables on most servers. I don't see anything different on this server. Our other servers seem to have no trouble with PHP. It seems pretty likely that this isn't a PHP bug, so I will stop expending your resources. 

Thank you for your time.