Pourquoi mon projet Eclipse a-t-il des points d'arrêt fantômes dans le débogueur ?

Question

J'ai un petit projet qui, lorsqu'il est exécuté dans le débogueur Eclipse, semble toujours s'arrêter à la ligne 106 de FileInputStream.class, où les fichiers sont ouverts. Il n'y a pas de points d'arrêt définis, mais Eclipse se comporte exactement comme si j'avais un point d'arrêt à cet endroit. Si j'efface tous les points d'arrêt, cela se produit toujours.

J'ai un deuxième projet beaucoup plus important dans le même espace de travail Eclipse qui ne souffre pas de ce problème.

Je viens de déplacer le petit projet de mon ancienne machine Linux, où je l'ai développé dans Europa Eclipse et où j'ai eu ce problème, sur ma nouvelle machine Windows, où je continue à voir le problème dans Ganymede Eclipse. Le problème persiste sur tous les systèmes d'exploitation et sur toutes les versions d'Eclipse, mais apparemment pas sur tous les projets. Je ne comprends pas ! J'ai parcouru tous les fichiers du répertoire de ce projet et je n'ai rien trouvé qui puisse être un fichier indiquant à Eclipse de s'arrêter dans FileInputStream.

Plus d'informations Le point d'arrêt apparent ne concerne pas la ligne 106 de FileInputStream ; il semble s'agir d'un point d'arrêt de type Exception pour FileNotFoundException, lancé par le code natif appelé à partir de cette ligne de FileInputStream. Mais là encore, il semble que je n'aie aucun point d'arrêt défini. Les points d'arrêt d'exception sont-ils définis ailleurs ?

Answer 1

Avez-vous essayé de désélectionner

Window > Preferences > Java > Debug : Suspend execution on uncaught exceptions

? (comme mentionné dans ce fil de discussion par exemple)

Pourquoi Eclipse fonctionne-t-il de cette manière ?

Il remonte à 2002 lorsque la hiérarchie des objets de point d'arrêt a été dépouillée.

Afin de définir un point d'arrêt, avec l'ancienne API, un client avait besoin d'objets de modèle Java - tels que IType , IField etc.
Avec la nouvelle API, tout ce qui est requis par le modèle de débogage est le nom des types, le nom des champs, etc.

Cela permet aux clients de définir des points d'arrêt lorsque les Java Model Objects ne sont pas disponibles.
Les clients peuvent maintenant spécifier la ressource à laquelle associer un point d'arrêt (auparavant, nous le limitions aux ressources associées au modèle Java).

Les points d'arrêt peuvent désormais être "cachés". . C'est-à-dire qu'ils n'ont pas besoin d'être enregistrés auprès du gestionnaire de points d'arrêt.
Les points d'arrêt peuvent également être persistés de manière sélective (les marqueurs ne permettaient de persister que tout ou rien d'un type de marqueur).
Cela rend le modèle de débogage plus flexible et donne aux clients davantage de blocs de construction.

Cela a également simplifié une partie de notre mise en œuvre du débogage Java - par exemple, la fonction " suspend on any uncaught exception ", définit simplement un point d'arrêt pour le type nommé " java.lang.Throwable ", plutôt qu'un IType dans un projet spécifique .
Le point d'arrêt n'est pas enregistré auprès du gestionnaire de points d'arrêt (c.-à-d. caché ) - il n'est connu et utilisé que par un seul client .
Un autre exemple est le " run to line breakpoint ". Le site IJavaRunToLineBreakpoint a été supprimé, car sa fonctionnalité spéciale n'est plus nécessaire. Désormais, l'interface de débogage Java crée simplement un "point d'arrêt de ligne" qui est caché, non persistant et dont le nombre d'occurrences est de 1. C'est un exemple de fourniture de blocs de construction aux clients.

Answer 2

J'ai eu un problème similaire mais la solution acceptée n'a pas fonctionné pour moi. Je fais du développement Eclipse Android et j'avais défini des points d'arrêt, puis je les ai désactivés. Même si je les ai désactivés, Eclipse a continué à arrêter l'exécution à ces points d'arrêt fantômes. La solution pour moi était d'ouvrir la fenêtre Breakpoints :

Fenêtre > Afficher la vue > Autre...

Debug > Points d'arrêt

Ensuite, faites un clic droit sur n'importe quel point d'arrêt et sélectionnez "Supprimer tout".

Malheureusement, vous devez réinitialiser tous vos points d'arrêt valides, mais cela a fonctionné pour moi et m'a évité beaucoup d'angoisse et de frustration à l'avenir.

Quelques photos pour guider les autres :

Answer 3

Pour ceux qui ne trouvent pas d'autres solutions utiles, j'ai trouvé une solution personnelle à mon problème. Je travaille avec une bibliothèque .jar qui est générée par la construction d'un autre projet dans l'espace de travail. Si je place un point d'arrêt dans un projet .java dans la bibliothèque, le point d'arrêt sera déclenché lors du débogage du projet final. Cependant, lorsque le débogueur met en pause l'exécution Le fichier .class est affiché et possède ses propres points d'arrêt. et donc le point d'arrêt placé dans le fichier .java n'apparaît pas ici !

Solution : Pour supprimer le point d'arrêt, vous devez supprimer le point d'arrêt dans le fichier .java, dans le projet de bibliothèque.

Answer 4

J'ai rencontré un problème où un fichier source avait des marqueurs persistants pour des points d'arrêt qui n'existaient pas. J'ai essayé de nettoyer le projet, de faire une construction complète, de redémarrer Eclipse - rien n'a fonctionné.

J'ai fouillé dans les métadonnées d'Eclipse et j'ai trouvé le fichier .markers des projets. La suppression de ce fichier a finalement résolu le problème.

Pour tous ceux qui rencontrent ce problème, ouvrez le répertoire de votre espace de travail, puis naviguez dans .metadata/.plugins/org.eclipse.core.resources/.projects/votre projet, puis renommez/supprimez le fichier .markers.

Par exemple, si le dossier de votre espace de travail est ~/workspace, et que votre projet s'appelle Foo, vous pouvez faire ce qui suit :

$ mv ~/workspace/.metadata/.plugins/org.eclipse.core.resources/.projects/Foo/.markers ~/safe.Foo.markers

Answer 5

Pour ceux qui n'ont pas trouvé de solution dans les réponses précédentes, ils peuvent essayer ce qui a résolu mon problème. Je pense que c'est similaire au problème/solution de HAL9000.

Si vous avez deux classes avec le même nom (dans deux projets différents), les points d'arrêt de l'une s'appliquent également à l'autre. Les deux s'affichent dans la fenêtre "Breakpoints".

Solution : Si vous supprimez le point d'arrêt de la classe - avec le même nom - que vous n'utilisez pas, cela supprime le point d'arrêt de la classe que vous déboguez.