The debugger support in the VM will wait a second or two for the
debugger to settle before continuing if you use
android.os.Debug.waitForDebugger(). That's not enough to enter
breakpoints by hand, but if you use a more sophisticated program like
Eclipse it gives the debugger enough time to
On Jul 7, 10:50 am, Stephen Kell sr...@srcf.ucam.org wrote:
#0 0x00ad97fb in dvmChangeStatus (self=0xf0d057d8,
newStatus=THREAD_RUNNING)
at dalvik/vm/Thread.c:3160
#1 0x00ab0bb5 in dvmDbgThreadContinuing (status=1) at dalvik/vm/
Debugger.c:502
#2 0x00afb823 in dvmJdwpPostThreadChange
You may be able to just remove the assertion for your purposes.
For some reason a thread in the running state is trying to change to
running, i.e. it's a do-nothing operation that just wastes time. It
also represents a potential problem in that a bit of code that was
assuming it was in some
On Jul 5, 4:53 am, Stephen Kell sr...@srcf.ucam.org wrote:
If I break the dalvikvm in gdb before it does
Check_CallStaticVoidMethodV,
then attach jdb and resume both, I get the following.
E/dalvikvm(26824): ASSERT FAILED (dalvik/vm/Thread.c:3160): oldStatus !
= THREAD_RUNNING
You may be
