I'm studying Android system startup and am very interested in the zygote process. Is there anyway to debug zygote with gdb or other tools? I've tried to do it with virtual machine like VMware or qemu but failed, all google results are about kernel debugging. By debug I mean I could set breakpoint, step into, check register value, etc... with gdb just like the normal process debugging with gdb.
I post this question and after several tries. I found one way to debug daemon processes as long as it started after adbd:
Stop zygote
Gdbserver attach init process
Restart zygote
Debug its child process
Related
Background
I'm debugging an Android application using gdb 8.3 under WSL (Windows Subsystem for Linux). When debugging my app gdb frequently catches SIGSEGV and other signals that terminate the application, in general at inconsistent points in the session. These signals do not occur when the app is run without gdb. I have good reason to believe that gdb is the source of the instabilities.
I therefore want to monitor the running gdb-app using strace, in the hope of exercising the app and seeing what system function generates the offending signal when it crashes.
The Problem
strace is unable to attach to the gdb-debugged Android application because it cannot attach to an already attached process.
Here is the gdbserver command to attach to the running process:
dreamlte:/data/local/tmp # ./gdbserver :9999 --attach 26060
Attached; pid = 26060
Listening on port 9999
Remote debugging from host 127.0.0.1
I start gdb, which attaches to the running application.
With gdb attached to the Android application, I attempt to attach strace to the application:
127|dreamlte:/data/local/tmp # ./strace -p 26060
attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted
I understand the problem is that the application process cannot be attached to more than once.
Is there a way to attach strace to a running gdb-app combination?
I understand the problem is that the application process cannot be
attached to more than once.
Yes, this is the limitation of ptrace() system call, see ERRORS section in man ptrace:
EPERM The specified process cannot be traced. This could be because
the tracer has insufficient privileges (the required
capability is CAP_SYS_PTRACE); unprivileged processes cannot
trace processes that they cannot send signals to or those
running set-user-ID/set-group-ID programs, for obvious
reasons. Alternatively, the process may already be being
traced, or (on kernels before 2.6.26) be init(1) (PID 1).
I therefore want to monitor the running gdb-app using strace, in the
hope of exercising the app and seeing what system function generates
the offending signal when it crashes.
Instead, you can see backtrace when the app crashes. You will probably see some system function generating signal or something else you do not expect.
When I debug my instant app on Android Studio, the debugger attaches to instant app process and pauses execution at most breakpoints. However it seems to ignore breakpoints at my main activity's onCreate method. I've tried "Debug" and "Attach Debugger to Android Process" options. What am I missing?
Basic information about how to use Android Studio debugger to debug an Android app is available at Developer Documentation Debug Your App
.
Android Studio debugger works normally most of the time when debugging an instant app. However, you will notice that the debugger will fail to stop at breakpoints early in the app's lifecycle (such as Application.onCreate or Activity.onCreate) on devices running Android N and below.
When your instant app is up and running, it runs under your app's package name. However, there is a short period of time during app startup when it runs under a temporary package name, in the following form:
com.google.android.instantapps.supervisor.isolated[0-9]+
This temporary name is assigned by the runtime. Because Android Studio is not aware of this name, the debugger will not attach to this process.
The workaround is to find out this temporary name and use adb to set the app to debug. This can be done by running the following command in terminal before running your app. It will print out the name when your app starts.
=> adb shell 'while true; do ps | grep com.google.android.instantapps.supervisor.isolated; sleep 1; done'
u0_i6 31908 630 1121664 29888 0 00ea57eed4 R com.google.android.instantapps.supervisor.isolated15
Once you identify the package name, use the following command which will pause and make your instant app process to wait for the debugger. Then attach the debugger normally, but choosing the temporary process name in the Choose Process window by clicking on “Show all processes”.
=> adb shell am set-debug-app -w --persistent com.google.android.instantapps.supervisor.isolated15
I had also problems recently debugging instant apps.
with multiple log messages
"Waiting for application to start debug server"
in the debug window and after several retrials
"Could not connect to remote process. Aborting debug session."
The way I solved the issue is
by using the "Attach To Process" option from Android studio "Run" menu.
How can I run emulator without GUI (headless Android)?
My requirement is to run the headless Android on the emulator. Is it correct if I use ro.config.headless 1? Or disable zygote?
As of 29.2.11, you need to use the -no-window option instead of the emulator-headless binary:
The binary emulator-headless is now retired. Headless builds of the engine are now launched via emulator -no-window, thus unifying the previously separate (but similar) paths.
https://androidstudio.googleblog.com/2019/12/emulator-29211-and-amd-hypervisor-12-to.html
Android Emulator 28.1.8 now supports running the emulator in headless mode (emulator-headless): https://androidstudio.googleblog.com/2019/02/emulator-2818-canary.html
One of the options to achieve that is to stop zygote service when an emulator running. When stopping the zygote process (aka app_process) all of the system services, that were forked from zygote at system boot, shuts down. Only a few native system services will be running. The emulator's display should show the startup logo (or animation).
The steps for stopping zygote are as follows:
adb shell
su (most of emulator images have /system/xbin/su)
stop zygote
After that you can explore how less services are running with service list. Critical for Android Runtime services will be stopped, e.g.
activity: [] // ActivityManager
package: [] // PackageManager
display: [] // DisplayManager
...
To start zygote execute:
start zygote
Note: with the #CommonsWare's solution you are still going to have zygote and most of the Android system services running.
I was facing an issue with the emulator not running after building AOSP on my ssh server ubuntu 18.4.
emulator: WARNING: system partition size adjusted to match image file
(2562 MB > 800 MB) QXcbConnection: Could not connect to display
Aborted (core dumped)
I used emulator -no-window and I found the emulator process started.
now I can use ADB to verify AOSP changes
I have built ICS and want to get it running on my hardware with version 3.3 of the Linux Kernel.
When the board boots up Android starts the init process but all processes get killed, with messages similar to:
[ 7.600000] init: waitpid returned pid 2228, status = 0000000b
[ 7.600000] init: process 'vold', pid 2228 exited
[ 7.600000] init: process 'vold' killing any children in process group
Finally the board gives up with the message:
[ 28.090000] init: critical process 'servicemanager' exited 4 times in 4 minutes; rebooting into recovery mode
I have tried putting logcat into my init.rc but it never appears to reach or successfully load logcat, so I can't get more detailed log information out of the device.
In my kernel config I have set ANDROID_BINDER_IPC, ASHMEM, ANDROID_LOGGER, ANDROID_TIMES_OUTPUT, ANDROID_LOW_MEMORY_KILLER and ANDROID_SWITCH. IS there something else I have missed. I was hoping after reading http://kernelnewbies.org/Linux_3.3#head-b733d694037e0b34ad47e1b5d38ebc4d1bd1d89f that with Kernel 3.3 it would be easier to get Android up and running.
Has anyone seen this issue before or can anyone help me get more log data?
Many thanks in advance,
Markus
adbd is the daemon process running on the device. After a long time running, I found adbd may
receive a sigsegv signal, but this will not be logged in logcat. I have try to make the static libs shared libs, but that does not help.
Is there anyway to debug adbd?
I have found out that.
Jut copy what debugger.c does to adbd, after receive the signal, just make a socket connect to the debuggerd, and tell it your pid, and it will track you error stack. Then in the logcat,
you can find the error.
But I am really intersted how the orignal developers debug adbd ?