starting (dalvik) applications with gdb

[Pawel]

Hi,

Is there a way to start a (dalvik?) application with the gdb server?
I have an application that was packaged and installed, and now it is
failing during startup with some signal during native libraries
loading. I can't figure out exactly what process do I need to start
under gdb, so I can have the debugger so early in the loading process.
Any hints? I guess the alternative question is -- how to start an
application from command line (adb shell) ? :)

Thanks,
Pawel.

[fadden]

You can't start an Android app process directly from the shell. The
closest you can come is to use the "am" command to inspire the
framework to start one.

A low-tech solution to your problem:

Log.i("xxx", "start your debugger now!!");
Thread.sleep(10 * 1000);
System.loadLibrary("mystuff");

[Pawel Veselov]

On Thu, Jul 16, 2009 at 5:19 AM, fadden <fad...@android.com> wrote:
>
> On Jul 14, 10:58 pm, Pawel <pawel.vese...@gmail.com> wrote:
> > Is there a way to start a (dalvik?) application with the gdb server?
> > I have an application that was packaged and installed, and now it is
> > failing during startup with some signal during native libraries
> > loading. I can't figure out exactly what process do I need to start
> > under gdb, so I can have the debugger so early in the loading process.
> > Any hints? I guess the alternative question is -- how to start an
> > application from command line (adb shell) ? :)
>
> You can't start an Android app process directly from the shell.  The
> closest you can come is to use the "am" command to inspire the
> framework to start one.

I guess I need to check the zygote source code to see exactly
how it forks the app_process. Realistically, there shouldn't be anything
impossible to start it from the shell, unless zygote keeps open sockets
to the child after forking...

> A low-tech solution to your problem:
>
>  Log.i("xxx", "start your debugger now!!");
>  Thread.sleep(10 * 1000);
>  System.loadLibrary("mystuff");

After knocking my head on the keyboard some, I came up with
running the application with 'am' with '-D' flag, then attaching
the gdb, then attaching IDEA debugger to let the app continue.
At least this eliminates the need to set this funky debugger variable
to prevent that garbage collection problem I've read so much
about :)

Thanks,
Pawel.

P.S. Seeing IDEA properly debugging dalvik app is surreal :)

[Doug Schaefer]

Cool. Something I need to get working with Eclipse CDT too ;).

 

Cheers,

CDT Doug.

[fadden]

On Jul 15, 7:27 pm, Pawel Veselov <pawel.vese...@gmail.com> wrote:
> I guess I need to check the zygote source code to see exactly
> how it forks the app_process. Realistically, there shouldn't be anything
> impossible to start it from the shell, unless zygote keeps open sockets
> to the child after forking...

I think it's using the binder driver for communication, so it
shouldn't be clinging to pipes. In particular, the zygote parent has
no particular status except as a fork() server, so there's no need for
the two to talk.

There may well be a way to launch directly from the command line, but
I wouldn't be surprised if some bit-rot has occurred. Part of the
issue is that an app process is generic until the system server tells
it what to be. You don't launch the calculator; you zygote-spawn a
new process and then tell it to become a calculator. This is why a
newly-launched app will sometimes show up as "?" in DDMS for half a
second.

> After knocking my head on the keyboard some, I came up with
> running the application with 'am' with '-D' flag, then attaching
> the gdb, then attaching IDEA debugger to let the app continue.
> At least this eliminates the need to set this funky debugger variable
> to prevent that garbage collection problem I've read so much
> about :)

This is where "jdb" really shines, since all you really need to do is
connect and then quit. :-) "jdb -attach localhost:8700" on the
machine running DDMS.

You can also use android.os.Debug.waitForDebugger().

[mrzerg]

On 2009年7月17日, 上午4时27分, fadden <fad...@android.com> wrote:
> On Jul 15, 7:27 pm, Pawel Veselov <pawel.vese...@gmail.com> wrote:
>
> > I guess I need to check the zygote source code to see exactly
> > how it forks the app_process. Realistically, there shouldn't be anything
> > impossible to start it from the shell, unless zygote keeps open sockets
> > to the child after forking...
>
> I think it's using the binder driver for communication, so it
> shouldn't be clinging to pipes. In particular, the zygote parent has
> no particular status except as a fork() server, so there's no need for
> the two to talk.
>
> There may well be a way to launch directly from the command line, but
> I wouldn't be surprised if some bit-rot has occurred. Part of the
> issue is that an app process is generic until the system server tells
> it what to be. You don't launch the calculator; you zygote-spawn a
> new process and then tell it to become a calculator. This is why a
> newly-launched app will sometimes show up as "?" in DDMS for half a
> second.
>
> > After knocking my head on the keyboard some, I came up with
> > running the application with 'am' with '-D' flag, then attaching

> > thegdb, then attaching IDEA debugger to let the app continue.

> > At least this eliminates the need to set this funky debugger variable
> > to prevent that garbage collection problem I've read so much
> > about :)
>
> This is where "jdb" really shines, since all you really need to do is

> connect and then quit. :-) "jdb-attach localhost:8700" on the

> machine running DDMS.
>
> You can also use android.os.Debug.waitForDebugger().

I found that jdb and gdb seems can't work together, (under my ndk-r5b,
on both 2.2 and 2.3 device)
I use jdb to make the programe stop in onCreate() in java, and then
fire ndk-gdb. but after I continue both jdb and gdb, the programe exit
with the following info in gdb:

(gdb) c
Continuing.

Child terminated with signal = 5

grogram terminated with si
Child terminated with signal = 0x5 (SIGTRAP)
GDBserver exiting
nal SIGTRAP, Trace/breakpoint trap.
The program no longer exists.
(gdb)

and there is no abnormal log in logcat.
It's sad that I still have to change my code to debug app startup :(