Bug #16037 Updated: random parse errors on dual xeon machine

From: Date: Tue, 23 Jul 2002 01:16:55 +0000
Subject: Bug #16037 Updated: random parse errors on dual xeon machine
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-14831@lists.php.net to get a copy of this message
ID: 16037 Updated by: mike@h3c.org Reported By: hfielker@softsolutions.de Status: Critical Bug Type: Scripting Engine problem Operating System: Win PHP Version: 4.1.2 New Comment: 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. Previous Comments: ------------------------------------------------------------------------ [2002-07-10 04:29:22] estelle@megaphone.ch 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 ? ------------------------------------------------------------------------ [2002-06-07 16:48:10] agarza@campus.mty.itesm.mx 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). ------------------------------------------------------------------------ [2002-06-05 15:17:35] agarza@campus.mty.itesm.mx 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' ------------------------------------------------------------------------ [2002-05-09 18:00:52] chris@dvdplaza.com.au 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. ------------------------------------------------------------------------ [2002-05-01 10:54:28] chris@dvdplaza.com.au 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! ------------------------------------------------------------------------ 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 http://bugs.php.net/16037 -- Edit this bug report at http://bugs.php.net/?id=16037&edit=1

« previous php.bugs (#14831) next »