This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
GDB fork problems
- From: Uri Moszkowicz <uri at 4refs dot com>
- To: gdb at sourceware dot org
- Date: Wed, 19 Apr 2017 13:45:18 -0500
- Subject: GDB fork problems
- Authentication-results: sourceware.org; auth=none
Hi,
An application I'm debugging is written in C++ and forks at various
times. Normally it's not a problem but I have no visibility to debug
the child processes. I've tried a few approaches to debug them without
success and need help.
First, I tried attaching to the child processes from another terminal.
The default behavior of GDB is to detach on fork so I expected that
this wouldn't be a problem. However, when I tried to attach to the
child process using it's PID, GDB complained that the process is
already being traced (by GDB instance of the parent process). In that
GDB session, "info inferriors" shows only one process, the parent
process. Why does it appear to the kernel that the parent GDB session
is tracing the child process then?
Second, I tried GDB's fork features. I tried "follow-on-fork-mode" and
"detach-on-fork" and both result in the same behavior, a hang at the
time of the fork() calls. After the fork I can see two inferiors but
continuing the child inferior doesn't result in progress. If I detach
the child process, then the parent process continues to completion.
The last line I see is "[New process #]". When I switch to the child
inferior I see that it's stopped at the fork() call. Why isn't the
child process hanging at this line?
My GDB versions is 7.12.1 and I'm running the executable on CentOS 6.
Thanks,
Uri