We have EXACTLY the same problem, and it is 100% specific to PHP 4.1 onward (ie both PHP 4.1 and now PHP 4.2 do this).  For example sake let's compare 4.0.6 to 4.2 - install PHP 4.2 and everything works fine, but every so often (let's say 10% of the time) they get nothing/part of a page and the error log shows a parse error (whinges about all sorts of stuff that isn't true) - a simple refresh solves this problem.  It's easily reproducable, though as per the original repor there it might be load related as we get a lot of activity.  Now here's the thing - PHP 4.1 introduced this, if you put PHP 4.0.6 back on everything is 100% PERFECT.  Put 4.1 or 4.2 back on and 10% or so of requests fail, put 4.0.6 back on and it's perfect, put 4.1 or 4.2 back on and the problem is back - this has been major hell for us and I hoped to heck 4.2 would fix it, but alas the problem still exists.... HELP!!!!  Running as a module under Apache, was Apache 1.3.24 until last night - as of last night we're now under Apache 2.0.35, with the same problem.

Well I've finally found the problem, having lived with all the hell this has caused all these months...

Let's say you have a line such as:
echo "$blah->blah!!!\n\n";

That line of code may work, but THAT is what is causing the random failures - if PHP 4.1 onward (including PHP 4.2) is used that line will randomly fail with parse errors.  As a result of those parse errors, the scripts would not have been fully loaded into memory and what ends up executing causes even more errors.

I have edited such references in a third-party script we purchased to instead read as follows:
echo $blah->blah . "!!!\n\n";

As a result of this, instead of my error log filling up thick and fast per MINUTE with all these weird parse errors (and as a result 90% or so of page requests working, the remainder failing with a blank page or partial page) the error log has been dead silent this past couple of hours and I've not yet seen a single page failure!

Been a week and a half and my error log is still dead silent since making those changes, compared with several MB worth of random/intermittent errors that occurred months ago when we first upgraded to PHP 4.1 onward.

I am experiencing the same problem--random parse errors--on SunOS 5.8 with PHP 4.2.1. It seems the larger the script the easier it is to get a parse error.

PHP is set up to run under NSAPI (Iplanet webserver).

The setup is:
'./configure' '--with-mysql=/usr/local/www/biblio/dev/mysql' '--with-nsapi=/opt/iplanet/webserver/' '--enable-track-vars' '--enable-libgcc'

I tried switching to PHP4.1.2 on Solaris 5.8, however the problems still remained.

I followed the steps mentioned by chris@dvdplaza.com.au (editing the scripts), I was able to get the scripts to work--ALL STRINGS with ${variable} or $variable within them HAD to be changed to get rid of the errors. 

  for example:
    echo "Hello $foobar";
    $foo="This is a ${bar}";
  changed to:
    echo "Hello ".$foobar;
    $foo="This is a ".${bar};

Don?t you think this is rather serious? (Random errors are a troublesome thing, arent they? Also, the lines reported as having errors were wrong most of the time).

PHP 4.1.2 on a Solaris 8 box, Apache 1.3.26 : same problem. Random parse error (slashes around quotes not removed when doing a print("blabla \"blabla\""); when these quotes are coming from an array (nothing to do with stripslashes, this is a RANDOM error).
This is critical for our clients.
Especially for people who use softwares like php Nuke ... do you know the amount of changes in code that would be necessary to avoid the problem ??
But ... is there an answer from PHP or not ?

I've got the same hardware setup as these guys (dual cpu win2k machine with lots of ram), and I still see this problem with PHP 4.2.2 right on up to the latest 4.2.2-dev stable snapshot (as of a few hours ago), so this is definitely still an issue. I haven't tried the workarounds yet, but others seem to find success so I just wanted to add another status report.

We also ran into this problem.  We found a workaround
for the iPlanet/NSAPI environment which forces single-
threading for PHP - it's documented in this bug report:
  http://bugs.php.net/bug.php?id=18869

- Bob Fillmore

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.

This should finally be fixed.

I tried the latest build and I can confirm it works for me.

I got 17 failures for 30 attempts on my reproduction scenario with an older build.

The new build as 0 failures for 30 attempts. If you're using an SMP windows machine, grab the new code.