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

ID: 16037 Updated by: estelle@megaphone.ch Reported By: hfielker@softsolutions.de Status: Critical Bug Type: Scripting Engine problem Operating System: Win PHP Version: 4.1.2 New Comment: 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 ? Previous Comments: ------------------------------------------------------------------------ [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! ------------------------------------------------------------------------ [2002-04-30 22:26:04] chris@dvdplaza.com.au 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. ------------------------------------------------------------------------ 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