xdebug-Ferndebugging stoppt nicht an Haltepunkten

Question

Ich habe ein Problem damit, dass xdebug bei der Verwendung von Remote-Debugging nicht an Haltepunkten anhält (beim Ausführen von Skripten über die Befehlszeile ist alles in Ordnung). Es bricht bei der ersten Zeile des Programms ab und beendet sich dann, ohne irgendwelche Haltepunkte zu erfassen.

Früher hat das gut funktioniert, bis ich auf MacPorts für Apache und PHP umgestiegen bin. Ich habe mehrmals versucht, es neu zu kompilieren (mit verschiedenen Versionen), aber ohne Erfolg.

Ich verwende PHP 5.3.1 und Xdebug 2.1.0-beta3

Ich habe auch mindestens 3 verschiedene Debugging-Programme ausprobiert (MacGDBp, Netbeans und JetBrains Web IDE).

Meine php.ini-Einstellungen sehen wie folgt aus:

[xdebug]
xdebug.remote_enable=1
xdebug.remote_handler=dbgp
xdebug.remote_mode=req
xdebug.remote_port=9000
xdebug.remote_host=localhost
xdebug.idekey=webide

Und wenn ich die Debugger-Ausgabe protokolliere, sieht das Setzen eines Haltepunkts wie folgt aus/;

<- breakpoint_set -i 895 -t line -f file:///Users/WM_imac/Sites/wm/debug_test.php -n 13 -s enabled -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="breakpoint_set" transaction_id="895" state="enabled" id="890660002"></response>

Wenn er ausgeführt wird, erhält der Debugger den Kontext der ersten Zeile der Anwendung und sendet dann die Meldungen detach und stop.

Diese Zeile wird jedoch beim Starten des Debuggers ausgegeben.

<- feature_get -i 885 -n breakpoint_types -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="feature_get" transaction_id="885" feature_name="breakpoint_types" supported="1"><![CDATA[line conditional call return exception]]></response>

Bedeutet 'line conditional call return exception' etwas?

Answer 1

Ich hasse diese Konfigurationen. Mein Leben hat sich verändert, als ich die Lib Dephpugger kennenlernte.

Ist ein Debugger, der im Terminal läuft (wie ipdb für Python und byebug für Ruby). https://github.com/tacnoman/dephpugger Ist sehr einfach zu bedienen.

Answer 2

Ich kann keine Kommentare zu einem Beitrag abgeben, daher dieser Beitrag.

Die Lösung für mein Problem war ähnlich wie Pitchandtone sagte. Eclipce hatte falsche und doppelte Pfadzuordnungselemente erstellt. Trotzdem konnte ich die relativen Pfade verwenden (z.B. /project/folder).

Answer 3

Ich habe versucht, mit PhpStorm zu debuggen, aber es hielt nicht an einigen Haltepunkten an und fing an, noch mehr zu ignorieren, während ich jede einzelne Lösung versuchte, die ich mit Google finden konnte.

Das Problem war es liefen mehrere getrennte PHP-Prozesse im Hintergrund die meine Anfragen tatsächlich bearbeitet haben. PhpStorm hielt nicht an Haltepunkten an, weil der Prozess, den ich debuggte, keine Anfragen empfing. Das Beenden dieser Prozesse hat das Problem für mich gelöst.

Answer 4

Es kann auch ein Problem mit ungewöhnlichen Symbolen im Pfad geben. Ich habe zum Beispiel meinen Code nach dem Pfad gesucht:

C:\[dev]\OpenServer\domains\...

Und ich war nicht in der Lage, etwas zu fangen, aber nach der Änderung des Pfades verschwand das Problem:

C:\dev\OpenServer\domains\...

Selbst Klammern sind also wichtig.

Answer 5

Wenn es um Pfade geht, unterscheidet das OSX-Dateisystem nicht zwischen Groß- und Kleinschreibung, aber xdebug scheint dies zu tun.

In meinem Fall schien alles zu funktionieren, obwohl ich das Skript mit / p roj/test.php anstelle von / P roj/test.php.

Wenn xdebug (oder zumindest die Version, die ich derzeit habe) nach Haltepunkten sucht, wird die Groß- und Kleinschreibung beachtet. Wenn der Haltepunkt für /Proj/test.php gesetzt ist, das Skript aber über /proj/test.php ausgeführt wird, gibt es keine Übereinstimmung.

Ich hatte auch ein ähnliches Problem mit dem PHP-Include-Pfad. Der Pfad enthielt das /proj-Verzeichnis, was falsch war. Das Ausführen des Codes funktionierte, aber da die Haltepunkte mit /Proj gesetzt wurden, wurden sie nicht getroffen.

Prüfen Sie, ob dies das Problem ist:

• Protokollierung einschalten, -dxdebug.remote_log=/tmp/remote.log
• Prüfen Sie den genauen Pfad im Protokoll, wenn Haltepunkte gesetzt sind
• Vergleichen Sie den Pfad, den der PHP-Intepreter verwendet, zum Beispiel: echo dirname(__FILE__) ;