Interpretar entrada de Logcat: threadid = 8: aún suspendido después de deshacer (sc = 1 dc = 1 s = Y)

Question

Estoy ejecutando alrededor de diez AsyncTasks después de que se inicia mi aplicación. A veces, el emulador tarda mucho tiempo en comenzar estas tareas. Cuando esto ocurre, aparece el mensaje siguiente en el gato de registro:

D/dalvikvm (1983): threadid = 8: todavía suspendido después de deshacer (sc = 1 dc = 1 s = Y)

Cuando el emulador se ejecuta rápidamente, este mensaje no aparece. Extrañamente, este comportamiento cambió hoy sin modificaciones. Dado que he asignado explícitamente 512mb ram al emulador, ya no es extremadamente lento ~ 5min, ahora ~ 5s. En un dispositivo real, nunca tengo una ejecución tan lenta.

Me gustaría entender lo que significa este mensaje de registro de gato. Entiendo que el hilo con la identificación especificada está suspendido y no funciona mientras está en este estado. ¿Pero por qué? Después de lo que deshacer? ¿Qué significa (sc = 1 dc = 1 s = Y)?

Answer 1

El mensaje viene de dvmSuspendSelf(), que se enrosca llamada cuando el depurador (a través de la rosca JDWP) les ha pedido suspender.

La forma en que se supone que el trabajo es (donde "nosotros" somos un hilo):

• JDWP nos pide suspender
• le decimos que hemos suspendido y vamos a dormir
• finalmente , el depurador nos despierta y reanudamos

El mensaje se registra cuando la variable de condición que la VM está esperando en las señales, pero por alguna razón todavía estamos marcados como suspendidos.Las notas de código:

/* 
* 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). 
*/ 

La expectativa en este caso es que nos despertaba de forma inesperada cuando una señal llegó (por ejemplo system_server piensa que hay una ANR porque el hilo principal no responde porque el depurador ha suspendido ella), y si volvemos a dar vueltas, el depurador tendrá la oportunidad de limpiarnos y ponernos en camino.

El mensaje de registro se imprime los valores de self->suspendCount (cuántas veces nos han dicho a suspender nosotros mismos), self->dbgSuspendCount (¿cuántas de esas solicitudes suspender llegaron desde el depurador, por lo que puede "deshacer" todos aquellos si el depurador desconecta), y el valor de self->isSuspended booleano.

Tenga en cuenta que la bandera "s = Y" desapareció en pan de jengibre, la forma en que funciona la suspensión de hilos fue changed.

Answer 2

Este hilo es antiguo, pero esta respuesta debería ser útil para los usuarios que tropiecen con esta pregunta meses después.

Citando la respuesta de un usuario en un Google group thread

Hay una interacción raras entre la máquina virtual y el depurador. El hilo se suspendió y luego esperó a que lo despertaran. Sin embargo, cuando se despertó , el subproceso todavía estaba marcado como suspendido (s = 1) por el depurador (d = 1).

Me he encontrado con esto en el emulador y en el teléfono. Si el depurador se desconecta del dispositivo (ya sea emulado o real), esta condición de error se restablece. No he encontrado otra forma de escapar del problema.

otro para responder a las reclamaciones esto es debido a los puntos de interrupción de depuración están fuera de sincronía - DexFile.class error in eclipse

Puede probar eso también.

HTH

Answer 3

Yo también encontré el problema. Simplemente porque después de iniciar un nuevo Thread(), traté de acceder a las cosas en el hilo que ya había sido suspendido. Se eliminó ese código y se resuelve el problema.

HTH