Menu
When a process is attached by gdb, the stat of the process is "T", like:
root 6507 0.0 0.0 67896 952 ? Ss 12:01 0:00 /mytest
root 6508 0.0 0.0 156472 7120 ? Sl 12:01 0:00 /mytest
root 26994 0.0 0.0 67896 956 ? Ss 19:59 0:00 /mytest
root 26995 0.0 0.0 156460 7116 ? Tl 19:59 0:00 /mytest
root 27833 0.0 0.0 97972 24564 pts/2 S+ 20:00 0:00 gdb /mytest
From the above, 26995 may be debuging. How can I know 26995 is debug or not? Or can I know which process is attached by gdb(27833)
pstree -p 27833 --- show gdb(27833)
Another question: How to know a process(stat: T) is attached by which gdb(PID)? In most siduation, I am not the peoson who is debuging the process.
880
In order to attach to processes on Windows machine you need to run GDB as Administrator. You cannot attach two instances of GDB to the same process. You cannot attach GDB to a Windows process that is already being debugged by native Visual Studio debugger.
When you attach to processes with GDB, the following restrictions are applied: In order to attach to processes from different Linux terminals you need to be running as root. In order to attach to processes on Windows machine you need to run GDB as Administrator. You cannot attach two instances of GDB to the same process.
If you use the run command instead, the process will be restarted. When you attach to processes with GDB, the following restrictions are applied: In order to attach to processes from different Linux terminals you need to be running as root.
Instated of scrolling through the list of all process, you can use “ Processes ” dialog window to see the what are the current process attached. To navigate the “Processes” windows, from debug menu, Debug > Windows > Processes [ during debugging ]
The T in ps output stands for "being ptrace()d". So that process (26995) is being traced by something. That something is most often either GDB, or strace.
So yes, if you know that you are only running GDB and not strace, and if you see a single process in T state, then you know that you are debugging that process.
You could also ask GDB which process(es) it is debugging:
(gdb) info process
(gdb) info inferior
Update
As Matthew Slattery correctly noted, T just means the process is stopped, and not that it is being ptrace()d.
So a better solution is to do this:
grep '^TracerPid:' /proc/*/status | grep -v ':.0'
/proc/7657/status:TracerPid: 31069
From above output you can tell that process 7657 is being traced by process 31069. This answers both "which process is being debugger" and "which debugger is debugging what".
54
/proc file system is a telent design of Linux. Many process real-time information can be found from /proc/{PID}/.
Another question: How to know a process(stat: T) is attached by which gdb(PID)? In most siduation, I am not the peoson who is debuging the process.
For this question, we can check /proc/{PID}/status file to get the answer.
root 14616 0.0 0.0 36152 908 ? Ss Jun28 0:00 /mytest
root 14617 0.5 0.0 106192 7648 ? Sl Jun28 112:45 /mytest
tachyon 2683 0.0 0.0 36132 1008 ? Ss 11:22 0:00 /mytest
tachyon 4276 0.0 0.0 76152 20728 pts/42 S+ 11:22 0:00 gdb /mytest
tachyon 2684 0.0 0.0 106136 7140 ? Tl 11:22 0:00 /mytest
host1-8>cat /proc/2684/status
Name: mytest
State: T (tracing stop)
SleepAVG: 88%
Tgid: 2684
Pid: 2684
PPid: 2683
TracerPid: 4276
.......
Thus we know 2684 is debug by process 4276.
31
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With