accident Apache - PHP

Question

MISE À JOUR INFO:

OS Windows 7 32bit Apache 2.2.15 PHP 5.2.13

---

C'est vraiment bizarre. Quand je suis arrivé à cette URI dans mon application:

/view/course/teid/1/cid/-1/pos/30 

Apache se bloque.

Quand je vais à un URI très similaire - comme celui-ci:

/view/course/teid/1/cid/-1/pos/29 

Tout fonctionne très bien.

C'est l'erreur journal:

[Thu Aug 05 11:22:14 2010] [notice] Parent: child process exited with status 255 -- Restarting. 

Je suis en mesure de suivre la ligne qui provoque l'Apache crash:

if (true === $aCourseTree->SetNodePassed($node)) { // this line crashes Apache 
    self::writeTreeToDb($aCourseTree, $training, $this->aUtils); 
} 

La méthode est ici:

public function SetNodePassed(CourseTreeNode $theNode) 
{ 
    $aWasChange = !isset($theNode->Passed) || $theNode->Passed !== true; 
    $theNode->Passed = true; 

    if ($aWasChange && isset($theNode->Parent)) { 
     if (true === $this->AreChildrenPassed($theNode->Parent)) { 
      $this->SetNodePassed($theNode->Parent); 
     } 
    } 
    return $aWasChange; 
} 

Que diable se passe-t-il? S'il y a une erreur, cela devrait juste être une erreur PHP. Pourquoi Apache plante-t-il?

Answer 1

Comment utilisez-vous PHP dans votre Apache?

mod_php peut facilement tuer un processus de travail Apache [1], et la ligne de conduite correcte pour le serveur Apache dans son ensemble est d'essayer de revenir à un état aussi "propre" que possible. Il est presque impossible pour un processus de nettoyer après une mémoire corrompue, mais le redémarrage est très sûr et facile. [2] Cela va un long chemin vers le retour du système à un état connu.

Vous souhaiterez peut-être passer à une implémentation FastCGI au lieu de mod_php; si vous avez besoin d'autres raisons, voici une série de raisons très bien écrit:

http://www.majordojo.com/2007/11/is-mod-php-falling-out-of-favor-with-hosting-providers.php

[1] L'équipe de PHP a demandé aux équipes de sécurité de la distribution Linux de cesser d'appeler les bogues crash php-interprète « problèmes de sécurité » - ils corrigeaient si souvent ces types de bogues, que des bogues de sécurité exploitables à distance dans php et ses bibliothèques étaient noyés dans le bruit.

[2] Bien sûr, pour se ré-exécuter, il devrait appeler une des fonctions exec() sur la mémoire qui pourrait être corrompue, mais heureusement la seule mémoire corrompue dans le processus maître Apache serait le tableau de bord. Donc, un re-exec devrait être assez sûr.

Answer 2

Essayez d'inclure ce en haut de votre script php et voir quelle erreur vous obtenez

ini_set('error_reporting', E_ALL);