Diego Frehner Diego Frehner - 1 year ago 78
Android Question

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

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 Source

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.

Recommended from our users: Dynamic Network Monitoring from WhatsUp Gold from IPSwitch. Free Download