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?
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):
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
Note the "s=Y" flag disappeared in gingerbread -- the way thread suspension works was changed.