Sigificant Volume Of Errors Since Upgrade To 2.2.1

[DVD Plaza]

Hey guys,

Ever since I upgraded to 2.2.1 my error log keeps filling up with stuff like (small snippet):

[Wed Jan 23 00:01:41 2002] [error] PHP Parse error:  parse error in \htdocs\forums\admin\sessions.php on line 161
[Wed Jan 23 00:01:41 2002] [error] PHP Parse error:  parse error in \htdocs\forums\admin\db_mysql.php on line 229
[Wed Jan 23 00:01:41 2002] [error] PHP Fatal error:  Cannot instantiate non-existent class:  db_sql_vb in \htdocs\forums\global.php on line 104
FATAL:  erealloc():  Unable to allocate 360448 bytes
[Wed Jan 23 00:05:17 2002] [error] PHP Parse error:  parse error in \htdocs\forums\admin\functions.php on line 843[Wed Jan 23 00:05:17 2002] [error] PHP Warning:  Unexpected character in input:  '\' (ASCII=92) state=1 in \htdocs\forums\admin\db_mysql.php on line 227
[Wed Jan 23 00:05:17 2002] [error] PHP Warning:  Unexpected character in input:  '\' (ASCII=92) state=1 in \htdocs\forums\admin\db_mysql.php on line 227
[Wed Jan 23 00:05:17 2002] [error] PHP Parse error:  parse error in \htdocs\forums\admin\db_mysql.php on line 228
[Wed Jan 23 00:05:17 2002] [error] PHP Fatal error:  Cannot instantiate non-existent class:  db_sql_vb in \htdocs\forums\avatar.php on line 24
[Wed Jan 23 00:05:17 2002] [error] PHP Fatal error:  Call to undefined function:  vbdate() in \htdocs\forums\admin\sessions.php on line 357
[Wed Jan 23 00:17:02 2002] [error] PHP Parse error:  parse error in \htdocs\forums\admin\db_mysql.php on line 234
[Wed Jan 23 00:17:02 2002] [error] PHP Fatal error:  Cannot instantiate non-existent class:  db_sql_vb in \htdocs\forums\global.php on line 104
[Wed Jan 23 00:20:50 2002] [error] PHP Parse error:  parse error in \htdocs\forums\admin\functions.php on line 899
[Wed Jan 23 00:20:50 2002] [error] PHP Fatal error:  Call to undefined function:  vbdate() in \htdocs\forums\admin\sessions.php on line 357
FATAL:  erealloc():  Unable to allocate 1441792 bytes
[Wed Jan 23 00:36:54 2002] [error] PHP Parse error:  parse error in \htdocs\forums\admin\functions.php on line 1155[Wed Jan 23 00:36:54 2002] [error] PHP Parse error:  parse error in \htdocs\forums\admin\db_mysql.php on line 228
[Wed Jan 23 00:36:54 2002] [error] PHP Fatal error:  Cannot instantiate non-existent class:  db_sql_vb in \htdocs\forums\global.php on line 104
[Wed Jan 23 00:36:54 2002] [error] PHP Fatal error:  Call to undefined function:  vbdate() in \htdocs\forums\admin\sessions.php on line 357

What gives - the forums still work fine but this is bothering me. The log was nice a squeeky clean before, short of the odd 404.

[tubedogg]

Try reuploading all of your files, making sure you are doing so in ASCII mode.

Also have you done any hacking?

[DVD Plaza]

Yeah I've done quite a lot of additions throughout, only a few alter the existing code, but I've tried reverting to the original source and same results.

What I have discovered is that turning of Zend Optimizer suddenly eliminates all those errors (albiet runs a lot slower), and turning it back on again suddenly brings back all those errors.

These didn't exist a few weeks ago...?

[tubedogg]

That's why I'm thinking there's some kind of error in the way they were transferred to your server, especially with the kind of errors they, function() not existing, etc., which are often errors when files get uploaded wrong or get truncated...

[DVD Plaza]

It's a W2K server running Apache so that's problem doesn't exist.

In any case the scripts all work, as I said you can happily use the system (we're talking quarter of a million hits minimum a day so the percentage of errors is barely registerable), so it's not like it's hosed completely it's just that a tiny percentage of the time it is obviously coming up with those errors because.... ???

Very baffling... and concerning...

[roy7]

When I opened db_mysql.php in vi, it warned me the file had no EOL. So I resaved the file and the error went away.

It seems the .zip has text files formated for unix also? ie, no \r\n on each line.

-Jonathan

[roy7]

The base site itself wasn't working until I rewrote all the files missing EOL. Now it works.

Because your problem went away when Zend Optimizer was turned off, I have to wonder if files missing an EOL at the end of the file cannot be require()'ed when Zend Optimizer is turned on.

-Jonathan

[roy7]

Actually our server wasn't running the Optimizer, we were running the APC cache however.

Regardless, adding an EOL to the files that were missing them (you can check by opening the file in vi and seeing if [noeol] appears on the bottom of the screen) fixed it.

-Jonathan

[David Bott]

Yes...Once again Roy to the rescue! When we went to upgrade AVS Forum it went CRASH!!! The weird part is that even after a restore of the entire directory from backup (tape) it still would not work.

Now...we do not have the optimizer running but we do have APC Cache. Still NO CLUE! For some reason the 2.2.1 did not have any end of lines but still ran. But after just uploading the new files...it all failed until the end of lines were put into place.

SOMEONE FROM VB PLEASE ADVISE!!!

[Mike Sullivan]

PHP is like C -- a semi-colon terminates a statement, not the end of a line (like Basic for example). So unless semi-colons got chopped out, there shouldn't be a problem.

The files are most likely formatted for Unix -- which is just \n. Windows is \r\n, Macs just \r. The only PHP bug I've heard of is when the line breaks are Mac formatted, but that should now be fixed -- either in the most recent version or CVS, not sure which.

To me it sounds like an obscure Zend Engine bug...

[roy7]

But it isn't a \r vs \r\n issue though. The \r and the \n on the final line is missing, thus the warning in vi "noeol" when you open the file. That shouldn't happen on dos or unix. It's kinda.

If you just open the file and resave them in vi it'll fix the problem, or get that final EOL on there in some other way. Then this program won't resurfe regardless of what weird bug it's tickling. It seems files with a missing EOL on the last line can't be require()'ed in some situations.

-Jonathan

[DVD Plaza]

Some further developments on this, firstly my post in the PHP bug reporting database:

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.

Next, a post I made elsewhere here that elaborated a little...

Originally posted by DVD Plaza
....I've found since version 1.2.x of PHP that, when running as an Apache module under the Windows environment, PHP will intermittently screw up when it interprets code. That is, even a single line script will suddenly fail with a parse error once in a while. This causes either a blank (white by defalt) window or a partially rendered page - but as I said it's only intermittent

PHP 4.0.6 had no such problem, reverting back to it solves this. Unfortunately (or fortunately really) 4.1.2 was a security fix so obviously one needs to upgrade to this, and must therefore live with the (various for me) faults it has.

That said, it seems to me the problem is specific to the Windows platform so I was taking a guess that perhaps your server may be such a setup - but it sounds like you probably don't know anyways If it is the case I don't yet have a solution for the problem yet

[DVD Plaza]

So, the reason for the above followup? I've finally found the damned problem!!!

The trouble with this chaos was that things would work 90% of the time, the rest of the 10% pages would not display/partially display and stupid messages would appear in the error log such as:

unexpected '!' in \htdocs\forums\admin\db_mysql.php on line 234
unexpected T_ENCAPSED_AND_WHITESPACE in \htdocs\forums\admin\functions.php on line 124
Call to undefined function: getuserinfo() in \htdocs\forums\admin\sessions.php on line 322

It goes on and on and on and on and on... the stupid thing is 90% of the time it works brilliantly, the other 10% it fails - how can there be a fault in the source code when it works 9/10 and more important, that it seems most people here (bar a few posting here and there, elsewhere, and those who contacted me direct) didn't have such an issue...

Well I tonight finally sorted it out - I decided I would resolve anything and everything the damned log was whinging about, regardless of it working the other 90% of the time. After changes all over the place, the following is the ONLY changes that TOTALLY resolved this issue once and for all!

Starting at line 206 in db_mysql.php:
$message="Database error in " . $this->appname . $GLOBALS[templateversion] . ": \n\n$msg\n";
$message.="mysql error: " . $this->errdesc . "\n\n";
$message.="mysql error number: " . $this->errno . "\n\n";
$message.="Date: ".date("l dS of F Y h:i:s A")."\n";
$message.="Script: " . $GLOBALS[bburl] . (($scriptpath) ? $scriptpath : getenv("REQUEST_URI")) . "\n";
$message.="Referer: ".getenv("HTTP_REFERER")."\n";

if ($technicalemail) {
@mail ($technicalemail,$this->appshortname . " Database error!",$message,"From: " . $technicalemail);

So what's different than what vBulletin comes with? I've removed all the class references from WITHIN quotes to OUTSIDE the quotes. Who knows why, but 10% of the time the PHP parser goes ape when it hits something like $blah->blah/n or $GLOBALS[blah]:

Hopefully this can be changed in the actual vBulletin release code - this behaviour quirk has obviously been caused by some change in PHP from 4.1 onward, and whilst it clearly didn't affect many people here it certainly has caused MONTHS OF SHEER HELL for my viewers (10%+ of page requests failing is a massive figure, and p#sses people off if it happens to fail when they submit a post!). My error log was squeeky clean before PHP 4.1, since PHP 4.1 and PHP 4.2 it grows to several *MB* a day - the errors I've listed in this thread flow very thick a MINUTE, yet since I've made the above changes this past hour not a single thing has appeared in the error log bar the "No file uploaded in Unknown on line 0" that appears under Apache2 every time a post is made without an attachment.

/me is happy!!!

[DVD Plaza]

Hey freddie,

I noticed in the db_mysql security fix you've incorporated the above changes, however there's still one thing present that caused these weird errors - GLOBALS within quotes.

The lines I'm referring to is as follows:
$message.="Script: $GLOBALS[bburl]" . (($scriptpath) ? $scriptpath : getenv("REQUEST_URI")) . "\n";
and
$message="Database error in " . $this->appname . " $GLOBALS[templateversion]:\n\n$msg\n";


It needs to instead be:
$message.="Script: " . $GLOBALS[bburl] . (($scriptpath) ? $scriptpath : getenv("REQUEST_URI")) . "\n";
and
$message="Database error in " . $this->appname . " " . $GLOBALS[templateversion] . ":\n\n$msg\n";

Thanks