tags:

views:

32

answers:

3

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?

A: 

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.

fadden
Thanks for the info. This interesting also... I can use JSwat without adding any sleep code and it is also able to set breakpoints after the waitForDebugger call.The bottom line is I'm looking for an Android debug solution to go along with TextMate or Emacs on the Mac. I'm not a fan of Eclipse and I'm looking for something more "condensed" since I tend to be working almost exclusively on a macbook pro 13". I was hoping to just wire some simple jdb functionality into a TextMate bundle or Emacs helpers.
mmgcs
It's really just a question of timing. If you can have a script driving jdb, and get the breakpoint commands through fast enough, it'll work. I filed a feature request with the Eclipse people to make the debugger better deal with connecting to a suspended VM, but I don't expect that to happen any time soon (if at all). Since it wouldn't fix other debuggers with similar behavior I can't count on it in the VM anyway.
fadden
argh... fadden, I appreciate the help!I guess I'll just create, manage, and debug Android projects in Eclipse and write the code with an external editor.Classic story... conform or feel the pain hitting your head against a wall that everyone claims is not there. Moving on...Peace
mmgcs
A: 

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.

Richard Riley
this truly doesn't seem to work at all. However, stop at <class>:<lineno> does work
codeboy2k
A: 

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...

Giuseppe Ciaccio
I too couldn't get stop in <class> to work, however stop at <class>:<lineno> works in the .jdbrc file. I've verified it. See the answer to your linked question.
codeboy2k