Interpretazione della voce Logcat: threadid = 8: ancora sospeso dopo l'annullamento (sc = 1 dc = 1 s = Y)

Question

Sono in esecuzione circa dieci AsyncTask dopo l'avvio dell'applicazione. A volte l'emulatore impiega molto tempo per iniziare queste attività. In questo caso, vedo il seguente messaggio nel gatto registro:

D/dalvikvm (1983): threadid = 8: ancora sospeso dopo l'annullamento (sc = 1 dc = 1 s = Y)

Quando l'emulatore viene eseguito rapidamente, questo messaggio non viene visualizzato. Stranamente, questo comportamento è cambiato oggi senza alcuna modifica. Dato che ho assegnato in modo esplicito 512mb ram all'emulatore, non è più estremamente lento ~ 5min, ora ~ 5s. Su un dispositivo reale non ho mai un'esecuzione così lenta.

Mi piacerebbe capire cosa significa questo messaggio cat log. Capisco che il thread con l'id specificato sia sospeso e non funzioni mentre si trova in questo stato. Ma perché? Dopo cosa annulla? Cosa significa (sc = 1 dc = 1 s = Y)?

Answer 1

Il messaggio viene da dvmSuspendSelf(), che infila chiamata quando il debugger (attraverso il filo JDWP) ha chiesto loro di sospendere.

Il modo in cui dovrebbe funzionare è (dove "noi" siamo un filo):

• JDWP ci chiede di sospendere
• diciamo che abbiamo sospeso e andiamo a dormire
• alla fine , il debugger ci sveglia e riprendiamo

Il messaggio viene registrato quando la condizione variabile VM è in attesa di segnali, ma per qualche motivo siamo ancora contrassegnati come sospesi.Le note di codice:

/* 
* The condition was signaled but we're still suspended. This 
* can happen if the debugger lets go while a SIGQUIT thread 
* dump event is pending (assuming SignalCatcher was resumed for 
* just long enough to try to grab the thread-suspend lock). 
*/ 

L'aspettativa in questo caso è che ci siamo svegliati improvvisamente quando un segnale è arrivato (ad es system_server pensa che ci sia un'ANR perché il thread principale non risponde perché il debugger ha sospeso esso), e se ci aggiriamo di nuovo, il debugger avrà la possibilità di ripulirci e metterci in cammino.

Il messaggio di log è la stampa i valori di self->suspendCount (quante volte c'è stato detto di sospendere noi stessi), self->dbgSuspendCount (quante di queste sospendere richieste venuto dal debugger, in modo che possiamo "annullare" tutti coloro che se il debugger disconnette) e il valore del valore booleano self->isSuspended.

Nota: il flag "s = Y" è scomparso nel pan di zenzero - il modo in cui la sospensione del thread funziona era changed.

Answer 2

Questa discussione è vecchia ma questa risposta dovrebbe fornire utili agli utenti che incappano in questa domanda mesi dopo.

Citando la risposta di un utente su un google group thread

C'è un'interazione strano tra la macchina virtuale e il vostro debugger. Il thread si è sospeso e quindi ha aspettato di essere svegliato. Tuttavia, quando è stato riattivato , il thread era ancora contrassegnato come sospeso (s = 1) dal debugger (d = 1).

L'ho trovato sull'emulatore e sul telefono stesso. Se il debugger è disconnesso dal dispositivo (sia esso emulato o reale), questa condizione di errore viene ripristinata. Non ho trovato nessun altro modo di sfuggire al problema.

Un altro SO rispondere sostiene che questo è a causa di punti di interruzione di debug che sono fuori sincrono - DexFile.class error in eclipse

Si può provare anche questo.

HTH

Answer 3

Anche io ho riscontrato il problema. Semplicemente perché dopo aver iniziato una nuova discussione(), ho provato ad accedere alla roba nella discussione che era già stata sospesa. Rimosso quel codice e il problema è stato risolto.

HTH