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 habe gerade etwas Ähnliches wie safls Kommentar oben mit Komodo erlebt, bin aber nicht sicher, ob es damit zusammenhängt:

Ich hatte xdebug mit zend_extension mit Komodo eingerichtet und es funktioniert perfekt, kann Haltepunkte und xdebug_break() setzen, aber nur einige Dateien. Andere funktionierten nicht.

Die Lösung lag in der Art und Weise, wie die Zuordnung der entfernten und lokalen Pfade erfolgte. Es stellte sich heraus, dass Komodo einen Groß-/Kleinschreibung-Vergleich des Pfadnamens durchführt, so dass meine Zuordnung nicht ganz stimmte. Dateien, die der Debugger beim Durchlaufen öffnete, lagen im richtigen Pfad, aber Dateien, die ich über die Ide öffnete, hatten einen Laufwerksbuchstaben in Großbuchstaben, was Komodo offenbar übersehen hat.

Answer 2

Ich habe all diese Lösungen erfolglos ausprobiert. Ich war verwirrt, weil XDebug für eines meiner Projekte funktionierte, aber nicht für dieses neue. Nachdem ich durch den Vergleich der Konfigurationseigenschaften gestolpert war, erkannte ich, dass auf

Projekteigenschaften > Quellen > Web Root:

wurde der Wert auf einen default value für das neue Projekt, aber mit der Einstellung webroot zu dem bestehenden Projekt. Ich habe also die Webroot des Projekts aufgerufen und diesen Wert festgelegt. Ich habe es getestet und, bada-bing, es hat funktioniert.

Answer 3

Ich verwende Eclipse und habe auch eine Zeit lang danach gesucht. Alle Dinge in php.ini richtig gewesen.

Am Ende fand ich heraus, dass in der Eklipse wurde der Debugger so eingestellt ZEND-Debugger . Nachdem ich es geändert habe in XDEBUG hat es gut funktioniert.

Mit freundlichen Grüßen Jörg

Answer 4

Ich bin auch mit dem gleichen Problem. Ich habe die Lösung, die zum Laden der DLL-Datei sollten wir zend_extension verwenden.

zend_extension=php_xdebug-2.5.5-5.6-vc11.dll 

Die restliche Konfiguration wird

xdebug.remote_enable=1
xdebug.remote_host=localhost
xdebug.remote_port=9000
xdebug.remote_handler=dbgp

Answer 5

Ich hatte genau dasselbe Problem und habe mir eine Zeit lang den Kopf darüber zerbrochen. Irgendwann hatte ich auch ZendDebugger.so zu meiner PHP.ini hinzugefügt und das war es, was Xdebug kaputt machte. Das Auskommentieren der ZendDebugger.so Zeile in meiner php.ini hat das Problem behoben.

Wenn Sie ZendDebugger nicht verwenden, können Sie einfach andere Zend-Erweiterungen deaktivieren und sehen, ob es eine andere Erweiterung ist, die den Konflikt verursacht.