Can strace debug an application being debugged by gdb?

user_562242 0
Viewed 1726

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?

strace gdb android debugging
1 Answers

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.

user_721780
Related