The Context

I am debugging a unit test which acts as a "server" by spawning child processes which act as the "clients," and they communicate with the server on different ports. The server itself is a child of a "manager" process that just spawns it and waits for it to finish. I am able to attach debuggers to the server process and the first client process, and determine that they are both waiting for a message. The server is waiting for a message from the second client, and I am trying to find the location in the source code where the second client got stuck, presumably before it could send the message.

Other Details

The processes are all running the same unit test binary under the user shell.

The development environment is a MacOS running Android emulator with Android version 12, API version 32. I ran lldb-server --server --listen *:5039 on the emulator via adb shell. In a terminal window, I ran lldb in multiple terminal windows, where I entered platform select remote-android, and then platform connect connect://:5039. This was all successful. I was monitoring the processes and their ancestry with top -u shell -O PPID -s 1 -d 1 in another adb shell.

In one lldb instance per process, I entered process attach --pid [target pid]. This worked for two of the processes but not the third. I tried starting over with fresh lldb instances and tried to attach to the problem process before attaching to the others, but still got Operation not permitted. I have seen the many answers about ptrace protection online, but the common solutions involving kernel.yama.ptrace_scope don’t work here because that sysctl entry doesn’t exist on Android, and neither does the file under /proc. Android is based on SELinux, and I did find some clues such as ObjectClassesPerms and a RedHat tutorial about setting a permission policy, but I am having trouble understanding it enough to apply it to my situation. I also just ran getenforce and the result was Permissive, so I don’t think it’s policy related.

You need to sign in to view this answers