Eclipse - Impossible d'installer le point d'arrêt en raison d'attributs de numéro de ligne manquants

J'obtiens cette étrange erreur dans Eclipse en essayant de définir un point d'arrêt.

Unable to insert breakpoint Absent Line Number Information

J'ai coché la case des options du compilateur mais pas de chance.

J'avais le même message d'erreur dans Eclipse 3.4.1, SUN JVM1.6.0_07 connecté à Tomcat 6.0 (fonctionnant en mode débogage sur une autre machine, Sun JVM1.6.0_16, la connexion de débogage fonctionnait correctement).

Fenêtre -> Préférences -> Java -> Compilateur -> Génération de fichier de classe: "ajouter des attributs de numéro de ligne au fichier de classe généré" a été coché. J'ai fait un nettoyage, une recompilation. Je l'ai décoché, recompilé, vérifié, recompilé. Je me suis assuré que le projet utilisait les paramètres globaux. Toujours le même message.

Je suis passé à la construction de fourmis, en utilisant

<javac srcdir="./src/java" destdir="./bin" debug="true">

Toujours le même message.

Je n'ai pas découvert la cause de ce message et pourquoi il ne disparaîtrait pas. Bien que cela semble avoir quelque chose à voir avec la session de débogage Tomcat en cours d'exécution: une fois déconnectée, la recompilation résout le problème. Mais lors de la connexion du débogueur à Tomcat ou lors de la définition de nouveaux points d'arrêt au cours d'une session de débogage connecté, il est réapparu.

Cependant, il s'est avéré que le message était faux : j'ai en effet pu déboguer et définir des points d'arrêt, à la fois avant et pendant le débogage ( javap -l a également montré les numéros de ligne). Alors ignorez-le :)

1. Dans le menu éclipse, allez dans Fenêtre-> Préférences-> Java-> Compilateur
2. Décochez la case "Ajouter des attributs de numéro de ligne ..."
3. Cliquez sur Appliquer -> Oui
4. Cochez la case "Ajouter un attribut de numéro de ligne ..."
5. Appliquer à nouveau.
6. Allez débogage heureux

Cela a résolu mon problème:

1. Fenêtre -> préférences -> serveur -> environnements d'exécution
2. Apache Tomcat -> modifier
3. Sélectionnez un JDK au lieu de JRE

Pour les problèmes liés à Spring , considérez que dans certains cas, il génère des classes "sans numéro de ligne"; par exemple une @Serviceclasse annotée sans interface, ajoutez l'interface et vous pouvez déboguer. voir ici pour un exemple complet.

@Service("SkillService")
public class TestServiceWithoutInterface {
   public void doSomething() {
      System.out.println("Hello TestServiceWithoutInterface");
   }
}

Le service ci-dessus aura une interface générée par spring provoquant des "numéros de ligne manquants". L'ajout d'une véritable interface résout le problème de génération:

public interface TestService {
    void doSomething();
}

@Service("SkillService")
public class TestServiceImpl implements TestService {
   public void doSomething() {
      System.out.println("Hello TestServiceImpl");
   }
}

J'ai la réponse à ce problème du côté du SDK BlackBerry: pour une raison quelconque, peu importe combien de fois j'ai changé les options dans le compilateur, le fichier de paramètres sous-jacent n'a pas changé.

Jetez un œil dans le dossier .settings de votre projet pour un fichier appelé org.eclipse.jdt.core.prefs .

Là, vous pouvez modifier les paramètres manuellement:

org.eclipse.jdt.core.compiler.debug.lineNumber=generate

edit: Suite à cela, j'ai remarqué que parfois je peux ignorer l'alerte qu'Eclipse donne, et elle s'arrêtera toujours à l'endroit requis ... lorsque vous travaillez en tant que dev.

Cela a fonctionné pour moi:

1. Sous Window --> Preferences --> Java --> Compiler --> Classfile Generation, toutes les options doivent être True.
2. Fabriqué debug="true"dans la <javac>tâche build.xml .
3. Déployer l'application dans le tomcat par la guerre générée par ant
4. Redémarrage du Tomcat en Debugmode

Je ne sais pas si cela est toujours d'actualité, peut-être qu'un autre marin trouvera cela utile.

Le message apparaît lorsqu'un fichier de classe a été compilé, les indicateurs de débogage sont désactivés.

Dans eclipse, vous pouvez l'activer par les options mentionnées ci-dessus,

Fenêtre -> Préférences -> Java -> Compilateur -> Génération de fichier de classe: "ajouter des attributs de numéro de ligne au fichier de classe généré"

Mais si vous avez un fichier jar, vous obtiendrez la sortie compilée. Il n'existe aucun moyen simple de résoudre ce problème.

Si vous avez accès à la source et utilisez ant pour obtenir le fichier jar, vous pouvez modifier la tâche ant comme suit.

  <javac  destdir="${build.destDir}" srcdir="${build.srcDir}" source="1.6" fork="true" target="${javac.target}" debug="on" debuglevel="lines,vars,source" deprecation="on" memoryInitialSize="512m" memoryMaximumSize="1024m" optimize="true"   >

Débogage heureux ..

réf: http://doc.sumy.ua/prog/Java/javanut/ch16_04.htm

J'ai essayé presque toutes les solutions ici et pas de chance. Avez-vous essayé de cliquer sur "Ne me redites plus"? Après cela, j'ai redémarré mon programme et tout allait bien. Eclipse a atteint mon point d'arrêt comme si de rien n'était.

La cause principale pour moi était qu'Eclipse essayait de configurer le débogage pour les objets proxy Spring CGLIB générés automatiquement. Sauf si vous devez déboguer quelque chose à ce niveau, vous devez ignorer le problème.

Il serait utile que vous indiquiez la version d'éclipse que vous utilisez et la technologie (Java JDT, ou AJDT pour Aspect Java, ou C ++ CDT par exemple), juste pour être sûr.

Du côté de Java, je suppose que votre "Cochez la case des options du compilateur" se réfère à cela

Sous " Window --> Preferences --> Java --> Compiler --> Classfile Generation", toutes les Class fileoptions de génération ' ' sont définies sur True:

• (1) ajouter des attributs variables,
• (2) ajouter des numéros,
• (3) ajouter le nom du fichier source,
• (4) conserver les variables locales inutilisées.

Est-ce que votre projet fait vérifier celles-ci uniquement au niveau global (Préférences Windows) ou au niveau spécifique du projet?

Et êtes-vous sûr que la classe a ouvert (sur laquelle vous essayez de définir un point d'arrêt):

• est l'une de vos sources (et ne provient pas d'une bibliothèque tierce)
• est un .java, pas un .class?

Essayez de tout nettoyer et de tout reconstruire, recherchez d'éventuels conflits de pots .

J'ai rencontré ce problème lors de la tentative de démarrage de Tomcat en mode débogage depuis Eclipse. J'avais un fichier de compilation ANT prenant en charge la compilation et le déploiement. Après avoir défini l'indicateur de débogage sur true (comme mentionné dans d'autres réponses) et redéployé l'application, cela a bien fonctionné:

<javac srcdir="./src/java" destdir="./bin" debug="true">

REMARQUE: si vous venez d'ajouter l'indicateur de débogage et recompilé, vous devez toujours redéployer votre application sur le serveur car c'est là qu'Eclipse débogue les fichiers de classe. Très évident, mais facile de passer une heure à se gratter la tête et de se demander pourquoi cela ne fonctionne pas (croyez-moi).

essayez de modifier le que jrevous utilisez. Définissez le jredans le dossier de à la JDKplace.

Étant donné que j'ai 6 versions différentes de Java installées, j'ai dû modifier ma conformité JDK par défaut pour correspondre à celle de la version Java que je voulais utiliser. Par défaut, Eclipse avait le niveau de conformité du compilateur défini sur Java 1.7 lorsque tout a été construit / compilé à l'aide de Java 1.6.

Donc tout ce que j'ai fait, c'est

1. Dans le menu éclipse, allez dans Fenêtre-> Préférences-> Java-> Compilateur
2. Sous Conformité JDK, j'ai changé le niveau de conformité du compilateur de 1,7 à 1,6

Maintenant, Eclipse ne se plaint plus de "Impossible d'insérer des informations sur les numéros de ligne absents des points d'arrêt" et les points d'arrêt de débogage fonctionnent réellement !!!

Si rien d'autre ne fonctionne, ouvrez la perspective de débogage, supprimez tous les points d'arrêt existants, puis redéfinissez-les.

Ceci est expliqué en détail ici:

https://github.com/spring-projects/spring-ide/issues/78

Juste pour référence future, c'est la partie pertinente de la réponse (ignorez le fait qui se réfère à une application Spring Boot, le comportement est le même pour beaucoup d'autres cas):

Chaque fois que vous définissez un point d'arrêt dans Eclipse / STS, l'EDI essaie de définir le point d'arrêt dans la machine virtuelle si vous lancez une application. C'est ce qui se passe dans votre cas lorsque vous exécutez l'application de démarrage en mode débogage.

Pour chaque classe chargée dans la JVM, l'EDI vérifie s'il doit définir un point d'arrêt ou non. S'il décide de définir le point d'arrêt, le tente de le faire (en utilisant les informations de la définition du point d'arrêt dans l'EDI, y compris son numéro de ligne, car vous définissez généralement des points d'arrêt de ligne sur un fichier source à une ligne donnée).

Cette décision (de définir ou non le point d'arrêt sur une classe chargée donnée) vérifie les types sur lesquels vous définissez le point d'arrêt, les types englobants et les classes internes. Cela garantit que les points d'arrêt pour les classes internes (même les classes internes anonymes) sont définis sur la JVM (et ne sont pas ignorés).

Spring Boot génère une classe interne pour votre contrôleur lors de l'exécution (il s'agit de la classe interne générée par CGLIB qui apparaît dans le message d'erreur). Lorsque la JVM charge cette classe, elle essaie de définir le point d'arrêt du numéro de ligne du type englobant (pour cette classe interne). Étant donné que la classe interne générée n'a pas d'informations sur le numéro de ligne (elle n'a pas besoin d'avoir d'informations sur le numéro de ligne), la définition du point d'arrêt échoue pour cette classe interne avec le message d'erreur mentionné.

Lorsque l'EDI charge le type englobant (votre classe de contrôleur elle-même), il essaie également de définir le point d'arrêt de ligne et y parvient. Ceci est visualisé avec le marqueur de contrôle sur le marqueur de point d'arrêt.

Par conséquent, vous pouvez ignorer en toute sécurité le message d'erreur qui s'affiche. Pour éviter que ce message d'erreur n'apparaisse, vous pouvez aller dans les préférences (Java -> Débogage) et désactiver "Avertir en cas d'impossibilité d'installer le point d'arrêt en raison d'attributs de numéro de ligne manquants".

Ma situation était similaire:

• Je déboguais un test JUnit
• J'utilisais Mockito pour créer un espion, comme dans spyTask = spy(new Task())
• J'ai mis le point d'arrêt à l'intérieur de la classe que j'espionnais (à l'intérieur Task.java)

Ce point d'arrêt génère l'erreur en question, chaque fois que je lance Debug As... > JUnit Test

Pour résoudre le problème, j'ai déplacé le point d'arrêt «vers le haut» dans le test réel (à l'intérieur de TaskTest.java). Une fois l'exécution arrêtée, j'ai rajouté le point d'arrêt là où je l'avais à l'origine (dans Task.java).

J'ai toujours la même erreur mais après avoir cliqué sur "ok", le point d'arrêt a très bien fonctionné.

J'espère que cela aide quelqu'un,

-gale

J'ai eu le même problème lorsque je faisais sur le serveur de la jetée et que je compilais un nouveau fichier .war par ANT. Vous devez créer la même version du compilateur jdk / jre et du chemin de génération (par exemple jdk 1.6v33, jdk 1.7, ....) après avoir défini le compilateur Java comme il a été écrit auparavant.

J'ai tout fait et je ne travaillais toujours pas. La solution a été de supprimer les fichiers .class compilés et la cible du fichier de guerre généré et maintenant son fonctionnement :)

Vous avez ce message avec Spring AOP (semble provenir de la bibliothèque CGLIB). Cliquer sur Ignorer semble bien fonctionner, je peux toujours déboguer.

J'ai trouvé une autre raison à ce message. Je programmais Scala. La solution était:

1. Open Run -> Debug configurations
2. Dans l'onglet principal, en bas, à côté des boutons "Appliquer" et "Revenir", il y a un texte indiquant quel lanceur vous utilisez, et à côté, il y a un lien hypertexte disant "Sélectionner autre". C'est un étrange élément d'interface utilisateur, ne semble pas actionnable à première vue.
3. Utilisez le lien "Sélectionner autre" et choisissez "Lanceur d'application Scala (nouveau débogueur)". L'autre ne semble pas fonctionner avec Scala.

Maintenant, le débogage devrait fonctionner. Notez que j'ai installé le plugin Scala IDE, cette option peut ne pas être disponible si vous ne l'avez pas.

Les choses ci-dessus n'ont pas fonctionné pour moi. Les solutions ci-dessous ont finalement fonctionné. Configurations de débogage -> Chemin de classe -> Entrées utilisateur -> (Ajoutez le dossier src du projet que vous souhaitez déboguer.)

J'ai eu ce même problème lors du débogage d'un WAR (construit à partir de plusieurs artefacts de projet Eclipse) déployé sur Tomcat.

Je construis tout en utilisant un script de construction ANT. Si c'est ce que vous faites, assurez-vous que l'indicateur debug = true est défini sur chaque tâche javac ant que vous avez. C'était mon seul problème - j'espère que ça aide votre problème!

J'ai eu la même erreur avec JBoss 7.1 .. Et j'ai fait la même chose que Zefiro. J'ai juste ignoré l'erreur et j'ai pu placer des points d'arrêt normalement. Dans mon cas, je construisais un constructeur de fourmis et c'est ma tâche javac:

<javac
        srcdir="${src.dir}"
        destdir="${build.classes.dir}" 
        includeantruntime="false" 
        debug="${debug}"
        verbose="false"
        debuglevel="lines,vars,source"
        source="1.6"
        target="1.6">

        <!-- Sppressing warning for setting an older source without bootclasspath
             (see: https://blogs.oracle.com/darcy/entry/bootclasspath_older_source) -->
        <compilerarg value="-Xlint:-options"/>

        <classpath>
            <fileset dir="${lib.dir}" includes="*.jar" />
            <fileset dir="${jboss.lib.dir}" includes="**/*.jar" />
        </classpath>

    </javac>

J'ai eu le même problème, j'ai passé beaucoup de temps à chercher une solution mais ces solutions sont inutiles, donc j'étudie moi-même tous les cas, enfin j'ai découvert un problème de conflit entre les versions JDK. Voici les étapes pour résoudre le problème: 1. Supprimez toutes les versions JDK et JRE, ne conservez qu'une seule version. 2. Définissez le système JAVA_HOME et le compilateur java dans Eclipse est le même. Dans certains cas, l'erreur ci-dessus ne disparaîtra pas, mais nous pouvons exécuter le modèle de débogage.

Une fois que j'ai rencontré la même erreur lorsque j'ai utilisé junit et Mockito, j'ai oublié d'ajouter @PrepareForTest pour une classe statique.

Ajouter le code ci-dessous a résolu mon problème.

@PrepareForTest({XXXXX.class})

_{Pas sûr que ce soit le même cas.}

Mon problème était que j'avais 2 fichiers JAR et j'essayais de remplacer l'un par l'autre en fonction de son ordre dans l' Java Build Path => Order & Exportonglet Eclipse, car l'un était pour le débogage et l'autre non (le JAR de débogage étant le premier dans l'ordre). Quand je l'ai fait de cette façon, j'ai dû attacher manuellement une source.

J'ai essayé de supprimer le JAR non de débogage et de placer le JAR de débogage dans mon répertoire \ WEB-INF \ lib \, de nettoyer, de construire, etc., et cela a fonctionné. Cette fois (après avoir supprimé la source attachée), cela me permettrait automatiquement de parcourir le code de débogage, sans avoir à attacher manuellement une source. Les points d'arrêt et le débogage ont également fonctionné.

Dans le cas où quelqu'un a encore des problèmes, j'ai également essayé toutes ces solutions particulières mentionnées dans les autres réponses:

• Décochez, appliquez et revérifiez Add line number attributes...
• Modification manuelle org.eclipse.jdt.core.prefscomme mentionné dans une autre réponse: https://stackoverflow.com/a/31588700/1599699
• S'assurer que le JAR était généré avec le débogage activé.
• Modification du niveau de conformité JDK de 1,6 à 1,7 (correspondant ainsi au JDK que j'utilisais).

J'ai également fait la fermeture habituelle du serveur (et en m'assurant que java.exe est réellement fermé ...), en supprimant les répertoires \ build \ dans les deux projets, en redémarrant Eclipse avec le paramètre -clean, en recréant le JAR de débogage, en rafraîchissant, nettoyage et construction du projet avec le fichier JAR de débogage, démarrage du serveur en mode débogage, publication / nettoyage et point d'arrêt.

J'ai fait tout ce qui est indiqué ci-dessus lors de la compilation / construction des bocaux - j'avais toujours le même problème.

Finalement, les changements de jvmarg répertoriés ci-dessous lors du démarrage du serveur sont ce qui a finalement fonctionné pour moi:

1) Supprimé / commenté un tas d'arguments jvm concernant javaagent et bootclasspath.

2) Activé / non commenté la ligne suivante:

Ensuite, lorsque je démarre le serveur, je peux atteindre mes points d'arrêt. Je soupçonne que l'agent java interférait d'une manière ou d'une autre avec la capacité d'Eclipse à détecter les numéros de ligne.

Vérifiez / procédez comme suit:

1) Sous "Fenêtre -> Préférences -> Java -> Compilateur -> Génération de fichier de classe", toutes les options doivent être à True:

(1) Add variable attributes...
(2) Add line number attributes...
(3) Add source file name...
(4) Preserve unused (never read) local variables

2) Dans le dossier .settings de votre projet, recherchez un fichier appelé org.eclipse.jdt.core.prefs. Vérifiez ou définissez org.eclipse.jdt.core.compiler.debug.lineNumber = generate

3) Si la fenêtre d'erreur apparaît toujours, cochez la case pour ne pas afficher le message d'erreur.

4) Nettoyez et construisez le projet. Démarrez le débogage.

Normalement, la fenêtre d'erreur ne s'affiche plus et les informations de débogage s'affichent correctement.

J'ai également rencontré ce problème. J'utilise un script de construction de fourmi. Je travaille sur une application héritée, j'utilise donc jdk version 1.4.2. Cela fonctionnait alors j'ai commencé à regarder autour de moi. J'ai remarqué que dans la configuration de débogage de l'onglet JRE, la version de Java avait été définie sur 1.7. Une fois que je l'ai changé à 1,4, cela a fonctionné.

J'espère que ça aide.

J'essayais de déboguer le gestionnaire de journalisation et je devais changer le jre en jdk, puis sélectionner ce jdk dans l'onglet "principal", "Java Runtime Environment" | "runtime JRE" de la configuration de débogage alors tout allait bien.

J'ai vu ce problème lorsque j'ai annoté une classe avec @ManagedBean (javax.annotation.ManagedBean). Le message d'avertissement est apparu lors de l'exécution de l'application nouvellement conforme sur JBoss EAP 6.2.0. L'ignorer et courir de toute façon n'a pas aidé - le point d'arrêt n'a jamais été atteint.

J'appelais ce bean en utilisant EL dans une page JSF. Maintenant ... il est possible que @ManagedBean ne soit pas bon pour ça (je suis nouveau sur CDI). Lorsque j'ai changé mon annotation en @Model, mon bean a été exécuté mais l'avertissement de point d'arrêt a également disparu et j'ai atteint le point d'arrêt comme prévu.

En résumé, il semblait certainement que l'annotation @ManagedBean fouillait les numéros de lignes, que ce soit ou non la mauvaise annotation à utiliser.

Assurez-vous que le projet dans lequel se trouve la classe principale du runtime est le même projet dans lequel se trouve la classe dans laquelle vous avez des points d'arrêt . Si ce n'est pas le cas, assurez-vous que les deux projets se trouvent dans le chemin de classe de la configuration d'exécution et apparaissent avant les fichiers JAR et les dossiers de classe.