零大小的回复：PHP在变量赋值时崩溃

Question

I occasionally got a problem, which lets the webbrowser display the message "Zero sized reply" (Firefox). Chrome displays "ERR_EMPTY_RESPONSE". I am using CodeIgniter (still a version 2.xx).

On the call, I validate some post variables, insert a database record, and send an email. The email method however loads a language file for a log message. On the end of this call, in the class system/core/Lang.php, the file gets included and a class array is extended.

The following line (Lang.php, line 126), executes the following statement:

$this->is_loaded[] = $langfile;

The array is initialized and this usually functions just fine. But in this special case, this is the exact line which leads the PHP server to crash (my explanation for the empty response I get).

I am running now forced PHP 5.5.19, but the error also displays with 5.2.17.

Anyone an explanation why this happens? If I try to reproduce the error by assigning a variable in a similar way, I never recieve the same message. Also, the only similarity in cases I recieve this error is that I've sent a mail before.

Update: Here's the PHP_INFO: http://awesumgrades.ch/phpinfo.php

Update 2: Here's what I tried exactly:

I tried to dump everything before that line:

var_dump($this->is_loaded);
var_dump($langfile);
exit("I reached here");
$this->is_loaded[] = $langfile;

Recieving this output:

array(0) { } string(14) "email_lang.php" I reached here

Now when I execute this (put the array assignment in front):

$this->is_loaded[] = $langfile;
var_dump($this->is_loaded);
var_dump($langfile);
exit("I reached here");

I get an ERR_EMPTY_RESPONSE (chrome).

When I dump $this, this is the object:

object(CI_Lang)#11 (2) { ["language"]=> array(0) { } ["is_loaded"]=> array(0) { } }

When I go a step back to the calling function, I got the following lines (at core/libraries/Email.php):

protected function _set_error_message($msg, $val = '')
{
    $CI =& get_instance()
    $CI->lang->load('email'); // <-- this is the call which gets to the other method

I put the following lines in front of the email loader:

$CI =& get_instance();
var_dump($this);
var_dump($CI);
exit();
$CI->lang->load('email');

This outputs the whole object, which I cannot post here because of security reasons of my site. If you need a specific property or a part of the object, I'll provide here.

I'm currently still waiting for the Apache Log from my hoster, if it's here I'll post it.

Update 3: I've just tried to simply comment out the line once again, but then the script crashes at the following line, which clarifies that the crash has absolutely nothing to do with the logic of the class Lang.php, but it seems to be an error of a bigger class (I've tried to print out the memory but I don't have permission for memory_get_usage()....

FINAL UPDATE

I've finally reached my hoster which provided me the apache error logs, but there weren't any clues of the said error.

However, the magic is now complete: After smcjones' answer, I added the line

ini_set('display_errors', 1);

at the very first line in CI's index.php, and set the error_reporting again to E_ALL. However, as soon as I run the code with this line set, the error won't happen again - even when I set display_errors to 0. When I comment the line out again, the error happens again. Also when I remove the error_reporting(E_ALL), the error occurrs, despite the ini_set.....

I got absolutely no clue what gets changed with these lines, but it seems like with the call of ini_set() and the error_reporting, some routine maybe gets included which was missing otherwise - I don't know.

It states once more how magic PHP sometimes can be - it never fails to amaze me.

Answer 1

It sounds like your log level is not high enough to receive non-fatal errors. PHP can just gracefully shut down if there is an error that isn't set to display.

I understand that you should be receiving errors based on your CI configuration, but you may not be receiving warnings. Any warnings you get could serve as a clue.

Please try putting this at the top of your file (before any output and headers):

ini_set('display_errors', 1);
error_reporting(E_ALL);

When you refresh your browser, you should not receive an empty page.

Another thing you can try, as a slightly better long-term patch, is:

ini_set('display_errors', 0);
error_reporting(E_ERROR);

If this works, then stick with that for now because it is less likely to show the user things you don't want them to see.

Ultimately, based on the behavior changing (incorrectly) when using PHP configuration functions, this is something either Apache related or PHP config related, which is host-specific. Because you can't handle your host, I recommend switching hosts (there are lots of good affordable host options) or at least telling your host you won't be able to stay with them unless they fix whatever is wrong.