Interpret Logcat entry: threadid = 8: still paused after cancellation (sc = 1 dc = 1 s = Y)

Question

I start about ten AsyncTasks after starting my application. Sometimes it takes a long time to run these tasks. When this happens, I see the following message in the cat log:

D / dalvikvm (1983): threadid = 8: still paused after canceling (sc = 1 dc = 1 s = Y)

When the emulator runs fast, this message does not appear. Oddly enough, this behavior has changed today without any change. Since I explicitly assigned 512 MB of bar to the emulator, it is no longer very slow ~ 5min, now ~ 5 s. On a real device, I will never have a run that slows down.

I would like to understand what this log cat message means. I understand that the thread with the specified id is suspended and does not work in this state. But why? Then cancel? What does (sc = 1 dc = 1 s = Y) mean?

Answer 1

The message comes from dvmSuspendSelf() , which calls threads when the debugger (via the JDWP thread) asked them to pause.

The way it should work (where "we" is the stream):

• JDWP asks us to suspend
• we say we paused and fell asleep
• In the end, the debugger wakes us up and we resume

The message is written to the log when the condition variable that the VM expects on the signals is, for some reason, still marked as paused. Code Notes:

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

The expectation in this case is that we woke up unexpectedly when a signal appeared (for example, system_server believes that ANR because the main thread does not respond, because the debugger stopped it), and if we loop the debugger again it will get a chance to clear us and set us on our way.

The log message prints the values self->suspendCount (how many times we were told to suspend ourselves), self->dbgSuspendCount (how many of these requests for suspension came from the debugger, so we can “cancel” all these if the debugger is turned off) and the value self->isSuspended boolean.

Please note that the flag "s = Y" disappeared in the gingerbread lock - the way the suspension worked was changed .

Answer 2

This thread is old, but this answer should be useful to users who stumble on this question after a few months.

Quoting user response on google group stream

There is a strange interaction between the VM and your debugger. the thread suspended itself and then waited to be woken up. However, when this was woken up, the thread was still marked as a suspended (s = 1) debugger (d = 1).

I met this on the emulator and on the phone itself. If the debugger is disconnected from the device (whether it is emulated or real), this condition is reset error. I did not find another way to avoid the problem.

Another SO answer claims this is because debug points are not in sync - DexFile.class error in eclipse

You can also try.

NTN

Answer 3

I am also facing a problem. Just because after I started a new Thread (), I tried to access materials in a thread that was already paused. This code is removed and the problem is resolved.

NTN