Nützliches aus der Trickkiste: Debugging

• Home
• Magazin
• Know How
• Web Development

Fangen wir mit einem leidigen Thema an: Debugging. Vergessen Sie unzählige print- und echo-Orgien, sondern eignen Sie sich den Gebrauch der error_log()-Routine an. In manchen Situationen kann man einfach nicht mit PHP Userland Debuggern wie DBG arbeiten, z.B. weil die Applikation hinreichend komplex ist und der Verlauf sich nicht über das run-Interface des Debuggers in der IDE nachbilden läßt. Damit error_log() auch nützlich ist, sollte man zunächst folgende Einstellungen in der PHP-Konfiguration tätigen (zum Beispiel in der httpd.conf oder in einer .htaccess, sofern dies erlaubt ist):

php_flag display_errors off  
php_flag log_errors on 
php_value error_log /www/pfad/zu/siteA/logs/php_error.log

display_errors off sorgt zunächst dafür, dass Fehler nicht im Browser dargestellt werden. Sollte man mindestens auf der Produktivwebsite auf off lassen, je nach Workflow macht es auch Sinn, diese Variable ebenfalls im Testbetrieb auf off stehen zu lassen. Mit log_errors on wird PHP dazu angewiesen, Fehler in ein Logfile zu schreiben. Damit PHP auch weiß, welches Logfile das ist und auch Ihre "per Hand" geloggten Statements per error_log() im gleichen File landen, sollten Sie die Direktive error_log nutzen und hier ein Logfile definieren. Wichtig ist hierbei, dass die Datei bereits existiert (unter Linux reicht hier z.B. ein touch) und für PHP beschreibbar ist.

Nach dieser Einstellung und dem eventuellen Neustart des Webservers lassen sich Fehlermeldung sehr komfortabel über ein tail -f /www/pfad/zu/siteA/logs/php_error.log in einem Shell-Fenster neben dem Browser beobachten. In Ihrer Applikation sollten Sie dann an entsprechenden Stellen Ihre eigenen Logeinträge machen, zum Beispiel wie folgt:

<?php
    $db->query("select ....");
    while ($db->next_record()) {
      $id = $db->f("id");
        error_log(sprintf("ID im Durchlauf: %s",$id));
       }
  ?>

Damit Sie auf dem Produktivserver, der ja immer fehlerfrei sein sollte ;-), keine zig Megabytes an Logfiles haben, könnte man die error_log()-Aufrufe über eine If-Abfrage absichern, zum Beispiel mit einer Konstante DEBUG:

<?php
    /**
    * in Config file z.B. deklariert
    */
    define("DEBUG", true);

       /**
    * im aufrufenden Script
    */
    $db->query("select ....");
    while ($db->next_record()) {
      $id = $db->f("id");
      if (DEBUG) error_log(sprintf("ID im Durchlauf: %s",$id));
      }
  ?>

Manchmal ist jedoch alles scheinbar fehlerfrei, in den PHP Applikationen wurde alles kontrolliert und dennoch funktioniert die Applikation nicht so wie erhofft. Hier hilft es zum Beispiel, den Apache im single user Modus auf einem anderen Port zu starten und das entsprechende Szenario nachzuspielen, bei dem der Apache einen core dump wirft. Diesen core dump kann man dann mit dem GNU Debugger nachvollziehen und genau sehen, an welcher Stelle was (PHP? Apache? Datenbank?) gegen die Wand fährt. Weitere hilfreiche Tools dieser Art sind zum Beispiel strace oder tcpdump/tcpshow, mit denen sich der TCP/IP-Verkehr debuggen läßt und die Basis unserer Debugging-Arbeit in unseren Großprojekten sind. Wenn Sie ebenfalls in Ihren Projekten nicht weiter kommen oder hier und da Hilfe benötigen, so sprechen Sie an. Wir sind unter anderem für Unternehmen unterstützend im Bereich der Softwareentwicklung und des PHP Supports tätig.

Kommentare

Bitte beachten Sie unsere Informationen zum Datenschutz.

Weitere Artikel zum Thema