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 hatte dieses Problem und habe lange gebraucht, um die Antwort zu finden.

Klicken Sie in Ihrer Debug-Konfiguration im Serverbereich auf Configure, gehen Sie zu Path Mapping, klicken Sie auf den dortigen Pfad und dann auf Edit, wechseln Sie zu Path in file system und navigieren Sie zur richtigen Datei.

Erledigt.

Answer 2

Ich hatte das gleiche Problem, und schließlich fand ich heraus, dass in meiner php.ini diese beiden wichtigen Einstellungen fehlten:

xdebug.remote_autostart = "On"
xdebug.remote_enable = "On"

Dann hat es perfekt funktioniert.

Answer 3

Von http://xdebug.org/docs/install Sie sollten alle Aufforderungen ignorieren, "extension=xdebug.so" zur php.ini hinzuzufügen - dies wird Probleme verursachen.

So, das war's für mich:

in der Konfigurationsdatei, wo Sie die xdebug-Erweiterung laden ( bei mir, für die CLI-Version von php, war das /etc/php5/cli/conf.d/xdebug.ini ) - geben Sie nicht an

erweiterung=xdebug.so

verwenden Sie stattdessen

zend_extension=/path/to/xdebug/module/xdebug.so

(bei mir war das etwas wie /usr/lib/php5/(...)/xdebug.so)

Verwenden Sie locate xdebug.so um den Standort zu finden.

Answer 4

XDebug funktioniert gut in meinem Ubuntu Lucid-Box mit NetBeans, und ich habe die zend_extension Zeile in meinem php.ini (/etc/php5/apache2/php.ini).

Ich verwende Netbeans 6.9 und PHP 5.2 mit xdebug 2.0.4-2

Ich füge die relevanten Zeilen hier ein und hoffe, dass sie hilfreich sind:

zend_extension=/usr/lib/php5/20060613/xdebug.so

[debug]
; Remote settings
xdebug.remote_autostart=on
xdebug.remote_enable=on
xdebug.remote_handler=dbgp
xdebug.remote_mode=req
xdebug.remote_host=localhost
xdebug.remote_port=9000
xdebug.idekey="netbeans-xdebug"

; General
xdebug.auto_trace=off
xdebug.collect_includes=on
xdebug.collect_params=off
xdebug.collect_return=off
xdebug.default_enable=on
xdebug.extended_info=1
xdebug.manual_url=http://www.php.net
xdebug.show_local_vars=1
xdebug.show_mem_delta=0
xdebug.max_nesting_level=100
;xdebug.idekey=

; Trace options
xdebug.trace_format=0
xdebug.trace_output_dir=/tmp
xdebug.trace_options=0
xdebug.trace_output_name=crc32

; Profiling
xdebug.profiler_append=0
xdebug.profiler_enable=0
xdebug.profiler_enable_trigger=0
xdebug.profiler_output_dir=/tmp
xdebug.profiler_output_name=crc32

Answer 5

Ich hatte das gleiche Problem. Die Lösung für mich war, den lokalen Code auf dem gleichen Pfad wie den Remote-Code zu haben.

Exemple

Auf dem Webserver befand sich der Code unter dem Pfad: /var/www/dev01/app_name

Lokal befand sich der Code in meinem Heimatverzeichnis: /home/me/projects/app_name

Diese Konfiguration führte dazu, dass meine IDE (Eclipse und Komodo) direkt an den Haltepunkten vorbeiflog.

Ändern des lokalen Pfads von /home/me/projects/app_name a /var/www/dev01/app_name Das Problem wurde behoben. Die Verwendung von sshfs zum lokalen Einhängen des entfernten Dateisystems macht es noch einfacher.