> 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 set breakpoints before > resuming.
Ah, cool -- sounds useful. That was the reminder I needed to move to the Eclipse front-end anyhow, and has helped -- thanks! > That does look peculiar. I would guess the JNIEnv is bogus, and > you're looking at a bunch of memory that isn't actually holding a JNI > function table. Indeed, silly me -- the stack seems to be corrupt. I have now sidestepped this whole problem by commenting out the jar verification process (the initial exceptions were complaining about failing to find public keys, before being turned into other exceptions with a less helpful message -- I guess I need to install Android public keys locally for the Jars to verify? not sure why they're not in the distribution, but no matter). The fun's not over yet -- getting even stranger segfaults (without non-stop gdb) in some native calls originating in SystemServer (calling sqlite stuff). I might post back about those once I've investigated. -- unsubscribe: android-porting+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-porting
