Le débogage à distance ne s'arrêtera pas aux points d'arrêt
J'ai un problème avec xdebug qui ne s'arrête pas aux points d'arrêt lors de l'utilisation du débogage à distance (tout va bien lors de l'exécution de scripts via la ligne de commande). Il s'arrêtera à la première ligne du programme, puis se fermera, n'attrapant aucun point d'arrêt.
Cela fonctionnait bien, jusqu'à ce que je passe à l'utilisation de MacPorts pour Apache et PHP. J'ai essayé de le recompiler plusieurs fois (avec plusieurs versions), mais pas de dés.
J'utilise PHP 5.3.1 et Xdebug 2.1.0-beta3
J'ai également essayé au moins 3 programmes de débogage différents (MacGDBp, Netbeans et JetBrains Web IDE).
Mes paramètres php.ini ressemblent à:
[xdebug]
xdebug.remote_enable=1
xdebug.remote_handler=dbgp
xdebug.remote_mode=req
xdebug.remote_port=9000
xdebug.remote_Host=localhost
xdebug.idekey=webide
Et lorsque j'enregistre la sortie du débogueur, la définition d'un point d'arrêt ressemble à ceci /;
<- 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>
Lorsqu'il est exécuté, le débogueur récupère le contexte de la première ligne de l'application, puis envoie les messages de détachement et d'arrêt.
Cependant, cette ligne est sortie lors du démarrage du débogueur.
<- 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>
L'exception de retour d'appel conditionnel en ligne signifie-t-elle quelque chose?
J'ai eu ce problème et m'a pris beaucoup de temps pour trouver la réponse.
Dans votre configuration de débogage, dans la zone du serveur, cliquez sur Configurer, accédez au mappage de chemin, cliquez sur le chemin qui s'y trouve et cliquez sur modifier, changez de chemin dans le système de fichiers et accédez au fichier approprié.
Terminé.
J'ai eu le même problème, et finalement j'ai trouvé que mon php.ini manquait ces deux paramètres importants:
xdebug.remote_autostart = "On"
xdebug.remote_enable = "On"
Ensuite, cela a parfaitement fonctionné.
XDebug fonctionne bien dans ma boîte Ubuntu Lucid utilisant NetBeans, et j'ai la ligne zend_extension dans mon php.ini (/etc/php5/Apache2/php.ini).
J'utilise netbeans 6.9 et PHP 5.2 avec xdebug 2.0.4-2
Je colle les lignes pertinentes ici, j'espère que cela aide:
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
de http://xdebug.org/docs/install , "Vous devez ignorer toutes les invites pour ajouter" extension = xdebug.so "à php.ini - cela causera des problèmes."
donc, cela m'a arrangé:
dans le fichier de configuration, où vous chargez l'extension xdebug (pour moi, pour la version CLI de php, qui était /etc/php5/cli/conf.d/xdebug.ini) - ne spécifiez pas
extension = xdebug.so
utilisez plutôt
zend_extension =/chemin/vers/xdebug/module/xdebug.so
(pour moi, c'était quelque chose comme /usr/lib/php5/(...)/xdebug.so)
J'ai eu le même problème, la solution pour moi était d'avoir le code local sur le même chemin que le code distant.
Exemple
Sur le serveur Web, le code se trouvait sur le chemin: /var/www/dev01/app_name
Localement, le code se trouvait dans mon répertoire personnel: /home/me/projects/app_name
Cette configuration a fait voler mon IDE (Eclipse et Komodo) directement devant les points d'arrêt.
Modification du chemin local de /home/me/projects/app_name à /var/www/dev01/app_name a résolu le problème. L'utilisation de sshfs pour monter localement le système de fichiers distant facilite encore plus les choses.
Je viens de vivre quelque chose de similaire au commentaire de safl ci-dessus en utilisant Komodo mais je ne sais pas si c'est lié:
J'ai installé xdebug en utilisant zend_extension avec Komodo et cela fonctionne parfaitement, peut définir des points d'arrêt et xdebug_break (), mais seulement certains fichiers. D'autres n'ont pas fonctionné.
La solution était dans la manière dont la cartographie des chemins distants et locaux s'est produite. Il s'avère que Komodo effectue une comparaison sensible à la casse sur le nom du chemin, donc mon mappage ne correspond pas tout à fait. Les fichiers ouverts par le débogueur étaient sur la bonne voie, mais les fichiers que j'ai ouverts via l'ide avaient une lettre majuscule qui a apparemment fait oublier Komodo.
J'ai essayé toutes ces solutions en vain. J'étais confus parce que XDebug a travaillé pour l'un de mes projets mais pas pour ce nouveau. Après être tombé sur la comparaison des propriétés de configuration, j'ai réalisé que sur
Propriétés du projet> Sources> Racine Web:
la valeur a été définie sur default value sur le nouveau projet, mais défini sur webroot sur le projet existant. J'ai donc parcouru le site Web du projet et défini cette valeur. Je l'ai testé et, bada-bing, ça a marché.
J'ai aussi le même problème. j'ai obtenu la solution que pour charger le fichier dll, nous devrions utiliser zend_extension.
zend_extension=php_xdebug-2.5.5-5.6-vc11.dll
La configuration de repos sera
xdebug.remote_enable=1
xdebug.remote_Host=localhost
xdebug.remote_port=9000
xdebug.remote_handler=dbgp
Je suis tombé sur cette même chose exacte et je me suis cogné la tête pendant un moment. À un moment donné, j'avais également ajouté ZendDebugger.so à mon PHP.ini et c'est ce qui cassait Xdebug. Commentant la ligne ZendDebugger.so dans mon php.ini l'a corrigé.
Si vous n'utilisez pas ZendDebugger, vous pouvez simplement commencer à désactiver d'autres extensions Zend et voir s'il s'agit d'une autre extension à l'origine du conflit.
J'utilise Eclipse et j'ai également cherché pendant un certain temps. Tout dans php.ini avait raison.
À la fin, j'ai découvert que dans Eclipse le débogueur était défini de manière ZEND-Debugger. Après l'avoir changé en XDEBUG, cela a bien fonctionné.
Cordialement Joerg
Êtes-vous totalement sûr de ne pas charger le Xdebug via extension=xdebug.so? Xdebug se chargera si cette ligne apparaît dans votre php.ini (C'est-à-dire qu'elle apparaît dans la sortie phpinfo(), etc.) mais les points d'arrêt ne fonctionnent pas s'ils sont chargés de cette façon. (Il se connecte même aux clients du débogueur et accepte les points d'arrêt - ils ne sont tout simplement jamais déclenchés.)
Je vous suggère de commenter la ligne zend_extension Et de voir si elle est toujours chargée - vous pourriez penser que vous chargez Xdebug via /etc/php5/conf.d/xdebug.ini, Par exemple, mais quelque chose l'a ajouté à /etc/php5/Apache2/php.ini derrière ton dos.
Voir cette question et réponse pour plus d'informations.
Je ne peux pas commenter un post donc ce post.
La solution à mon problème ressemblait beaucoup à celle de pitchandtone. Eclipce avait créé des éléments de mappage erronés et à double chemin. Néanmoins, je pouvais utiliser les chemins relatifs (c'est-à-dire/project/folder).
J'essayais de déboguer avec PhpStorm, mais cela ne s'est pas arrêté à certains points d'arrêt et j'ai commencé à ignorer encore plus alors que j'essayais toutes les solutions que je pouvais trouver avec Google.
Le problème était il y avait plusieurs processus PHP en cours d'exécution en arrière-plan qui géraient réellement mes demandes. PhpStorm ne s'arrêtait pas aux points d'arrêt car le processus que je déboguais n'était pas '' t recevoir des demandes. Tuer ces processus l'a résolu pour moi.
Pour résoudre les problèmes de débogage PHP CLI,
Ajoutez des variables d'environnement à ~/.bashrc (et rechargez-les ensuite):
export PHP_IDE_CONFIG="serverName=www.yourservernameurl.com"
export XDEBUG_CONFIG="idekey=PHPSTORM"
(J'utilise phpstorm, mais vous pouvez omettre le second si nécessaire)
J'y ai de temps en temps touché et je n'ai jamais pu découvrir la véritable cause du problème.
Je résous habituellement par,
Placer plus de points d'arrêt sur le code client pour construire les instances et charger les classes (car il semble que XDebug ignorera certains points d'arrêt en raison de problèmes de chargement de classe). Vous pouvez apprendre et réaliser où se trouvent ces emplacements en faisant quelques pas.
Vérifiez les chemins source des dépendances. XDebug récupère ces fichiers par leur chemin d'accès complet, vous pouvez voir comment votre IDE les traite dans votre panneau de point d'arrêt.
Dans mon cas, le problème se produisait dans un seul projet (je ne pouvais casser qu'en utilisant xdebug_break), tandis que dans les autres projets fonctionnait bien.
Il a été corrigé en modifiant le fichier: nbproject/private/private.properties: Et définissez:
copy.src.files=false
Lorsque j'ai créé le projet, j'ai sélectionné l'option "copier les sources" par erreur. Ensuite, j'ai déplacé manuellement le projet et modifié son chemin source (dans le fichier "nbproject/project.properties"), que le débogueur recherchait toujours l'ancien chemin (défini dans copy.src.target).
Donc, techniquement, une autre façon de résoudre ce problème de débogage est de recréer le répertoire nbproject (en le supprimant et en recréant le projet). Je suppose que le débogueur devrait fonctionner correctement avec l'option "copier" activée (car je ne l'utilise jamais).
J'espère que cela peut vous aider.
J'ai eu un problème similaire et suis tombé sur un message pour résoudre le problème. Mon formulaire html (testform.html) appelait un script php (runQuery.php) et Netbeans n'a pas pu s'arrêter aux points d'arrêt définis dans mon runQuery.php
Après avoir vérifié tous les paramètres de configuration dans php.ini et Netbeans en recherchant sur des forums comme celui-ci, j'ai découvert que les netbeans ne se briseraient que sur les points de rupture si le fichier d'index du projet est un PHP Ceci est très important, sinon vous passerez des heures à essayer de comprendre pourquoi les points d'arrêt ne fonctionnent pas.
Dans Netbeans, allez dans Fichier/Propriétés du projet/Exécuter la configuration et vérifiez que le fichier d'index est un fichier PHP. Dans mon cas, j'ai changé mon fichier d'index de testform.html en testform.php et il travaillé, j'ai pu casser sur des points de rupture.
Pourriez-vous fournir un journal de session complet tout en essayant de déboguer avec Web IDE?
BTW lors de l'utilisation de Web IDE vous n'avez généralement pas besoin de définir xdebug.idekey = webide car la clé ide est automatiquement attribuée via le paramètre url.
Il peut également y avoir un problème avec des symboles inhabituels sur le chemin. Par exemple, j'avais mon code localisé par chemin:
C:\[dev]\OpenServer\domains\...
Et je n'ai rien pu attraper, mais après avoir changé de chemin, le problème a disparu:
C:\dev\OpenServer\domains\...
Donc, même les crochets comptent.
Dans mon cas, lorsque je déplace l'élément zend_extension du dessus [xdebug] vers le dessous [xdebug], cela fonctionne bien.
;zend_extension = "D:\wamp\bin\php\php5.6.25\ext\php_xdebug-2.5.4-5.6-vc11-
x86_64.dll"
[xdebug]
zend_extension ="D:/wamp/bin/php/php5.6.25/zend_ext/php_xdebug-2.4.1-5.6-vc11.dll"
xdebug.auto_trace = On
xdebug.remote_enable = On
xdebug.remote_autostart = On
xdebug.profiler_enable = On
xdebug.profiler_enable_trigger = On
Je déteste ces configurations. Ma vie a changé quand j'ai connu le lib Dephpugger.
Est un débogueur à exécuter dans le terminal (comme ipdb pour Python et byebug pour Ruby). https://github.com/tacnoman/dephpugger est très facile à utiliser .
En ce qui concerne les chemins, le système de fichiers OSX n'est pas sensible à la casse, mais xdebug semble l'être.
Dans mon cas, tout semblait fonctionner même si j'exécutais le script en utilisant /proj/test.php au lieu de/ P roj/test.php.
Lorsque xdebug (ou au moins la version que j'ai actuellement) vérifie les points d'arrêt, la vérification est sensible à la casse. Si le point d'arrêt est défini pour /Proj/test.php, mais que le script est exécuté via /proj/test.php, il n'y a pas de correspondance.
J'ai également eu un problème similaire avec le chemin d'accès PHP include. Le chemin d'accès incluait/proj -directory, ce qui était faux. L'exécution du code a fonctionné, mais puisque les points d'arrêt ont été définis à l'aide de/Proj, ils étaient pas touché.
Pour vérifier si c'est bien le problème:
- Activez la journalisation, -dxdebug.remote_log =/tmp/remote.log
- Vérifiez le chemin exact dans le journal lorsque les points d'arrêt sont définis
- Comparez le chemin d'accès à l'interpréteur PHP utilise, par exemple: echo dirname (__ FILE__);
Juste pour une mise à jour rapide sur le sujet, j'ai eu un problème similaire avec ma nouvelle configuration de développement et c'était apparemment un problème de version: au moins avec PHP Version 7.1.20-1 + ubuntu16.04.1 + deb.sury.org + 1 xdebug 2.7.1 ne fonctionnait pas:
il a effectué avec succès la première demande (je suis sur un projet Symfony donc c'est router.php) mais ensuite quand mon IDE (PHPSTORM) lui a demandé un autre point d'arrêt il s'est juste écrasé donc pas de journal de point d'arrêt et de bien sûr ma page ne s'est pas chargée trop ^^.
Je l'ai compris en regardant le journal (dans php.ini, vous pouvez le personnaliser avec le paramètre xdebug.remote_log). J'espère que j'ai restauré xdebug à 2.6.1 et maintenant tout va bien.
J'espère que cela aide quelqu'un;)