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

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.