Android with jdb confusion using waitForDebugger

Question

I'd like to debug my Android application on my device (Nexus One - not the emulator) using the command line.

I'm confused at how to set a breakpoint using jdb in combination with android.os.Debug.waitForDebugger.

Say I put the following code in my main activity onCreate:

public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.main);

    android.os.Debug.waitForDebugger();
    int j = 10;
    int r = j;
}

Using ddms I can see that my application is waiting for the debugger (red bug icon) when I start it.

However, I don't understand how to set a breakpoint after the waitForDebugger() call so that I can start stepping.

Obviously just attaching jdb is going to immediately continue running the app without stopping.

e.g.

jdb -attach localhost:8700

Is there way to preset breakpoints prior to running jdb or a way to start jdb set breakpoints and then attach?

Answer 1

I've tried with both solutions (the one from fadden and the one from Richard Riley), but none of them worked. The app launched in the emulator get unblocked as soon as a jdb is attached to the debug port (8700 via Dalvik) but then it runs on its own, without synchronizing with jdb at all. Introducing a waiting loop does not change things, and breakpoint commands in .jdbrc have no effect. Invariably, the jdb answer is "Deferring breakpoint etc. etc. It will be set after the class is loaded.", as the app was not running; but, if you type "run" the answer is "Nothing suspended.", as the app was already running...

Answer 2

Unfortunately, there is no way for the VM to tell the debugger that it's already suspended. The various debuggers I've tried get confused if the initial state is anything other than "running". As a result, after the debugger connects, the VM has to resume all threads. (The only exception to the above is if the VM was just started, in which case it can send a special "I just started" message indicating whether it's going to come up running or stay suspended. This doesn't help here.)

What waitForDebugger() does do is wait until the initial burst of activity from the debugger quiets down. After the debugger connects, the method will sleep until there has been no activity from the debugger for 1.5 seconds. This allows the debugger a chance to set any breakpoints before the VM resumes.

For Eclipse, this hack works out pretty well, because you can configure your breakpoints before you attach. For jdb, there's no way I can see to tell it to attach after it has started up, so you have to be quick on the keyboard or use some sort of config file (which I also don't see).

You could solve this a different way: below the waitForDebugger call, add a loop like:

static volatile boolean staticField = false;
  ...
while (!MyClass.staticField) {
    Log.d(tag, "waiting for go");
    Thread.sleep(2000);
}

Then, after you've got jdb configured the way you want, use something like:

> set MyClass.staticField = true

If you're quick, you could skip the loop and just Thread.sleep(5000) to give yourself a little extra time to slam breakpoints in.

Answer 3

jdb has a config file : ~/.jdrbc in Linux. e.g in mine I have:

stop in net.richardriley.myproj.myact.onCreate

The in your device emulator dev settings you can set "wait for debugger" for the application class in question. Run the application, start the debugger and it will break.