Question

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).

Answer 1

(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.