tags:

views:

83

answers:

1

I was using the following code to retrieve HTML snippets from a database table and display them. It worked fine on my old web host, but after moving to a new web host I started getting (rather unhelpful) 500 Internal Server errors. Both hosts use PHP 5.2.x.

$query = "SELECT id, html FROM $tableName ORDER BY id DESC LIMIT 0, 300";
$result = mysql_query($query);
while ($row = mysql_fetch_assoc($result)) {
    $myArray[] = $row;
}

foreach($myArray as $m) {
    echo $m['html'];
}

By selectively commenting out code, I narrowed the problem down to the foreach loop. I eventually found that I could get the page to display (with no 500 error) if I chopped off some of the items (see $offset below). Sometimes I have to use an offset of 50, sometimes 100 or more.

$counter = 0;
$offset = 100;
$limit = count($myArray) - $offset;
while ($counter < $limit) {
    echo $myArray[$counter]['html'];
    ++$counter;
}

This made me think there was something wrong with the individual HTML snippets. So I adjusted the offset one by one until I found the offending row (i.e., $offset=23 worked, but $offset=22 doesn't, therefore row #23 is the culprit). I looked at that row's HTML and it is perfectly fine. Not only that, but earlier in the day my script had even displayed that particular HTML snippet with no issues (this table periodically has new HTML inserted, and I'm just viewing the most recent 300 of them).

I also tried adding some basic checks before echo-ing, but it had no effect:

while ($counter < $limit) {
    if ($myArray[$counter]['html'] != false && !empty($myArray[$counter]['html'])) {
        echo $myArray[$counter]['html'];
    }
    ++$counter;
}

Any ideas why echo and/or the loop is failing? How can I see useful errors instead of a 500 server error? I have PHP display_errors turned on and I can see errors from other parts of the script when I intentionally force them (both on the page and in the error log file).

Update: Apache access log

Okay, I went to it first and manually set '$offset' to 200 (see the parameter ?o=1 in the URL) which I knew would let the page display properly. The result:

my.ip.add.ress - p [18/Jun/2010:13:27:36 -0400] "GET /test2/index.php HTTP/1.1" 200 602778 "-" "Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 (.NET CLR 3.5.30729)"
my.ip.add.ress - p [18/Jun/2010:13:27:47 -0400] "GET /test2/index.php?o=200 HTTP/1.1" 200 418127 "-" "Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 (.NET CLR 3.5.30729)"

Then I forced $offset to 1 (which would generate the 500 error) and I got this:

my.ip.add.ress - - [18/Jun/2010:13:31:06 -0400] "GET /test2/index.php?o=1 HTTP/1.1" 404 - "-" "Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 (.NET CLR 3.5.30729)"
my.ip.add.ress - p [18/Jun/2010:13:30:59 -0400] "GET /test2/index.php HTTP/1.1" 200 602731 "-" "Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 (.NET CLR 3.5.30729)"

It says 404, however the page being displayed in the browser says two things: the <title> is 500 Internal Server error, and the page body repeats this but then also mentions the 404 because it couldn't find the 500 error HTML page (which I haven't set up yet).

A: 

(Sorry, ideally this would have been just been a comment, sans-speculation, if I was able to post one)

I notice based on your access log that your script's output is fairly large (602778 bytes formed from what I believe is only 200 of your original 300 records), and after performing a quick test for myself, the script could potentially consume several megabytes of memory when it gets called. That's certainly nothing outrageous, but if your new host is super-stringy about their setting of memory_limit in php.ini, exceeding this value would raise E_FATAL in PHP, which could in turn generate the internal server error.

Admittedly, this scenario seems very unlikely to me, but it would explain why the problem manifested when you changed to a new host and why it 'magically' appeared after working fine earlier, provided the so-called problem HTML came from a slightly smaller result set when you viewed it before.

In any case, imaginative guessing on my part aside, you should have access to your php_error.log file, which would show if PHP was causing any sort of fatal error, and that would help debug your problem further.

Tim Stone
You might be on to something -- each snippet is roughly 3KB, and the entire rendered page is ~1MB (yikes, didn't realize that). I added `echo memory_get_usage();` at the end of my script and it reported 900KB to 1.5MB over a few tries. My host has `memory_limit` set to `32M` and I don't have access to php.ini. I tried adding `ini_set('memory_limit', '128M');` to my script but it didn't seem to help. Nothing is showing up in my `php_error.log` file (other errors do, but nothing in the past hour while I've been playing around with it).
Ellsass
While I haven't been able to determine it beyond any doubt, I think Tim is right, it is a memory issue. While working on this problem, however, I realized that I actually don't want to display ~300 records -- I really wanted to do something else (display everything from record X and newer) and just spitting out 300 was a lazy way of achieving that. I've since rewritten my code to display a more accurate set of records as well as insert a link to load more via ajax if necessary, which is much more efficient and correct. Thanks everyone!
Ellsass
Yeah, I messed around with a few things on one of my test servers to see if I could recreate the issue for myself, but nothing took unfortunately. At least you were able to come up with an issue-free solution, though, so it's all good.
Tim Stone