From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30773 invoked by alias); 23 Oct 2008 00:10:10 -0000 Received: (qmail 30765 invoked by uid 22791); 23 Oct 2008 00:10:09 -0000 X-Spam-Check-By: sourceware.org Received: from mail-gx0-f10.google.com (HELO mail-gx0-f10.google.com) (209.85.217.10) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 23 Oct 2008 00:09:34 +0000 Received: by gxk3 with SMTP id 3so9064431gxk.0 for ; Wed, 22 Oct 2008 17:09:32 -0700 (PDT) Received: by 10.90.93.8 with SMTP id q8mr9932442agb.38.1224720572072; Wed, 22 Oct 2008 17:09:32 -0700 (PDT) Received: by 10.90.89.3 with HTTP; Wed, 22 Oct 2008 17:09:32 -0700 (PDT) Message-ID: <4ced24c0810221709u17575bf3s73994724c456e956@mail.gmail.com> Date: Thu, 23 Oct 2008 00:10:00 -0000 From: "Lukasz Lempart" To: gdb@sourceware.org Subject: gdb and cloned process MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-10/txt/msg00097.txt.bz2 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//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