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

Question

I am running around ten AsyncTasks after my application starts. Sometimes the emulator takes a long time to start these tasks. When this occurs, I see the following message in the log cat:

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

When the emulator executes quickly this message doesn't appear. Strangely, this behavior changed today without any modifications. Since I have explicitly assigned 512mb ram to the emulator, it is no longer extremely slow ~5min, now ~5s. On a real device I never have execution that slow.

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

Answer 1

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

The way it's supposed to work is (where "we" are a thread):

• JDWP asks us to suspend
• we tell it we've suspended and go to sleep
• eventually, debugger wakes us up and we resume

The message is logged when the condition variable the VM is waiting on signals, but for some reason we're still marked as suspended. The 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 got woken up unexpectedly when a signal arrived (e.g. system_server thinks there's an ANR because the main thread isn't responding because the debugger has suspended it), and if we loop around again the debugger will get a chance to clean us up and set us on our way.

The log message is printing the values of self->suspendCount (how many times have we been told to suspend ourselves), self->dbgSuspendCount (how many of those suspend requests came from the debugger, so we can "undo" all those if the debugger disconnects), and the value of the self->isSuspended boolean.

Note the "s=Y" flag disappeared in gingerbread -- the way thread suspension works was changed.

Answer 2

This thread is old but this answer should provide useful for users stumbling across this question months later.

Quoting a user's reply on a google group thread

There's a weird interaction between the VM and your debugger. The thread suspended itself and then waited to be woken. However, when it was woken the thread was still marked as being suspended (s=1) by the debugger (d=1).

I've come across this on the emulator and on the phone itself. If the debugger is disconnected from the device (be it emulated or real), this error condition is reset. I have found no other way of escaping the problem.

Another SO answer claims this is due to debug breakpoints being out of sync - DexFile.class error in eclipse

You can try that too.

HTH

Answer 3

Me too come across the problem. Simply just because after I started a new Thread(), I tried to access the stuff in the thread that had already been suspended. Removed that code, and the problem is resolved.

HTH