la session eclipse xdebug ne se termine jamais
J'essaie de faire fonctionner xdebug avec Eclipse (3.5)/php (sous xampp windows 7). J'ai vérifié que xdebug est activé dans php - j'ai la sortie de fantaisie et mon phpinfo montre toutes les choses xdebug. J'ai le débogage à distance et j'ai tapé l'adresse IP LAN sur ma machine Eclipse.
Lorsque je dis à Eclipse de déboguer, il lance le navigateur et transmet les paramètres d'URL de débogage. Cela semble OK.
Cependant, dans la perspective de débogage d'Eclipse, il indique "lancement de mon projet" à 57% "en attente d'une session xdebug". Il reste là pour toujours.
J'ai désactivé le pare-feu Windows sur les deux machines.
J'ai essayé d'activer la chasse d'eau implicite.
Des idées?
J'ai aussi eu ce problème et il me manquait cette ligne dans le php.ini fichier:
xdebug.remote_enable = On
Assurez-vous d'avoir défini zend_extention avec ABSOLU chemin dans le php.ini:
par exemple: zend_extension=D:\SANDBOX\server\php\php_xdebug-2.1.0-5.3-vc6.dll
Je débogue un projet local sur Windows. Jusqu'à présent, je n'avais pas besoin de xdebug.remote_enable = On.
Suggestions si la session Xdebug ne démarre pas (se bloque à 57%), assurez-vous que:
- La directive
zend_extentionEst définie avec un chemin absolu et le débogage est chargé, utilisezphpinfo()pour vérifier - le pare-feu ne bloque pas le port 9000 par défaut ni Eclipse.
- une autre application n'utilise pas le port (exécutez:
netstat -an |find /i "listening"à partir de la ligne de commande)
Si vous devez configurer un autre port, utilisez dans php.ini:
xdebug.remote_enable = on
xdebug.remote_port = XXXX
et corrigez les paramètres Xdebug dans Eclipse:
J'ai eu le même problème et je l'ai résolu en changeant le port en XDebug (maintenant en utilisant le port 9001).
Voici mon contenu php.ini:
zend_extension ="C:\...\EasyPHP-5.3.3\php\ext\php_xdebug-2.dll"
xdebug.remote_enable=1
xdebug.remote_Host=localhost
xdebug.remote_port=9001
xdebug.remote_handler=dbgp
xdebug.profiler_enable=0
xdebug.remote_mode=req
xdebug.remote_autostart=0
Vérifiez également le fichier journal Apache et assurez-vous que le message d'avertissement suivant ne s'affiche pas:
Avertissement PHP: Xdebug DOIT être chargé en tant qu'extension Zend dans Unknown sur la ligne 0
Avertissement: Xdebug DOIT être chargé en tant qu'extension Zend dans Inconnue en ligne
Si vous le faites, ouvrez le fichier php.ini et commentez avec un ';' les extension=php_xdebug-2.dll ligne:
;extension=php_xmlrpc.dll
extension=php_xsl.dll
**;extension=php_xdebug-2.dll**
;/PHPExt
J'ai eu le même problème avec Zend Studio. J'ai remarqué que la session xdebug ne démarrait pas correctement. J'ai passé cette chaîne à l'URL une fois et cela a fonctionné depuis.
http://localhost/myalias/?XDEBUG_SESSION_START=Eclipse_DBGP&KEY=13750956767461
Je suis sûr que c'est une question de configuration quelque part dans l'IDE.
Après avoir combattu pendant 3 heures et essayé toutes les solutions sur les forums, j'ai découvert que l'astuce était de supprimer les guillemets tout en spécifiant chemin de la DLL Xdebug in zend_extension in php.ini. J'utilise XAMPP (PHP 5.3.6 + Apache 2.2) + Eclipse Indigo + PDT + Xdebug 2.1.2 sur Windows Vista.
Voici la configuration exacte qui a fonctionné pour moi -
zend_extension=C:\xampp\php\ext\php_xdebug-2.1.2-5.3-vc6.dll
#Note that the path above is not in quotes
xdebug.remote_enable=true
xdebug.remote_Host=localhost
xdebug.remote_port=9001
xdebug.remote_handler=dbgp
xdebug.profiler_enable=1
xdebug.profiler_output_dir=C:\xampp\tmp
J'ai utilisé le port 9001 pour qu'il ne se heurte pas au 9000 au cas où il serait déjà utilisé par un autre programme. Assurez-vous que cela correspond au port dans Eclipse> Préférences> PHP> Debug> Xdebug aussi. Redémarrez Apache après avoir édité php.ini.
Une fois que j'ai ajouté cela à php.ini, tout a fonctionné comme de la crème glacée.
vérifiez ce lien:
Il y a une session sur les nouveaux plugins pour chrome et firefox et ils fonctionnent bien.
J'ai réalisé que TCP port était utilisé et que c'était la raison pour laquelle il se bloquait. J'ai changé de port dans les paramètres php.ini et Eclipse.
Vérifiez que les paramètres du navigateur Web d'Eclipse sont corrects.
Fenêtre/Préférences/Général/Navigateur Web/Navigateurs Web externes/Modifier les paramètres
Dans mon cas, le chemin vers le binaire du navigateur Web externe était incorrect. Il a dit "/ usr/bin/mozilla" au lieu de "/ usr/bin/firefox". Je ne sais pas comment ce paramètre a été créé, mais après l'avoir modifié, la fenêtre du navigateur Firefox est enfin apparue.
J'ai eu exactement le même problème. Mes configurations étaient comparables à la vôtre et en plus d'avoir xdebug.remote_enable = On dans le fichier php.ini en ajoutant également ce qui suit:
xdebug.remote_connect_back=1
cela permet le débogage distant multihôte, comme alternative, vous pouvez définir l'adresse IP de l'hôte.
xdebug.remote_Host=IP_ADDRESS
J'ai regardé dans le journal Apache et il y avait beaucoup de lignes avec une erreur de fichier introuvable.
Exécutez -> Configurations de débogage -> PHP -> Your_configuration
J'ai décoché auto generate et définissez le nom de fichier sur index.php.
Il semble qu'en cas d'erreur qui empêche Eclipse de fonctionner normalement, cela provoque une "attente de session"
Pour moi, l'ajout des configurations [xdebug] suggérées par d'autres à un fichier php.ini conservé dans le chemin suivant C:\wamp64\bin\Apache\apache2.4.23\bin a aidé. Il s'agit essentiellement d'un lien symbolique qui pointe/établit un lien vers le fichier phpForApache.ini sous votre dossier de version php respectif qui est installé avec wamp64, par exemple php5.6.25.
En bref, l'ajout des lignes suivantes phpForApache.ini pour m'a aidé -
zend_extension = c:\wamp64\bin\php\php5.6.25\ext\php_xdebug-2.5.1-5.6-vc11-x86_64.dll
xdebug.remote_enable=On
xdebug.remote_Host="localhost"
xdebug.remote_port=9000
xdebug.remote_handler="dbgp"
J'espère que cela t'aides
J'ai eu un problème similaire et il s'est avéré que j'utilisais la mauvaise DLL. J'espère que cela aidera quelqu'un à l'avenir.
Ce fil m'a aidé à régler mon problème avec MAMP sur OSX avec Eclipse. Après la mise à niveau vers MAMP 2.1.1 à partir de la version 1.x, je n'ai pas réussi à faire fonctionner xdebug dans Eclipse. Il pendait au niveau de 57%.
phpinfo a montré que l'extension xdebug se chargeait correctement et qu'il n'y avait aucune erreur dans les journaux PHP ou Apache.
Je voulais seulement déboguer localement, mais la raison du problème était que le débogage à distance n'était pas activé. L'ajout de xdebug.remote_enable = true au modèle MAMP PHP.ini et le redémarrage de MAMP ont résolu le problème.
- Les contributions ci-dessus étaient utiles. J'ai vérifié les valeurs des paramètres de xdebug dans phpInfo () et j'ai constaté que malgré mes réglages sur 1 ou On, auto_trace et remote_enable étaient désactivés. J'ai donc réussi à vrai. Et puis à distance travaillé!. Merci.
- Remarque, vous pouvez maintenant lancer la session de débogage à distance depuis Eclipse en configurant diverses configurations de débogage OU/et chaque fois que vous lancez une telle application configurée en dehors d'Eclipse, vous obtiendrez une question sur Eclipse pour accepter ou ne pas accepter la session de débogage. Donc, si vous êtes sur une machine différente de celle de l'interface utilisateur Eclipse, vous pouvez constater que l'appel à votre application est expiré sans raison. En fait, il y aurait une boîte de dialogue oui - non partout où se trouve la session Eclipse
Dans mon cas, l'application CLI fonctionnait bien, mais c'était l'application Web qui se bloquait à 57%.
Cela a fonctionné après 2 changements:
- fait un débogueur de serveur comme XDebug
- Générer automatiquement l'URL true.
Si Netweaver/Eclipse ne parvient pas à se connecter à XDebug, vous souhaiterez peut-être vérifier dans les journaux Apache les occurrences de quelque chose comme: Cannot load Xdebug - it was built with configuration API220090626,TS,VC6, whereas running engine is API220090626,TS,VC9 [Fri Jun 01 18:38:05 2012] [notice] Child 3404: Child process is running
Pour y remédier, choisissez la bonne version du binaire XDebug sur le site Web XDebug (essayez quelques combinaisons jusqu'à ce qu'il fonctionne)
Si votre configuration est correcte, supprimez simplement le fichier: YOUR_WORKSPACE/.metadata/.plugins/org.Eclipse.core.resources/.root/.markers
J'ai essayé toutes les solutions possibles sur ce post pour faire fonctionner xdebug sur un site fonctionnant sur Apache (port http 8000) en vain. J'ai ensuite accidentellement remarqué que xdebug fonctionnait sur un autre site que j'avais exécuté sur le port 80. Dès que j'ai changé l'autre site en port 80, il m'a finalement permis de le déboguer.
Je me demande s'il existe un paramètre qui peut diriger Apache pour autoriser xdebug sur d'autres ports que 80. J'ai plus d'un site fonctionnant dans Apache et je voudrais déboguer chacun sans avoir à reconfigurer les ports. Quelqu'un avait ce problème avant? ou sait comment le réparer?
Avant de paramétrer Eclipse, vérifiez que le contenu suivant est visible dans la fonction phpinfo.
Ce programme utilise le moteur de langage de script Zend: Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies with Xdebug v2.2.3, Copyright (c) 2002-2013, par Derick Rethans
Je ne sais plus ce que cela signifie pour toi ou pas! Mais, avez-vous atteint un fichier PHP (everything.php) avec le bon paramètre de débogage, quelque chose comme XDEBUG_SESSION_START=Eclipse_DBGP&KEY=12882809194391.
Les gens font souvent des erreurs pour frapper un fichier HTML avec les paramètres de débogage, ce qui provoque le blocage d'Eclipse lors de la session xdebug
Pour moi, ces symptômes ont été causés par le pare-feu Windows (Win7 Pro). Je devais autoriser explicitement Eclipse à passer le pare-feu. Je l'ai fait via la boîte de dialogue "Panneau de configuration\Tous les éléments du panneau de configuration\Pare-feu Windows\Programmes autorisés".
J'ai eu le même symptôme. Cependant, mon problème est que j'ai défini xdebug.remote_Host = "" J'ai fait cela parce que j'utilise des hôtes virtuels Apache pour éliminer le besoin de localhost. Cependant, je l'avais changé en xdebug.remote_Host = "localhost" puis modifiez mon Apache/etc/hpppd-vhosts.conf pour que le point localhost pointe vers mon root c:\web.
Oui, vérifiez les statistiques du réseau/port. Dans mon cas, j'utilise vmware fusion sur mac, et le processus vmware-natd monopolisait le processeur (blocage sur un port ouvert, je suppose), ce que je n'ai pas remarqué. php.ini était complètement bien, a dû l'exécuter pour le faire fonctionner à nouveau:
Sudo "/Library/Application Support/VMware Fusion/boot.sh" --restart
Alors ppl, vérifiez d'abord votre fichier php.ini (ou xdebug.ini). Si cela semble correct ala cette discussion , alors vérifiez que vous n'avez pas de problèmes de réseau.
Nous avons eu le même problème avec Uniserver Zero XIII 13.2.0 (nécessite une installation redistribuable MS VC12) et Eclipse Neon Release Candidate 3 (4.6.ORC3). Notre site Web utilise phalcon, lorsque nous avons trouvé un problème avec phalcon.dll et php7.0, nous sommes revenus à php5.6. Nous avons vérifié les paramètres de xdebug ci-dessus, ajouté zend_extension = $ (US_ROOTF) /php56/extensions/php_xdebug.dll - ne se connecterait pas, pas de points d'arrêt.
Trouvé un avertissement au sommet du projet de dialogue Eclipse | Propriétés | PHP | Débogage | Configurer les paramètres de l'espace de travail ... | PHP Exécutables | PHP56 (Espace de travail par défaut) | Modifier | Débogueur | "L'extension XDebug n'est pas installée. Veuillez visitez http://xdebug.org ... ". Cela nous a fait soupçonner la version de php_xdebug.dll (2.5.0) dans l'Uniserver 13.2.0 php56. J'ai téléchargé php_xdebug-2.4 .1-vc11.dll, l'a déposé dans/php56/extensions et PRESTO! Eclipse PHP Debugger fonctionne!
Cela pourrait ne pas être utile à tout le monde, mais ... lorsque vous essayez de déboguer des hôtes distants, n'oubliez pas toujours le routeur DSL! (ou n'importe quel routeur en cours de route) J'ai passé des heures à essayer de trouver une solution, quand j'ai remarqué que tout ce que j'avais à faire était d'activer la redirection de port (port 9000) sur mon Linksys et tout fonctionnait comme un charme :)
Moi aussi, j'ai rencontré le même problème. J'ai revérifié tous les paramètres en php avec la sortie de phpinfo() et tout allait bien.
Permettre à Java (TM) Platform SE binaire via le pare-feu a fait l'affaire.
Consultez les commandes de cette question , elles sont très utiles pour le débogage!