2016-05-24 36 views
19

Mentre lavoravo oggi, sembrava che improvvisamente non potessi più eseguire il debug dell'applicazione. La cosa divertente è che, se eseguissi l'app normalmente, funzionerebbe perfettamente. Per chiarire, stavo facendo funzionare il debugger per tutta la mattinata senza incidenti (a parte il problema occasionale o il crash). Poi dopo pranzo cominciò a mancare il 100% delle volte. Certo, ho apportato modifiche tutto il giorno, da qui il "sembra" sopra. Quindi, ecco alcuni dettagli rilevanti:L'applicazione Debugger per Android Studio si blocca con InterruptedException

  • Android Studio 2.1.1 (28 apr 2016 build)

  • Questa applicazione si avvia con una schermata di accesso. L'utente deve quindi autenticarsi con un nome utente/password che chiama a un servizio esterno.

  • Posso accedere alla schermata di accesso, ma l'app si arresterebbe sempre nello stesso punto nel mezzo dell'autenticazione.

Ecco la traccia dello stack:

05-24 14:56:25.764 2399-2745/com.mycomp.myapp.test E/Crashlytics: Failed to execute task. 
        java.lang.InterruptedException 
         at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:375) 
         at java.util.concurrent.FutureTask.get(FutureTask.java:162) 
         at com.crashlytics.android.v.a(SourceFile:1936) 
         at com.crashlytics.android.v.uncaughtException(SourceFile:307) 
         at java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:693) 
         at java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:690) 
05-24 14:56:25.764 2399-2745/com.mycomp.myapp.test E/AndroidRuntime: FATAL EXCEPTION: pool-5-thread-1 
         Process: com.mycomp.myapp.test, PID: 2399 
         java.lang.InterruptedException 
          at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.reportInterruptAfterWait(AbstractQueuedSynchronizer.java:1991) 
          at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2025) 
          at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:410) 
          at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1035) 
          at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1097) 
          at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:588) 
          at java.lang.Thread.run(Thread.java:820) 

Qui sono le cose che ho provato a risolvere il problema:

  • Indietro tutte le mie modifiche (git scorta)
  • Disinstallare l'applicazione dal telefono
  • Eseguire una compilazione pulita
  • fare un Gradle progetto Resync
  • Rimuovere tutti i punti di arresto (sul serio?)
    • Ok, ho aggiungendo i punti di interruzione in tutto per vedere come funzionano le cose, quindi chi lo sa? C'è qualche merito lì.
  • Riavvia Android Studio! (spegnilo e riaccendilo)

E fino ad ora, niente funziona. Tuttavia, non posso sottolineare abbastanza che se eseguo semplicemente l'app (pulsante Play,^R) ed eseguo lo stesso dispositivo, funziona perfettamente! Accedi senza problemi. Quindi, non sembra essere un problema di codice.

Inoltre, se si guarda la traccia dello stack, non c'è nulla che indichi il nostro progetto.

Qualche idea?

risposta

30

Beh, l'ho capito. Risulta che ho avuto un "Java Field Watchpoint" selezionato con "Sospendi discussione" come una delle opzioni. Vedi lo screenshot allegato per chiarimenti. Takeaways:

Come potete vedere, ho usato un sacco di punti di interruzione, quindi è stato sepolto nella finestra e non l'ho visto.

Ancora non so come sia stato impostato. Avevo usato gli orologi il giorno precedente, ma li avevo cancellati tutti. Inoltre, sono abbastanza sicuro di non averlo acceso, quindi come ha misteriosamente smesso di funzionare nel bel mezzo della giornata è ancora un mistero. Inoltre, certamente non avrei controllato "sospendere il thread" da solo. Una sorta di impostazione predefinita?

Punto rimane: se si notano tracce di stack strani, potrebbe essere opportuno controllare tutti i punti di interruzione e impostazioni del punto di osservazione.

Spero che questo aiuti qualcuno.

Screenshot of BreakPoint Window in Android Studio

+5

Ho un problema molto simile! Tranne che non uso Watchpoint - solo punti di interruzione. Tutto funzionava e all'improvviso ha iniziato a bloccarsi sullo splash screen della mia app (dove avevo solo Thread.sleep (3000)). Ha iniziato a bloccarsi dopo aver aggiunto un punto di interruzione su un frammento che non raggiungeva nemmeno in caso di arresto anomalo, ma quando ho rimosso questo punto di interruzione ha iniziato a funzionare di nuovo. – Makalele

+0

wtf! Ho alcuni punti di interruzione e l'app si è arrestata in modo anomalo all'avvio. Rimosso loro e tutto bene ora! Ho sprecato ben 2 ore in questa merda. –

+0

@PrasadPawar - Capisco. Anche questa è stata la mia reazione. Spero che tu abbia trovato questo post prima che passasse troppo tempo! –

11

istantaneo Run sembra essere il colpevole (almeno nel mio caso con Android Studio 2.3.3). Invece di disabilitare i punti di interruzione, prova a disabilitare l'esecuzione istantanea. Una volta fatto questo, i punti di interruzione hanno cessato di causare arresti anomali.

Vedere Android app crashes when launched in debug mode per dettagli. Sotto Mac OS X, ho disabilitato l'esecuzione istantanea andando su Android Studio-> Preferenze-> Crea, Esecuzione, Deployment-> InstantRun e deselezionando "Abilita Esegui Esegui in hot swap ...".

C'è un "Problemi con Instant Run?" messaggio visualizzato nel pannello delle impostazioni. Ho fatto clic su "Riattiva e attiva la registrazione aggiuntiva", riprodotto l'arresto anomalo, quindi ho immediatamente segnalato utilizzando l'opzione "Guida - Segnala istanza di esecuzione istantanea ..." come richiesto.

+1

Questo problema esiste ancora in Android Studio 3.0 su Mac. – Gavriel

+0

Questo mi ha colpito anche su Android Studio 3.0.1 su Mac. Disabilitato Instant Run e potrebbe collegare il debugger senza causare il crash dell'applicazione. – Jed