Debuggen

[Tom]

Hello,

ich habe eine umfangreichere Klasse bekommen, die nicht richtig tickt.
Die möchte ich nun gerne debuggen. Das Problem vermute ich in einer relativ verknoteten Methode.

Welche Möglichkeiten habe ich, speziell diese Methode zu debuggen?

• Kontrollausgaben,     ok
• register_tick_funktion()        nützt mir das was?
• log schreiben lassen mit der Entwicklung der einzelnen Datenwerte
    dazu müsste ich auch lauter Kontrollstatements einbauen.

kennt Ihr gute Debugger für PHP, mit Breakpoints, Stops, Watches, trace into. Step for Step... usw.?

Dieser hier scheint wohl nicht wirklich kostenlos zu sein.
http://www.nusphere.com/products/php_debugger.htm?gclid=CNj61suZ0ZsCFYYVzAodfVI2MA

Kennt den jemand?
Gibt's Alternativen?

Oder ne gute Idee, wie ich das ohne große Eingriffe ins Script mit Bordmitteln lösen könnte?

Es sind ca. 10 Variablen (die meisten davon Arrays) zu beobachten.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Sympathisant]

Hai,

wie bereits in einem Thread weiter unten erwaehnt:
Eclipse respektive PHPEclipse.
http://www.phpeclipse.com

Und zum Debuggen Xdebug bzw. DBG.

Anfaenglich war es ein relatives "Gluecksspiel" den Debugger zum Laufen zu bekommen. Mitterweile verhaelt sich das doch recht problemlos.

Nach dem Installieren/Konfigurieren stehen dir saemtliche Debuginformationen und -Moeglichkeiten - wie man sie aus anderen Sprachen gewoehnt ist - zu Verfuegung.

Allerdings:
Wenn Du das Problem lediglich in einer einzigen Methode siehst, so kannst du diese doch die Aufrufe loggen lassen. Mittels debug_backtrace() kommst du ja an die meiszten Informationen ran.

2. Kannst ja auch deine Klasse posten.

MfG,
Sympatisant

[Tom]

Hello,

2. Kannst ja auch deine Klasse posten.

Die ganz dicke Klassensammlung darf ich nicht posten, weil sie mir nicht gehört. Das wäre dann eventuell mein letztes Posting für längere Zeit.

Aber ich habe versucht, mit der Testversion von
http://www.nusphere.com/products/php_debugger.htm?gclid=CNj61suZ0ZsCFYYVzAodfVI2MA
den Bug in https://forum.selfhtml.org/?t=188733&m=1256831 zu finden.

Mein Bildschirm ist mit 1280x1024 definitiv zu klein dafür! :-(

Leider scheiterte ich gestern Nacht schon an den notwendigen Zutaten/Einstellungen des Debuggers. Für die Calculator-Klasse wird ein installiertes PEAR benötigt. Das kann der Debugger dann nicht finden. Das muss ich heute, wenn ich Zeit dafür finde, erstmal einrichten für den Debugger.

Aber das Ding scheint wirklich gut zu sein. Das kleine Video aus der Doku stellt auch alles ganz easy dar.

Schade nur, dass die Testversion nur 14 Tage läuft und ich garantiert keine 230 Dollar bewilligt bekomme dafür.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Sven Rautenberg]

Moin!

Aber ich habe versucht, mit der Testversion von
http://www.nusphere.com/products/php_debugger.htm?gclid=CNj61suZ0ZsCFYYVzAodfVI2MA
den Bug in http://forum.de.selfhtml.org/my/?t=188733&m=1256831&aaf=1 zu finden.

Mein Bildschirm ist mit 1280x1024 definitiv zu klein dafür! :-(

Dein Ansatz klingt so danach, als würdest du hoffen, dass ein Debugger dir die Lösung für den Bug liefert. Ich glaube nicht, dass dieser Gedanke zielführend ist und sich in Realität verwandeln wird.

Debugger erlauben es, zur Laufzeit des Skripts Dinge wie "schrittweises Ausführen" oder direkten Zugriff auf die aktuellen Inhalte von Variablen zu erhalten. Das mag relevant sein, wenn man dem Fehler auf der Spur ist und ihn schon entsprechend eingekreist hat.

Aber ohne eine Spur zu haben führt ein Debugger eigentlich nur dazu, dass man noch viel mehr Daten kriegt, die man erstmal filtern muss.

Ich glaube ja fest daran, dass die in PHP integrierten Möglichkeiten des Debuggings in 99% aller Fälle ausreichen, sofern man denn im Quellcode des Skriptes Änderungen durchführen kann.

PHP bietet zahlreiche interessante Funktionen an. Die einfachsten sind var_dump() und print_r() für die Wiedergabe von Variableninhalten (auch Objekten). Spannender - vor allem, wenn man ein komplexes Klassenkonstrukt hat - ist debug_backtrace() bzw. debug_print_backtrace(). Wenn man sich die Skriptausgabe nicht mit Debug-Ausgaben versauen will, ist auch error_log() eine prima Funktion, sofern das Skript nicht über einen eigenständigen Log-Mechanismus verfügt, den man an der Stelle einsetzen kann.

Aber das Ding scheint wirklich gut zu sein. Das kleine Video aus der Doku stellt auch alles ganz easy dar.

Ein Debugger rettet dir nicht deinen Arsch. Insofern ist der Name irreführend. Der Vorgang heißt englisch "Debugging", deutsch "Fehlersuche". Das Hilfsmittel dazu heißt englisch "Debugger", deutsch aber nicht "Fehlersucher" - der Fehlersucher sitzt VOR der Tastatur.

- Sven Rautenberg

[Tom]

Hello,

Ein Debugger rettet dir nicht deinen Arsch. Insofern ist der Name irreführend. Der Vorgang heißt englisch "Debugging", deutsch "Fehlersuche". Das Hilfsmittel dazu heißt englisch "Debugger", deutsch aber nicht "Fehlersucher" - der Fehlersucher sitzt VOR der Tastatur.

*schmunzel*
Wann hast Du denn das erste Mal einen Debugger benutzt?

Jau, der Debugger vor dem Schirm sucht auch schon seit gestern Nacht, erstmal in dem Calculator-Beispiel, um wieder warm zu werden mit der Materie "Debugging", bevor er sich dann an die eigentliche Aufgabe macht. Übung ist das halbe Leben (diesmal, sonst ist es Ordnung *g*).

Und eine Spur hat er scih beschafft mit Script-Modifikationen, wie

debug:

error_log(__LINE__.', $i: '.$i.', _input_array: '.implode(',',$this->_input_array).', $temp_value: '
                  .$temp_value.', $temp_operator: '.$temp_operator."\r\n",3,'errorlog.txt');

an diversen Stellen im Script.

Aber die zeigen nur, dass der Fehler tatsächlich in der vermuteten Methode steckt.

Ein Debugger macht das Tracing doch erheblich einfacher. Wenn man über eine Applikation keine Dokumentation hat (und da würde hier sowas wie Nassi-Shniderman oder auch PAP helfen), dann ist es nicht so ganz leicht, die verschlungenen Wege zu verfolgen.

Und das Schritt für Schritt zuschauen, wie und WO es weitergeht, ist schon eine nette Sache. Hat mir schon immer gefallen :-)

Vielleicht muss man am Ende ja auch noch in den PHP-Sourcecode schauen, wie die Array-Funktionen implementiert sind. Aber das bleibt erstmal als verrückte Idee im Hintergrund...

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[ChrisB]

Hi Sven,

[...] Ein Debugger rettet dir nicht deinen Arsch. Insofern ist der Name irreführend. Der Vorgang heißt englisch "Debugging", deutsch "Fehlersuche". Das Hilfsmittel dazu heißt englisch "Debugger", deutsch aber nicht "Fehlersucher" - der Fehlersucher sitzt VOR der Tastatur.

Ich denke nicht, dass du mit all dem Tom etwas neues sagst.

Ich glaube ja fest daran, dass die in PHP integrierten Möglichkeiten des Debuggings in 99% aller Fälle ausreichen, sofern man denn im Quellcode des Skriptes Änderungen durchführen kann.

Sicher reicht das in den allermeisten Fällen aus - aber *komfortabel* Debuggen sieht doch oftmals anders aus. Insb. wenn es ein komplexeres System ist - sich haufenweise gedumpte Objektinhalte anzusehen, durch mehrdimensionale Arrays zu wühlen etc., macht doch ab einer gewissen Komplexität keinen besonderen Spaß mehr. Und wenn's dann auch noch fremder Code ist ...

Da hat ein "richtiger" Debugger doch seine Vorteile, das wirst du doch kaum bestreiten wollen.
Schon allein die "Dynamik", dass du dir auch während des Scriptablaufes überlegen kannst, welche Variableninhalte interessant sein könnten - anstatt den Testlauf abzubrechen, weil du merkst, dass dir doch noch was fehlt, das Script wieder anzupassen, und dann von vorne loszulegen ...

Und mit Kontrollausgaben an bestimmter Stelle kannst du meinetwegen einen Breakpoint simulieren - aber z.B. sowas wie einen Watchpoint realisierst du auch nicht mal eben durch eine kleine Anpassung am Script.

MfG ChrisB

[Tom]

Hello,

How to "Pimp up my Eclipse" :-)

wie bereits in einem Thread weiter unten erwaehnt:
Eclipse respektive PHPEclipse.
http://www.phpeclipse.com

Und zum Debuggen Xdebug bzw. DBG.

Anfaenglich war es ein relatives "Gluecksspiel" den Debugger zum Laufen zu bekommen. Mitterweile verhaelt sich das doch recht problemlos.

Nach dem Installieren/Konfigurieren stehen dir saemtliche Debuginformationen und -Moeglichkeiten - wie man sie aus anderen Sprachen gewoehnt ist - zu Verfuegung.

Darauf muss ich nochmal etwas tiefer eigehen.
Da Eclipse für Java und für C++ noch auf meinem PC schlummert (ich habe schon wieder MOnAte nichts mehr damit gemacht), könnte ich die PHP-Extensions ja auch endlich mal instellieren.

Kannst Du einen kurzen Fahrplan geben, was man beachten muss, wo sich die Fallen befinden?

Ich habe hier
Eclipse Ganymede
Version: 3.4.0
Build id: I20080617-2000

und außerdem noch auf Vinzenz' Anraten eine Wascana-Version.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Sympathisant]

Hai Tom,

im Folgenden beziehe ich mich jetzt auf PHP 5, Apache 2, Eclipse
Ganymede, PHPEclipse 1.2 und Windows.
(Genauere Versionsangaben sind mir nicht mehr bekannt).

1. Mittels Software-Updates PHPEclipse installieren
   Siehe http://www.phpeclipse.com/wiki/Installation

2. Dann den DBG-Debugger herunterladen und installieren
   http://www.php-debugger.com/dbg/downloads.php
   Mit dem xdebug hat das bei mir nicht funkioniert.
   => Siehe weiter unten den letzten Punkt des Chat-Protokolls.
      Es muss afaik sogar deaktiviert werden (denn es ist
  automatisch mit PHPEclipse dabei)

3. Die php_dbg.dll muss dann ins ext-Verzeichnis von PHP.

4. Den Debugger registrieren. Hierfuer die php.ini editieren
   und am Ende folgendes hinzufuegen:
     [Debugger]
     extension=php_dbg.dll
     debugger.enabled=On
     debugger.profiler_enabled=On
     debugger.timeout_seconds=600
     debugger.JIT_enabled=Off
     debugger.JIT_host=clienthost
     debugger.JIT_clientport=7869
   Wichtig an dieser Stelle ist der Clientport. Denn ueber diesen
   sprichst du spaeter im Browser den Debugger an

5. phpinfo() sollte nach Neustart des Apaches dann ganz am Ende
   anzeigen, dass DBG in Betrieb ist.
   Startet der Apache an dieser Stelle nicht mehr, so liegt es an
   einer falschen Version der dll.

6. Unter Eclipse selbst muss dann noch der Interpreter angegeben
   werden. Also der Pfad zur php-win.exe.

7. Debug-Konfiguration (Dies ist der schwierigste Punkt)
   Wie auch unter Java auf das Debug-Symbol klicken (bzw. auf den
   Pfeil daneben) und eine neue Konfiguration anlegen.
   - Remote Debug und Cross Plattform debugging aktivieren
   - Open with DBGSession URL in internal Browser wahlweise aktivieren
     (ich rate jedoch dazu, einen von Eclipse unabhaengigen Browser zu benutzen)
   Ausschnitt:
   "Der Remote Sourcepfad müsste schon auf dem absoluten Pfad zur Datei,
    welche gedebugged werden soll stehen. Wenn nicht, ist dies anzugeben.
    Bei uns wäre das G:\IDE\xampp\htdocs\development\iEngine (da die zu
    debuggende Datei index.php dort liegt)
    Jetzt noch das Mapping. Unter Mapped Path klickt man auf Add und trägt
    den Pfad von eben sowohl als Local Path als auch als Remote Path ein.
    Jetzt steht also sozusagen 3 mal der gleiche Pfad da. Es funktioniert
    wirklich nur so. Lässt man die Pfade weg tut sich nichts.

8. Eclipse und Apache neustarten

9. Debug starten

10. Im Browser aufrufen:
    http://localhost/myproject/test.php?DBGSESSID=1@clienthost:10001
    Wobei der Clienthost aus der php.ini genommen werden muss.
    DBGSESSID=1 wird benoetigt um das Debugen zu registrieren.
    Moechtest du eine Debugsession wieder killen, so gebe statt dessen
    DBGSESSID=0 in der URL ein.

Was einzelne Probleme mit den Ports, Projekteinstellungen oder Fehlermeldungen
angeht, wirst du hier fuendig werden:
http://www.ilimitado.de/blog/programmierung/php-debugger-fur-eclipse/
Das war ueberigens die einzige(!) Anleitung netzweit, mit der es bei
mir funktioniert hat!

Allgemein fuehren die unterschiedlichen Versionen meiszt zu Problemen.
Hier genaustens darauf achten welche Versionen von welchem Plugin
unterstuetzt werden. Eine falsche .dll bringt einem nur Probleme ein
und fuehrt auch nicht zum gewuenschten Ergebnis.

Beachte auch, dass es bereits ein paar Monate her ist, als ich das bei
mir zum Laufen bekommen habe. Gut moeglich, dass sich mitterweile so
manches geaendert hat (Zumindest hatten PHPEclipse neulich einen
Relaunch ihrer Seite.. das koennte man so deuten als seien sie weiterhin
fleiszig am herumwerkeln).

So, und dann hatte ich mir damals noch Notizen gemacht, welche ich jetzt
nicht mehr ganz reproduzieren kann (habe aber im Hinterkopf dass sie
wichtig waren). Vllt. hilft es dir ja weiter. ..

Auszug des Chats:

[ee] deaktivier mal unter environemnt(1)->remote debug die option
"open..internal brwoser".. und rufe dann die URL manuell im externen
browser auf ( in etwa sowas:
http://localhost/myproject/test.php?DBGSESSID=1@clienthost:10001)..

[ee] und dann stell noch unter window->preferences->phpeclipse->Project Defaults
als Project URI folgendes ein: http://localhost/myproject dann klappts auch
im internen browser.

[ee] muss man dann fuer jedes projekt aendern.. aber meisstens arbeitet man ja
     eh nur mit einem..

[zr] was ist denn hiermt: http://www.xdebug.org/

[zr] war doch beim phpeclipse schon  dabei

[ee] das bringt nichts.. das musst du deaktivieren.. steht glaueb ich auch im
     tutorial.. wenn nicht, dann wie folgt: help->software updates->installed
usw.. nach xdebug feature suchen.. und auf uninstall klicken. danach eclipse
neustarten.. die beiden sachen vertragen sich nicht zusammen..

PS: Ich hoffe sehr, dass sich der Konfigurationsausfwand in den neueren
Versionen reduziert hat.

PPS: Wenn Du es zu Laufen bekommst, und Unterschiede hinsichtlich der
Installation und Konfiguration gefunden hast, kannst du das ja
anschlieszend hier posten.

MfG,
Sympatisant