Ricevo questo strano errore in Eclipse mentre provo a impostare un breakpoint.
Unable to insert breakpoint Absent Line Number Information
Ho selezionato la casella di controllo tra le opzioni del compilatore, ma senza fortuna.
Ricevo questo strano errore in Eclipse mentre provo a impostare un breakpoint.
Unable to insert breakpoint Absent Line Number Information
Ho selezionato la casella di controllo tra le opzioni del compilatore, ma senza fortuna.
Risposte:
Ho avuto lo stesso messaggio di errore in Eclipse 3.4.1, SUN JVM1.6.0_07 collegato a Tomcat 6.0 (in esecuzione in modalità debug su una macchina diversa, Sun JVM1.6.0_16, la connessione di debug funzionava correttamente).
Finestra -> Preferenze -> Java -> Compilatore -> Generazione file di classe: è stato verificato "aggiungi attributi numero riga al file di classe generato" . Ho fatto un clean, ricompilare. L'ho deselezionato, ricompilato, controllato, ricompilato. Mi sono assicurato che il progetto usasse le impostazioni globali. Sempre lo stesso messaggio.
Sono passato a Ant Build, usando
<javac srcdir="./src/java" destdir="./bin" debug="true">
Comunque, stesso messaggio.
Non ho scoperto cosa ha causato questo messaggio e perché non è andato via. Anche se sembrava avere qualcosa a che fare con la sessione di debug di Tomcat in esecuzione: quando disconnesso, la ricompilazione risolve il problema. Ma durante la connessione del debugger a Tomcat o l'impostazione di nuovi punti di interruzione durante una sessione di debug connessa, è apparso di nuovo.
Tuttavia, si è scoperto che il messaggio era sbagliato : ero davvero in grado di eseguire il debug e impostare i punti di interruzione, sia prima che durante il debug ( javap -l mostrava anche i numeri di riga). Quindi ignoralo :)
debug="true"
al javac
compito del ant
script di build ha funzionato.
Questo risolto il mio problema:
Installed JREs
impostazione predefinita è JDK
inveceJRE
Per le questioni relative alla primavera , si considera che in alcuni casi genera classi "senza numeri di riga"; ad esempio una @Service
classe annotata senza interfaccia, aggiungi l'interfaccia e puoi eseguire il debug. vedi qui per un esempio completo.
@Service("SkillService")
public class TestServiceWithoutInterface {
public void doSomething() {
System.out.println("Hello TestServiceWithoutInterface");
}
}
Il servizio sopra avrà un'interfaccia generata da spring causando "numeri di riga mancanti". L'aggiunta di una vera interfaccia risolve il problema di generazione:
public interface TestService {
void doSomething();
}
@Service("SkillService")
public class TestServiceImpl implements TestService {
public void doSomething() {
System.out.println("Hello TestServiceImpl");
}
}
Ho la risposta a questo problema dal lato BlackBerry SDK delle cose: per qualche ragione, non importa quante volte ho cambiato le opzioni nel compilatore, il file di impostazioni sottostante reale non è cambiato.
Dai un'occhiata nella cartella .settings del tuo progetto per un file chiamato org.eclipse.jdt.core.prefs .
Lì puoi modificare manualmente le impostazioni:
org.eclipse.jdt.core.compiler.debug.lineNumber=generate
modifica: Oltre a ciò, ho notato che a volte posso ignorare l'avviso che Eclipse emette, e si fermerà comunque nel luogo richiesto ... curioso e curioso ... Ho messo questo nel secchio delle cose che impariamo a gestire quando si lavora come dev.
Questo ha funzionato per me:
Window --> Preferences --> Java --> Compiler --> Classfile Generation
, tutte le opzioni devono essere True
.debug="true"
nell'attività build.xml <javac>
.Debug
modalitàNon so se questo è ancora rilevante, forse un altro marinaio lo troverà utile.
Il messaggio appare quando uno ha compilato un file di classe i flag di debug sono disattivati.
In eclipse, puoi attivarlo con le opzioni di cui sopra,
Finestra -> Preferenze -> Java -> Compilatore -> Generazione file di classe: "aggiungi gli attributi del numero di riga al file di classe generato"
Ma se hai un file jar, otterrai l'output compilato. Non esiste un modo semplice per risolvere questo problema.
Se hai accesso all'origine e usi ant per ottenere il file jar, puoi modificare l'attività di form come segue.
<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" >
Buon debug ..
Ho provato quasi tutte le soluzioni qui e senza fortuna. Hai provato a fare clic su "Non dirmelo più"? Dopo averlo fatto, ho riavviato il mio programma e tutto è andato bene. Eclipse ha colpito il mio punto di interruzione come se nulla fosse sbagliato.
La causa principale per me era che Eclipse stava cercando di impostare il debug per gli oggetti proxy Spring CGLIB generati automaticamente. A meno che non sia necessario eseguire il debug di qualcosa a quel livello, è necessario ignorare il problema.
Sarebbe utile se tu indicassi la versione di eclissi che stai usando e la tecnologia (Java JDT, o AJDT per Aspect Java, o C ++ CDT per esempio), per essere sicuri.
Sul lato Java, suppongo che la tua "spunta la casella di controllo dalle opzioni del compilatore" si riferisca a questo
In " Window --> Preferences --> Java --> Compiler --> Classfile Generation
", tutte le Class file
opzioni di generazione sono impostate su True:
I tuoi progetti sono stati controllati solo a livello globale (Preferenze di Windows) oa livello specifico del progetto?
E sei sicuro che la classe sia aperta (su cui provi a impostare un breakpoint):
.java
, non un .class
?Prova a pulire tutto e ricostruire tutto, controlla per potenziali conflitti di vaso .
Ho avuto questo problema durante il tentativo di avviare Tomcat in modalità debug da Eclipse. Avevo un file di build ANT che si occupava della compilazione e della distribuzione. Dopo aver impostato il flag di debug su true (come indicato in altre risposte) e aver ridistribuito l'applicazione, ha funzionato bene:
<javac srcdir="./src/java" destdir="./bin" debug="true">
NOTA: se hai appena aggiunto il flag di debug e ricompilato, devi comunque ridistribuire l'applicazione sul server poiché è qui che Eclipse sta eseguendo il debug dei file di classe. Molto ovvio ma facile passare circa un'ora grattandosi la testa e chiedendosi perché non funziona (fidati di me).
Poiché ho installato 6 diverse versioni di Java, ho dovuto modificare la mia conformità JDK predefinita in modo che corrispondesse a quella della versione Java che volevo usare. Eclipse per impostazione predefinita aveva il livello di conformità del compilatore impostato su Java 1.7 quando tutto era stato creato / compilato utilizzando Java 1.6.
Quindi tutto quello che ho fatto è stato
Ora Eclipse non si lamenta più dell '"Impossibile inserire le informazioni sul numero di riga dell'assenza del breakpoint" e i breakpoint di debug funzionano davvero !!!
Questo è spiegato in dettaglio qui:
https://github.com/spring-projects/spring-ide/issues/78
Solo per riferimento futuro, questa è la parte rilevante della risposta (ignora il fatto che si riferisce a un'applicazione Spring Boot, il comportamento è lo stesso per molti altri casi):
Ogni volta che si imposta un punto di interruzione in Eclipse / STS, l'IDE tenta di impostare il punto di interruzione nella macchina virtuale se si avvia un'app. Questo è ciò che accade nel tuo caso quando esegui l'app di avvio in modalità debug.
Per ogni classe che viene caricata nella JVM, l'IDE verifica se è necessario impostare un punto di interruzione o meno. Se decide di impostare il punto di interruzione, tenta di farlo (utilizzando le informazioni dalla definizione del punto di interruzione nell'IDE, incluso il suo numero di riga, poiché di solito si impostano i punti di interruzione di riga su un file di origine in una determinata riga).
Questa decisione (se impostare il punto di interruzione su una determinata classe caricata o meno) controlla i tipi su cui si imposta il punto di interruzione, i tipi di chiusura e le classi interne. Questo assicura che i punti di interruzione per le classi interne (anche le classi interne anonime) siano impostati sulla JVM (e non vengano ignorati).
Spring Boot genera una classe interna per il controller in fase di esecuzione (questa è la classe interna generata da CGLIB che appare nel messaggio di errore). Quando la JVM carica quella classe, tenta di impostare il punto di interruzione del numero di riga del tipo racchiuso (per questa classe interna). Poiché la classe interna generata non ha informazioni sul numero di riga (non è necessario disporre di informazioni sul numero di riga), l'impostazione del punto di interruzione non riesce per questa classe interna con il messaggio di errore menzionato.
Quando l'IDE carica il tipo racchiuso (la classe del controller stesso), tenta anche di impostare il punto di interruzione di linea e ha esito positivo. Questo viene visualizzato con il segno di spunta sul punto di interruzione.
Pertanto, puoi tranquillamente ignorare il messaggio di errore che viene visualizzato. Per evitare che questo messaggio di errore venga visualizzato, è possibile accedere alle preferenze (Java -> Debug) e disabilitare "Avvisa quando non è possibile installare il punto di interruzione a causa di attributi del numero di riga mancanti".
La mia situazione era simile:
spyTask = spy(new Task())
Task.java
)Questo punto di interruzione genera l'errore in questione, ogni volta che corro Debug As... > JUnit Test
Per risolvere il problema, ho spostato il Breakpoint 'su' nel test effettivo (all'interno di TaskTest.java). Una volta che l'esecuzione è stata interrotta, ho aggiunto il punto di interruzione nel punto in cui lo avevo, originariamente (all'interno di Task.java).
Ho ancora ricevuto lo stesso errore ma dopo aver fatto clic su "ok", il punto di interruzione ha funzionato bene.
Spero che aiuti qualcuno
-gmale
Ho avuto lo stesso problema quando stavo realizzando sul jetty server e compilando il nuovo file .war di ANT. Dovresti creare la stessa versione del compilatore jdk / jre e il percorso di compilazione (ad esempio jdk 1.6v33, jdk 1.7, ....) dopo aver impostato Java Compiler come scritto in precedenza.
Ho fatto tutto e ancora non funzionavo. La soluzione è stata eliminare i file .class compilati e la destinazione del file di guerra generato e ora funziona :)
Ho trovato un altro motivo per questo messaggio. Stavo programmando Scala. La soluzione era:
Ora il debug dovrebbe funzionare. Si noti che ho installato il plug-in IDE Scala, questa opzione potrebbe non essere disponibile se non lo si possiede.
Ho avuto lo stesso problema durante il debug di un WAR (costruito da più artefatti del progetto Eclipse) distribuito su Tomcat.
Sto costruendo tutto usando uno script di build ANT. Se questo è quello che stai facendo, assicurati che il flag debug = true sia impostato su ogni task javac ant che hai. Questo è stato il mio unico problema - spero che aiuti il tuo problema!
Ho avuto lo stesso errore con JBoss 7.1 .. E ho fatto lo stesso di Zefiro. Ho appena ignorato l'errore e sono stato in grado di posizionare normalmente i punti di interruzione. Nel mio caso stavo costruendo il generatore di formiche pensiero e questo è il mio compito 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>
Ho avuto lo stesso problema, ho trascorso molto tempo a cercare una soluzione, ma queste soluzioni sono inutili, quindi studio autonomamente tutti i casi, finalmente ho scoperto che è un conflitto tra le versioni di JDK. Di seguito sono riportati i passaggi per risolvere il problema: 1. Rimuovere tutta la versione di JDK e JRE, conservare solo una versione. 2. Impostare il sistema JAVA_HOME e il compilatore Java in Eclipse è lo stesso. In alcuni casi, l'errore sopra riportato non scomparirà, ma saremo in grado di eseguire il modello di debug.
Il mio problema era che avevo 2 JAR e stavo cercando di sovrascrivere l'uno con l'altro in base al suo ordine nella Java Build Path => Order & Export
scheda in Eclipse, perché uno era per il debug e l'altro no (il JAR di debug era il primo nell'ordine). Quando l'ho fatto in questo modo, ho dovuto collegare manualmente una fonte.
Ho provato a rimuovere il JAR non di debug e a posizionare il JAR di debug nella mia directory \ WEB-INF \ lib \, pulire, costruire, ecc., E ha funzionato. Questa volta (dopo aver rimosso la fonte allegata), mi avrebbe automaticamente permesso di navigare attraverso il codice di debug, senza dover allegare alcuna fonte manualmente. Anche i punti di interruzione e il debug hanno funzionato.
Nel caso in cui qualcuno abbia ancora problemi, ho anche provato tutte queste soluzioni particolari menzionate nelle altre risposte:
Add line number attributes...
org.eclipse.jdt.core.prefs
come indicato in un'altra risposta: https://stackoverflow.com/a/31588700/1599699Ho anche fatto il solito spegnimento del server (e assicurandomi che java.exe fosse effettivamente chiuso ...), eliminando le directory \ build \ in entrambi i progetti, riavviato Eclipse con il parametro -clean, ricreando il JAR di debug, aggiornando, pulizia e costruzione del progetto con JAR di debug al suo interno, avvio del server in modalità debug, pubblicazione / pulizia e breakpoint.
Ho fatto tutto ciò che è elencato sopra durante la compilazione / costruzione dei barattoli - ho ancora avuto lo stesso problema.
Alla fine, le modifiche jvmarg elencate di seguito durante l'avvio del server è ciò che alla fine ha funzionato per me:
1) Rimosso / commentato un gruppo di argomenti jvm relativi a javaagent e bootclasspath.
2) Attiva / non commentata la seguente riga:
Quindi, quando avvio il server, sono in grado di raggiungere i miei punti di interruzione. Sospetto che il javaagent interferisse in qualche modo con la capacità di Eclipse di rilevare i numeri di riga.
Controlla / procedi come segue:
1) In "Finestra -> Preferenze -> Java -> Compilatore -> Generazione file di classe", tutte le opzioni devono essere su True:
(1) Add variable attributes...
(2) Add line number attributes...
(3) Add source file name...
(4) Preserve unused (never read) local variables
2) Nella cartella .settings del tuo progetto, cerca un file chiamato org.eclipse.jdt.core.prefs. Verifica o imposta org.eclipse.jdt.core.compiler.debug.lineNumber = generate
3) Se viene ancora visualizzata la finestra di errore, fare clic sulla casella di controllo per non visualizzare il messaggio di errore.
4) Pulisci e costruisci il progetto. Inizia il debug.
Normalmente la finestra di errore non viene più visualizzata e le informazioni di debug vengono visualizzate correttamente.
Ho riscontrato anche questo problema. Sto usando uno script di build ant. Sto lavorando su un'applicazione legacy, quindi sto usando jdk versione 1.4.2. Questo funzionava, quindi ho iniziato a guardarmi intorno. Ho notato che sotto la configurazione di debug nella scheda JRE la versione di Java era stata impostata su 1.7. Una volta cambiato in 1.4 ha funzionato.
Spero che questo possa essere d'aiuto.
Stavo provando a eseguire il debug del gestore della registrazione e avevo bisogno di cambiare jre in un jdk e quindi di selezionare questo jdk nella scheda "principale", "Java Runtime Environment" | "Runtime JRE" della configurazione di debug quindi tutto andava bene.
Ho visto questo problema quando ho annotato una classe con @ManagedBean (javax.annotation.ManagedBean). Il messaggio di avviso è apparso durante l'esecuzione dell'app appena rispettata su JBoss EAP 6.2.0. Ignorarlo e correre comunque non aiutò: il punto di interruzione non fu mai raggiunto.
Stavo chiamando quel bean usando EL in una pagina JSF. Ora ... è possibile che @ManagedBean non vada bene (sono nuovo su CDI). Quando ho cambiato la mia annotazione in @Model, il mio bean è stato eseguito ma anche l'avviso di breakpoint è andato via e ho colpito il breakpoint come previsto.
In sintesi, sembrava che l'annotazione @ManagedBean incasinasse i numeri delle linee, indipendentemente dal fatto che fosse o meno l'annotazione sbagliata da usare.
Assicurarsi che il progetto in cui si trova la classe principale del runtime sia lo stesso progetto in cui è la classe in cui sono presenti i punti di interruzione . In caso contrario, assicurarsi che entrambi i progetti si trovino nel percorso di classe della configurazione di esecuzione e che vengano visualizzati prima di qualsiasi vasetto e cartella di classe.