Apache 2 no Ubuntu retornando 500 sem causa conhecida?

Question

NOTA: Esta questão foi resolvida ! Por favor, veja abaixo a solução no meu caso, se você está tendo um problema semelhante!

Histórico:

Este é um aplicativo baseado em banco de dados baseado em PHP / MySQL que faz uso intenso de AJAX, e quase todas as solicitações para o servidor ocorrem dessa maneira. As solicitações são solicitações GET nesta instância e o servidor está respondendo via JSON. O usuário trabalha para dentro, através do conjunto de dados, retornando resultados mais precisos e refinados. A aplicação é estável e em produção.

Eu tenho a capacidade de depurar isso em 3 plataformas: Meu laptop de desenvolvimento (OSX), um servidor interno do Ubuntu e o servidor Ubuntu de produção.

Cada servidor Ubuntu está executando um servidor MySQL e uma cópia do Apache.

Meu laptop de desenvolvimento conecta-se ao servidor MySQL executado em nosso servidor interno Ubuntu, e executa seu próprio servidor Apache. p>

Ambos os servidores Ubuntu são 9.10, x64, totalmente atualizados através dos fontes oficiais, Apache 2.2.12, PHP 5.2.10.

E agora a parte divertida:

O aplicativo retorna resultados corretamente em todos os casos, exceto uma subseção do conjunto de dados. Solicitações de dados dentro desta subseção sempre retornam um 500 em vez de um conjunto de resultados. A subseção em questão é meramente uma consulta para retornar resultados com base em IDs conhecidos. Os registros são conhecidos e não contêm dados corrompidos.

Eu tenho o registro de depuração ativado para o Apache e o E_ALL configurado para o PHP (registro no arquivo). Quando o 500 ocorre, vejo o seguinte no error.log do Apache (x é para mascarar):

[Sun Aug 01 15:43:54 2010] [debug] mod_deflate.c(615): [client 192.168.1.28] Zlib: Compressed 0 to 2 : URL /apps/xxxx/connectors/details_lookup.php, referer: http://xxxx.xxxx.local/apps/xxxx/

Isso implica uma falta de dados. No entanto, não há erros registrados no log de erros do PHP. Ao mesmo tempo, posso retornar resultados em outro lugar no conjunto de dados sem problemas.

Então você pode estar pensando "O problema deve estar no banco de dados".

No entanto , quando uso meu laptop de desenvolvimento (e sua própria cópia do Apache) para conectar ao mesmo servidor MySQL em nossa rede interna, eu posso executar o pedido que gera o 500 sem nenhum erro .

Então, quando eu executo o aplicativo no meu servidor Apache no meu laptop, tudo é legal. Quando executo a mesma solicitação com os mesmos dados no mesmo banco de dados no mesmo servidor de banco de dados, mas em vez disso, usando a cópia local desse servidor do Apache, falhe.

Estou totalmente perplexo. Qualquer ajuda seria muito apreciada neste momento.

    

Answer 1

Solução

Acontece que, embora o PHP 5.2 tenha introduzido o objeto DateTime, o método DateTime- > diff () não se tornou disponível até o PHP 5. 3 .

No meu caso, um bloco de código condicional seria executado dependendo do conteúdo de alguns resultados. Os resultados que causaram o 500 foram invocando a parte do código usando DateTime- > diff.

Eu postei o código original que causa o erro 500 no PHP 5.2, seguido pelo código corrigido que opera como esperado no PHP 5.2.

Alguém pode explicar por que o PHP não registraria um erro, mesmo usando o E_ALL?

Código 5.2 Incompatível :

$effective = new DateTime($eff, new DateTimeZone('America/New_York'));
$diff = $effective->diff(new DateTime(date('Y-m-d'), new DateTimeZone('America/New_York')));
if ($diff->format('%R') === '-') { ...

PHP 5.2 Compatível código:

$effective = new DateTime($eff, new DateTimeZone('America/New_York'));
if ($effective > new DateTime(null, new DateTimeZone('America/New_York'))) { ...