Eclipse – le débogueur ne s’arrête pas au point d’arrêt

J’essaie de dépanner un JUnit. Dans le code source, j’ai défini un point d’arrêt à deux endroits: 1) dans une ligne où un membre statique est initialisé 2) la première ligne d’un des cas de test.

Le débogueur s’arrête dans la ligne d’initialisation du champ statique. Mais cela ne s’arrête pas dans le cas de test. Peu importe où je définis le point d’arrêt dans le scénario de test, le débogueur ne s’arrête pas là. Je suis certain que le scénario de test est exécuté car je peux voir les messages de journal que j’ai ajoutés apparaissent dans le journal.

Toute aide serait grandement appréciée.

J’utilise le lanceur Eclipse Galileo et JUnit4.

Cela peut être lié à l’un des bogues de JDK 6 Update 14, comme indiqué dans les notes de publication de JDK 6 update 15 .

Si cela s’avère effectivement être le problème, vous devriez passer à une version supérieure du JDK (ce n’est pas une garantie, puisque des correctifs ont été publiés contre 6u16, 6u18 et 7b1 ). Le meilleur pari est d’utiliser l’option -XX: + UseParallelGC. Augmenter la taille de la taille minimale et maximale du segment de mémoire, pour retarder le premier GC, apporte un soulagement temporaire.

Au fait, utilisez ce rapport de bogue dans Eclipse pour savoir comment les autres se sont comportés.

Le correctif pourrait être aussi simple que de cliquer sur exécuter / ignorer tous les points d’arrêt. Travaillé pour moi

Assurez-vous, sous Exécuter> Configurer le débogage, que l’option “Arrêter en principal” est sélectionnée, le cas échéant.

Habituellement, lorsque cela m’arrive (rare mais cela arrive), cela signifie que le code en cours d’exécution est différent du code de l’éditeur. Il arrive de temps en temps pour Eclipse que les classes construites et le code dans l’éditeur ne soient pas synchronisés. Lorsque cela se produit, je reçois toutes sortes de comportements bizarres du débogueur (débogage des lignes vides, saut des lignes de code, etc.).

Redémarrer Eclipse, nettoyer tous les projets et reconstruire tout en général J’avais aussi les plugins Maven (les anciennes versions… ne l’avaient pas eu depuis longtemps) qui avaient tendance à le faire aussi.

Sinon, ce pourrait être un bug, peut-être celui que Vineet a déclaré,

J’espère que cela t’aides

Vous avez peut-être accidentellement ignoré tous les points d’arrêt dans la barre d’outils Eclipse. Pour résoudre ce problème, allez dans Eclipse -> Run -> Skip All Breakpoints.

Projet -> Clean semblait fonctionner pour moi sur JRE 8

Pour JDK7, exécutez-> Configurations de débogage, cochez “Garder JUnit en cours d’exécution après un test lors du débogage”.

Est arrivé à moi une fois, quand j’avais décoché “Exécuter> Construire automatiquement” et j’ai oublié de le vérifier à nouveau.

Assurez-vous de déclarer le paquet en haut. Dans mon code, cela s’arrête aux points d’arrêt:

package Pkg1 import java.awt.event.ItemEvent; isMule = false class LineItem { // Structure defining individual DB rows public Ssortingng ACCOUNT_CODE public Ssortingng ACCOUNT_DESC ... 

Cela ne s’arrête pas aux points d’arrêt:

 import java.awt.event.ItemEvent; isMule = false class LineItem { // Structure defining individual DB rows public Ssortingng ACCOUNT_CODE public Ssortingng ACCOUNT_DESC ... 

Pour que le débogueur fonctionne avec remote, les fichiers java .class doivent être conformes aux informations de débogage. Si l’option ” -g: none ” a été transmise au compilateur, le fichier de classe n’aura pas les informations nécessaires et le débogueur ne sera donc pas en mesure de faire correspondre les points d’arrêt sur le code source avec cette classe à distance. En attendant, si les fichiers jars / class étaient obscurcis , ils n’auraient pas non plus d’informations de débogage. Selon vos réponses, ce n’est probablement pas votre cas, mais cette information pourrait être utile pour ceux qui sont confrontés au même problème.

Dans mon cas, le problème était que je n’avais pas la vue Debug ouverte dans la perspective Debug, donc:

1 – Assurez-vous que la perspective de débogage est ouverte:

débogueur éclipse ne fonctionne pas 1

2 – Assurez-vous que la vue de débogage est ouverte:

le débogueur d'éclipse ne fonctionne pas 2

Supprimez tous les points d’arrêt et rajoutez-les.

Pour supprimer les points d’arrêt :

  1. Déboguer votre classe en tant que test de junit
  2. Lorsque votre débogueur s’arrête, cliquez sur l’onglet “points d’arrêt” à côté de “variables” et “expressions”
  3. En haut à droite de l’onglet des points d’arrêt, cliquez sur le bouton avec deux «X»
  4. Arrêtez le test, remplacez votre point d’arrêt et réexécutez le débogueur

Un commentaire supplémentaire concernant Vineet Reynolds répond.

J’ai découvert que je devais définir -XX: + UseParallelGC dans eclipse.ini

Je configure les arguments vm comme suit

 -vmargs -Dosgi.requiredJavaVersion=1.7 -Xms512m -Xmx1024m -XX:+UseParallelGC -XX:PermSize=256M -XX:MaxPermSize=512M 

qui a résolu le problème.

Vérifiez également si les points d’arrêt des autres lignes fonctionnent, cela peut être un bogue dans le débogueur. J’ai eu un problème avec le débogueur Eclipse où le fait de placer un point d’arrêt sur une affectation booléenne dont le code était sur la ligne suivante ne fonctionnait pas.

Si rien ne fonctionne –

  1. Supprimez cette configuration de débogage distante / locale et créez-en une nouvelle.
  2. Ajoutez la source dans les configurations de débogage.

Un autre problème possible est que le port du débogueur peut être bloqué par le pare-feu. Par exemple, j’utilisais le studio mule anypoint (v 5.4.3). Le port du débogueur par défaut est 6666. Lorsqu’un stream est exécuté, il ne s’arrête pas au point d’arrêt. quand j’ai changé le port à un autre (par exemple 8099), cela a fonctionné très bien.

Allez à Right click->Debug Configuration et vérifiez si trop d’instances de débogage sont créées. Mon problème a été résolu lorsque j’ai supprimé plusieurs instances de débogage de la configuration et que le débogage a commencé.

Si vous êtes sur Eclipse,

Faites un clic droit sur le dossier de votre projet sous “Explorateur de paquets”.

Goto Source -> Nettoyez et choisissez votre projet.

Cela permettra de nettoyer tout désordre et votre sharepoint rupture devrait fonctionner maintenant.

Créer un nouvel espace de travail a fonctionné pour moi.

Dans mon cas, j’ai eu plusieurs projets dans le même espace de travail. Le fichier java que j’essayais de déboguer était présent dans plusieurs projets avec le même package.

Je n’ai pas eu besoin de l’autre projet, donc j’ai simplement fermé des projets sans rapport (ou supprimé le fichier d’un projet sans rapport).

C’est ce qui fonctionne pour moi:

J’ai dû mettre l’adresse de mon serveur local dans la configuration de PHP Server comme ceci:

entrer la description de l'image ici

Note : cette adresse est celle que je configure dans mon fichier Apache .conf .

Note : le seul point d’arrêt qui fonctionnait était la “rupture à la première ligne”, après quoi les points d’arrêt ne fonctionnaient pas.

Remarque : vérifiez vos propriétés xdebug dans votre fichier php.ini et supprimez toutes les fonctionnalités qui ne vous semblent pas nécessaires.