gdb and cloned process

Lukasz Lempart llempart@gmail.com
Thu Oct 23 00:10:00 GMT 2008


I am using gdb 6.8 and running linux 2.6.9 on a 64bit AMD Opteron.

I am working with a multi-threaded application (using glibc's pthread
implementation). One of the threads, clones another process using the
following flags:

CLONE_VM | CLONE_UNTRACED | CLONE_DETACHED | CLONE_PARENT | CLONE_FILES

The cloned process also calls setsid creating its own process group.
The idea here is to peek at the memory of the original application
without stopping it, by attaching gdb to the cloned process.

However, when I attach for the first time, the cloned process as well
as the original and all of its threads are stopped under ptrace.
Detaching, and then reattaching results in the correct behavior of
only the cloned process being stopped under ptrace. The "info threads"
command, once again places the original process and all its threads
under ptrace. stracing gdb I can see an explicit ptrace attach with
the pid of the original process.

Attaching to the original process never causes the cloned process to
be put under ptrace even when "info threads" command is issued.
However, "info threads" causes duplicates of all threads to be
displayed.

Everything seems fine w.r.t. to the system. Varieties of top show the
two running as separate processes. /proc/<pid>/status shows the
correct number of threads (1 for the cloned, multiple for the
original). The process group ids and thread group ids are different.

My questions are as follows:
How does gdb (through libthread_db) figure out what threads belong to a process?
Does anyone have any idea what is causing this behavior?
Is there currently a way to disable thread debugging in gdb?

Thank you for any help you can afford.

Lukasz



More information about the Gdb mailing list