Having difficulties running GDB with Eclipse CDT on Mac OS X Mojave.
When I try to debug the project, GDB behaves chaotic: I am able to debug a few times, but then it starts stalling at the begining of the next debug session with the message "Configuring GDB".
Executable is /Users/jd/Work/myapp.
When I list the processes ps -al I see there are hanging processes:
/Users/jd/Library/Caches/gdb/bin/bash -c exec /Users/jd/Work/myapp
/Users/jd/Library/Caches/gdb/bin/bash -c exec /Users/jd/Work/myapp
/Users/jd/Library/Caches/gdb/bin/bash -c exec /Users/jd/Work/myapp
/Users/jd/Work/myapp
/Users/jd/Library/Caches/gdb/bin/bash -c exec /Users/jd/Work/myapp
/Users/jd/Library/Caches/gdb/bin/bash -c exec /Users/jd/Work/myapp
/Users/jd/Work/myapp
/usr/local/bin/gdb --interpreter mi2 --nx
/usr/local/bin/gdb --interpreter mi2 --nx
/usr/local/bin/gdb --interpreter mi2 --nx
/usr/local/bin/gdb --interpreter mi2 --nx
What could be the problem? Is it GDB or Bash?
Edit
The hanging myapp processes have a TXs+ state, which, according to man pspage means:
T, marks a stopped process
X, the process is being traced or debugged
s, the process is a session leader
"+", the process is in the foreground process group of its control terminal
The hanging ggdbprocesses have a state:
S, process that is sleeping for less than about 20 seconds (never turns to I, which means it sleeps more than 20 seconds, idle.)
From the details in the question and from my past experience of a similar issue this is all I have for you,
After starting GDB, I saw a message, "launching gdb aborting configuring gdb." My environment was Mac with Eclipse + gdb (ggdb downloaded from macports).
Temporary solution that worked for me was to start eclipse as root.
To fix the issue permanenty,
Use the below link to see how to create a certificate or cross check if already configured,
Mac C++/Mars eclipse gdb debug hangs at Launching Test 96%
If my response above and link were not helpful then try the below eclipse forum to check and compare your problems to others posted and see if you can identify and curate the question further with more relevant info.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=509737
I'm currently making a command line app in C in which many child process is created. So I need to debug this children code. I have created a child process on Xcode as follow. (see the break point and running cursor.)
After executing some statements, I get xcode to attach GBN(885) to the xcode debugger as shown in below figure.
It doesn't work. How can I attach the child process to xcode debugger? Thank you in advance.
Google and Apple developer page are really silent on this issue and finally I've found a good workaround. This error message appears when we get Xcode debugger to attach to the process that is a child process of process being debugged or that is a process already being debugged by Xcode debugger, gdb, or lldb.
In order to avoid this irritating message, First put kill(0, SIGSTOP) statement where you want to stop the child process. In the following figure, I have put the kill statement right after the child is created.
Second, use gcc to compile your source codes with -g option.
$ ls
GBN.1 gbn.c gbn.h type.h util.c util.h
$ gcc *.c -g
$ ./a.out
[1]+ Stopped ./a.out
$ ps -ef | grep a.out
501 628 600 0 9:33AM ttys000 0:00.00 ./a.out
501 629 628 0 9:33AM ttys000 0:00.00 ./a.out
Now, all we have to do is to tell Xcode debugger to attach to the process by pid. Click the Debug menu and then find the Attach to process option to click By Process Identifier (PID) or name option. Then type the pid for child process (or parent process) and click attach button.
Enjoy Debugging!
I'm trying to attach a program with gdb but it returns:
Attaching to process 29139
Could not attach to process. If your uid matches the uid of the target
process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try
again as the root user. For more details, see /etc/sysctl.d/10-ptrace.conf
ptrace: Operation not permitted.
gdb-debugger returns "Failed to attach to process, please check privileges and try again."
strace returns "attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted"
I changed "kernel.yama.ptrace_scope" 1 to 0 and /proc/sys/kernel/yama/ptrace_scope 1 to 0 and tried set environment LD_PRELOAD=./ptrace.so with this:
#include <stdio.h>
int ptrace(int i, int j, int k, int l) {
printf(" ptrace(%i, %i, %i, %i), returning -1\n", i, j, k, l);
return 0;
}
But it still returns the same error. How can I attach it to debuggers?
If you are using Docker, you will probably need these options:
docker run --cap-add=SYS_PTRACE --security-opt seccomp=unconfined
If you are using Podman, you will probably need its --cap-add option too:
podman run --cap-add=SYS_PTRACE
This is due to kernel hardening in Linux; you can disable this behavior by echo 0 > /proc/sys/kernel/yama/ptrace_scope or by modifying it in /etc/sysctl.d/10-ptrace.conf
See also this article about it in Fedora 22 (with links to the documentation) and this comment thread about Ubuntu and .
I would like to add that I needed --security-opt apparmor=unconfined along with the options that #wisbucky mentioned. This was on Ubuntu 18.04 (both Docker client and host). Therefore, the full invocation for enabling gdb debugging within a container is:
docker run --cap-add=SYS_PTRACE --security-opt seccomp=unconfined --security-opt apparmor=unconfined
Just want to emphasize a related answer. Let's say that you're root and you've done:
strace -p 700
and get:
strace: attach: ptrace(PTRACE_SEIZE, 700): Operation not permitted
Check:
grep TracerPid /proc/700/status
If you see something like TracerPid: 12, i.e. not 0, that's the PID of the program that is already using the ptrace system call. Both gdb and strace use it, and there can only be one active at a time.
Not really addressing the above use-case but I had this problem:
Problem: It happened that I started my program with sudo, so when launching gdb it was giving me ptrace: Operation not permitted.
Solution: sudo gdb ...
As most of us land here for Docker issues I'll add the Kubernetes answer as it might come in handy for someone...
You must add the SYS_PTRACE capability in your pod's security context
at spec.containers.securityContext:
securityContext:
capabilities:
add: [ "SYS_PTRACE" ]
There are 2 securityContext keys at 2 different places. If it tells you that the key is not recognized than you missplaced it. Try the other one.
You probably need to have a root user too as default. So in the other security context (spec.securityContext) add :
securityContext:
runAsUser: 0
runAsGroup: 0
fsGroup: 101
FYI : 0 is root. But the fsGroup value is unknown to me. For what I'm doing I don't care but you might.
Now you can do :
strace -s 100000 -e write=1 -e trace=write -p 16
You won't get the permission denied anymore !
BEWARE : This is the Pandora box. Having this in production it NOT recommended.
I was running my code with higher privileges to deal with Ethernet Raw Sockets by setting set capability command in Debian Distribution. I tried the above solution: echo 0 > /proc/sys/kernel/yama/ptrace_scope
or by modifying it in /etc/sysctl.d/10-ptrace.conf but that did not work for me.
Additionally, I also tried with set capabilities command for gdb in installed directory (usr/bin/gdb) and it works: /sbin/setcap CAP_SYS_PTRACE=+eip /usr/bin/gdb.
Be sure to run this command with root privileges.
Jesup's answer is correct; it is due to Linux kernel hardening. In my case, I am using Docker Community for Mac, and in order to do change the flag I must enter the LinuxKit shell using justin cormack's nsenter (ref: https://www.bretfisher.com/docker-for-mac-commands-for-getting-into-local-docker-vm/ ).
docker run -it --rm --privileged --pid=host justincormack/nsenter1
/ # cat /etc/issue
Welcome to LinuxKit
## .
## ## ## ==
## ## ## ## ## ===
/"""""""""""""""""\___/ ===
{ / ===-
\______ O __/
\ \ __/
\____\_______/
/ # cat /proc/sys/kernel/yama/ptrace_scope
1
/ # echo 0 > /proc/sys/kernel/yama/ptrace_scope
/ # exit
Maybe someone has attached this process with gdb.
ps -ef | grep gdb
can't gdb attach the same process twice.
I was going to answer this old question as it is unaccepted and any other answers are not got the point. The real answer may be already written in /etc/sysctl.d/10-ptrace.conf as it is my case under Ubuntu. This file says:
For applications launching crash handlers that need PTRACE, exceptions can
be registered by the debugee by declaring in the segfault handler
specifically which process will be using PTRACE on the debugee:
prctl(PR_SET_PTRACER, debugger_pid, 0, 0, 0);
So just do the same thing as above: keep /proc/sys/kernel/yama/ptrace_scope as 1 and add prctl(PR_SET_PTRACER, debugger_pid, 0, 0, 0); in the debugee. Then the debugee will allow debugger to debug it. This works without sudo and without reboot.
Usually, debugee also need to call waitpid to avoid exit after crash so debugger can find the pid of debugee.
If permissions are a problem, you probably will want to use gdbserver. (I almost always use gdbserver when I gdb, docker or no, for numerous reasons.) You will need gdbserver (Deb) or gdb-gdbserver (RH) installed in the docker image. Run the program in docker with
$ sudo gdbserver :34567 myprogram arguments
(pick a port number, 1025-65535). Then, in gdb on the host, say
(gdb) target remote 172.17.0.4:34567
where 172.17.0.4 is the IP address of the docker image as reported by /sbin/ip addr list run in the docker image. This will attach at a point before main runs. You can tb main and c to stop at main, or wherever you like. Run gdb under cgdb, emacs, vim, or even in some IDE, or plain. You can run gdb in your source or build tree, so it knows where everything is. (If it can't find your sources, use the dir command.) This is usually much better than running it in the docker image.
gdbserver relies on ptrace, so you will also need to do the other things suggested above. --privileged --pid=host sufficed for me.
If you deploy to other OSes or embedded targets, you can run gdbserver or a gdb stub there, and run gdb the same way, connecting across a real network or even via a serial port (/dev/ttyS0).
I don't know what you are doing with LD_PRELOAD or your ptrace function.
Why don't you try attaching gdb to a very simple program? Make a program that simply repeatedly prints Hello or something and use gdb --pid [hello program PID] to attach to it.
If that does not work then you really do have a problem.
Another issue is the user ID. Is the program that you are tracing setting itself to another UID? If it is then you cannot ptrace it unless you are using the same user ID or are root.
I have faced the same problem and try a lot of solution but finally, I have found the solution, but really I don't know what the problem was. First I modified the ptrace_conf value and login into Ubuntu as a root but the problem still appears. But the most strange thing that happened is the gdb showed me a message that says:
Could not attach to process. If your uid matches the uid of the target process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try again as the root user.
For more details, see /etc/sysctl.d/10-ptrace.conf
warning: process 3767 is already traced by process 3755 ptrace: Operation not permitted.
With ps command terminal, the process 3755 was not listed.
I found the process 3755 in /proc/$pid but I don't understand what was it!!
Finally, I deleted the target file (foo.c) that I try to attach it vid gdb and tracer c program using PTRACE_ATTACH syscall, and in the other folder, I created another c program and compiled it.
the problem is solved and I was enabled to attach to another process either by gdb or ptrace_attach syscall.
(gdb) attach 4416
Attaching to process 4416
and I send a lot of signals to process 4416. I tested it with both gdb and ptrace, both of them run correctly.
really I don't know the problem what was, but I think it is not a bug in Ubuntu as a lot of sites have referred to it, such https://askubuntu.com/questions/143561/why-wont-strace-gdb-attach-to-a-process-even-though-im-root
Extra information
If you wanna make changes in the interfaces such as add the ovs bridge, you must use --privileged instead of --cap-add NET_ADMIN.
sudo docker run -itd --name=testliz --privileged --cap-add=SYS_PTRACE --security-opt seccomp=unconfined ubuntu
If you are using FreeBSD, edit /etc/sysctl.conf, change the line
security.bsd.unprivileged_proc_debug=0
to
security.bsd.unprivileged_proc_debug=1
Then reboot.
In my project I added a new module and now my process is being terminated by signal 11 .
I want to track and understand the problem but no coredump file is generated by freebsd.
I set sysctl like :
sysctl -a | grep core
kern.corefile: /usr/core
kern.nodump_coredump: 1
kern.coredump: 1
kern.sugid_coredump: 1
debug.elf64_legacy_coredump: 1
debug.elf32_legacy_coredump: 1
I also set ulimit -c unlimited
From my code I removed all code about signal like "sigaction(SIGTERM, &signal, &signal_old);"
for not preventing kernel to generate coredump.
Why I can't see any coredump still ? What I am missing ?
Also are there any method forcing a program which run on freebsd to create coredump an equivalent to do_coredump() in linux?
The problem is in:
kern.corefile: /usr/core
Something like the following should help:
sysctl -w kern.corefile = "%N.core"
If I recall correctly, kern.corefile is the complete name of the resulting corefile, not the directory in which it should be placed. It also needs to be writable by the user running the process. /usr/core looks like a directory and/or a location writable only by root.
kern.nodump_coredump: 1 also looks suspicious.I don't remember that sysctl existing in the last version of FreeBSD I used, but it looks like it's intended to disable core dumps. Try setting it to 0.
Suppose I have a generic binary without source and I want to determine whether it is running serially or spawns multiple threads.
Is there a way I can do this from the linux command line?
First install strace.
$ yum install strace
Run the program with strace, and look for clone or fork system calls. Here's a quick example with a program I wrote that just calls fork and returns.
$ strace ./a.out
execve("./a.out", ["./a.out"], [/* 43 vars */]) = 0
brk(0) = 0x74f000
...
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7fb22b16da10) = 6567
exit_group(1) = ?
+++ exited with 1 +++
You can use ps for that. From man ps:
-L Show threads, possibly with LWP and NLWP columns.
So you can do:
$ ps -L <pid>
and it will show you something like this:
PID LWP TTY STAT TIME COMMAND
4112 4112 ? Sl 65:35 /usr/lib/firefox/firefox
4112 4116 ? Sl 0:04 /usr/lib/firefox/firefox
Each line of the output corresponds to one thread. This of course, only works for a certain
moment in time. To track the spawning of threads, use strace, as suggested by Jonathon Reinhart.
An alternative to strace is, of course, gdb. See this question for details on managing threads in gdb. You may also read the thread section of the gdb manual. Quick introduction:
$ gdb /usr/lib/firefox/firefox <pid>
[... initialization output ...]
> info threads # lists threads
> thread <nr> # switch to thread <nr>
Your comment:
How can I figure out where to set an instruction-level breakpoint if the program only takes seconds to run?
This answer might help you here, as it shows how to break on thread creation (with pthread_create) using gdb. So every time a thread is created, execution stops and you might investigate.
Just run: cat /proc/<pid>/stat | awk '{print $20}' to get the number of threads of a running process.
proc manpage