Perché il mio progetto Eclipse ha punti di interruzione del debugger fantasma?

Question

Ho un piccolo progetto che, eseguito nel debugger Eclipse, sembra sempre fermarsi nella riga 106 di FileInputStream.class, dove i file sono aperti. Non ci sono punti di interruzione impostati, ma Eclipse si comporta esattamente come se avessi qui un breakpoint. Se cancello tutti i punti di interruzione, succede ancora.

Ho un secondo progetto molto più grande nello stesso spazio di lavoro Eclipse che non soffre di questo problema.

Ho appena spostato il progetto più piccolo dalla mia vecchia macchina Linux, dove l'ho sviluppato in Europa Eclipse e ho avuto questo problema, nella mia nuova macchina Windows, dove continuo a vedere il problema in Ganymede Eclipse. Il problema persiste tra sistemi operativi e versioni di Eclipse, ma non tra i progetti. Non capisco! Ho sfogliato tutti i file nella directory di questo progetto e non sono riuscito a trovare nulla che potesse essere un file che in qualche modo dirigeva Eclipse a fermarsi in FileInputStream.

Ulteriori informazioni: il punto di interruzione apparente non è in realtà per la riga 106 di FileInputStream; sembra essere un punto di interruzione di eccezione per FileNotFoundException, essendo generato dal codice nativo chiamato da quella linea in FileInputStream. Ma ancora una volta, non sembra che i punti di interruzione siano stati impostati. I punti di interruzione delle eccezioni sono definiti altrove?

Answer 1

Forse si cerca di non-select

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

? (Come mentioned in this thread, per esempio)

Perché Eclipse funziona in questo modo?

E goes back to 2002, quando la gerarchia dell'oggetto punto di interruzione è stata ridotta.

Per impostare un punto di interruzione, con la vecchia API, un cliente ha richiesto Java Object Model - come IType, IField, ecc
Con la nuova API, tutto ciò che è richiesto dal modello di debug è di tipo nomi, nomi dei campi, ecc.

Ciò consente ai client di impostare i punti di interruzione quando Oggetti modello Java non sono disponibili.
I client ora specificano la risorsa per associare un punto di interruzione a (prima di vincolarlo alle risorse del modello Java associato).

I punti di interruzione possono ora essere "nascosti". Cioè, non hanno bisogno di essere registrati con il gestore di breakpoint.
I punti di interruzione possono anche essere mantenuti in modo selettivo (i marcatori hanno consentito la permanenza di tutti/nessuno di un tipo di indicatore).
Ciò rende il modello di debug più flessibile e offre ai client più elementi costitutivi.

Questo ha inoltre semplificato un po 'parte della nostra implementazione di debug Java - per esempio, la funzione "suspend on any uncaught exception", definisce semplicemente un punto di interruzione per il tipo denominato "java.lang.Throwable", piuttosto che una specifica IType in uno specifico progetto.
Il punto di interruzione non è registrato con il gestore di punti di interruzione (ad es.nascosto) - è noto e utilizzato solo da un client.
Un altro esempio è "run to line breakpoint". Il IJavaRunToLineBreakpoint è stato rimosso, poiché la sua funzionalità speciale non è più necessaria. Ora, il debug di Java, ui crea semplicemente un "punto di interruzione di linea" nascosto, non persistente e con un numero di successi pari a 1. Questo è un esempio di fornitura di blocchi predefiniti ai client.

Answer 2

Ho avuto un problema simile ma la soluzione accettata non ha funzionato per me. Sto facendo lo sviluppo di Eclipse per Android e ho impostato alcuni punti di interruzione e successivamente li ho disinseriti. Anche se li ho disabilitati, Eclipse ha continuato a fermare l'esecuzione a questi punti di rottura fantasma. La soluzione per me è stato quello di aprire la finestra Punti di interruzione:

Finestra> Mostra vista> Altro ...

Test> Punti di interruzione

Quindi fare clic su qualsiasi punto di interruzione e selezionare "Rimuovi tutto"

Sfortunatamente è necessario ripristinare tutti i punti di interruzione validi, ma questo ha funzionato per me e ha impedito che si verifichino molte angosce e frustrazioni.

Alcune immagini di guidare gli altri:

Answer 3

Per coloro che non trovano altre soluzioni utili, ho trovato la mia personale soluzione al mio problema. Lavoro con una libreria .jar che viene generata costruendo un altro progetto nello spazio di lavoro. Se imposto un breakpoint in un file .java nel progetto della libreria, il punto di interruzione verrà attivato quando si esegue il debug del progetto finale. Tuttavia, quando il debugger sospende l'esecuzione viene mostrato il file .class che ha i propri punti di interruzione e quindi il punto di interruzione impostato nel file .java non viene mostrato qui!

Soluzione: Al fine di rimuovere il punto di interruzione è necessario rimuovere il punto di interruzione nel file java, nel progetto di libreria.

Answer 4

Per coloro che non hanno trovato una soluzione dalle risposte precedenti, possono provare ciò che ha risolto il mio problema. Penso che sia simile al problema/soluzione HAL9000

Se si hanno due classi con lo stesso nome (in due progetti diversi) i punti di interruzione su uno, si applicano anche sull'altro. Entrambi appaiono nella finestra "Punti di interruzione".

Soluzione: Se si rimuove il punto di interruzione dalla classe - con lo stesso nome - che non lo si utilizza rimuove il punto di interruzione dalla classe di cui si sta eseguendo il debug.

Answer 5

Mi sono imbattuto in un problema in cui un file di origine aveva marcatori persistenti per punti di interruzione che non esistevano. Ho provato a pulire il progetto, a eseguire una compilazione completa, a riavviare Eclipse: niente ha funzionato.

Sono andato a scavare attraverso i metadati Eclipse e ho trovato il file .markers del progetto. L'eliminazione di quel file ha infine risolto il problema.

Per chiunque abbia questo problema, aprire la directory dello spazio di lavoro, quindi accedere a .metadata/.plugins/org.eclipse.core.resources/.projects/il progetto, quindi rinominare/rimuovere il file .markers.

Ad esempio, se la cartella di lavoro è ~/area di lavoro, e il progetto è denominato Foo, si potrebbe fare:

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