From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 21 23:35:14 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2ECF51065673 for ; Wed, 21 Mar 2012 23:35:14 +0000 (UTC) (envelope-from sushanth_rai@yahoo.com) Received: from nm3.bullet.mail.sp2.yahoo.com (nm3.bullet.mail.sp2.yahoo.com [98.139.91.73]) by mx1.freebsd.org (Postfix) with SMTP id 064C78FC15 for ; Wed, 21 Mar 2012 23:35:13 +0000 (UTC) Received: from [98.139.91.65] by nm3.bullet.mail.sp2.yahoo.com with NNFMP; 21 Mar 2012 23:35:13 -0000 Received: from [98.139.44.68] by tm5.bullet.mail.sp2.yahoo.com with NNFMP; 21 Mar 2012 23:35:13 -0000 Received: from [127.0.0.1] by omp1005.access.mail.sp2.yahoo.com with NNFMP; 21 Mar 2012 23:35:13 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 546240.61140.bm@omp1005.access.mail.sp2.yahoo.com Received: (qmail 39969 invoked by uid 60001); 21 Mar 2012 23:35:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1332372913; bh=9NpSRjHEJlUjR8pnDPQfOgHolbaPfp3ejbk98miTrls=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=U0/FHIY83Z5HKbNuAXJp3MaYmKm12ju8k5gcz+3dWMM6HHpYGEB4DfU1crZm6mpmvSXFEWd7ECu+RoUQ8SI5WQTXKGC2nP1a9RbWyjufle0zvfpmUkfoX+rsOa4WVEcdWTtuuuYSND2EDQsIezpEyMHkIF2FOtHoR1zrYaa9kF8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=E9fGrx9CxAcdlhYt5iqMkHZ3fjQw8NLak5z/45OcN4pRVddtqXRCGzHiclcfjdgVsK4UrwDCZLXnBguJmets+ibjDf2EtNJ7D80ojgkYyDM9xeTCjK1GVQ8qTr0oPeG/9Ud8uv4C2sYq2WWdPdLP5WDBaVWZo6xZEF4bmPIyT/U=; X-YMail-OSG: M9z4j10VM1kOh73fHBL.k5XWkr6YUA01ERrxBX4z6nwR93H iL1qhLPOz_GJjspZFxllfVUDx.k8dSbqOj6VG5cR2oOHHhVMQN01XmBIfUda nvH7zj8okXpJzXXvn_ifnmjOFQqWw4.Ni3apuGYEy8f0VjqSuF9oVvUWAnc1 fVmRGFRqiUnYHvDbRomg_yNkY.tUlwMKLC.35LGiH3tkH1aAXGC88MwcmsSM B5RYTWr0S0udPoosvHvpaTRvMCUakUWF40rGnJpVm5r9JSJAqQQfHeJEKB2A _0Mer8Rppe04VTkYrjX4vIv4ZZ5w8JLL.tBwVs3PXI9m8WK3JiVNjP_.5Npu m19IpLHg3J89UH_vxh114X87BSy9q9.l9gbgpyb34zQJGFWySdFEjwNu7.3L o_QVbjw_cdI7NIIGOiFSJ6aHXXYDNQ8SGobAtEuYhCkpZMGb0HkyXw6W2z17 vuUcEh6E- Received: from [209.119.38.67] by web180013.mail.gq1.yahoo.com via HTTP; Wed, 21 Mar 2012 16:35:13 PDT X-Mailer: YahooMailClassic/15.0.5 YahooMailWebService/0.8.116.338427 Message-ID: <1332372913.7195.YahooMailClassic@web180013.mail.gq1.yahoo.com> Date: Wed, 21 Mar 2012 16:35:13 -0700 (PDT) From: Sushanth Rai To: freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Improving gcore X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 23:35:14 -0000 Sometimes I have trouble capturing the "correct" state of a multithreaded process using gcore. That is, it looks like target process might have done some work since the time command was issued and the core file was generated. Looking at the code, gcore calls ptrace(PT_ATTACH...), which internally issues SIGSTOP, and calls waitpid() to wait until the process stops. So, it's quite possible that some threads that are not sleeping interruptibly will continue to run until the process notices the signal. Signals are only checked when a thread that is tagged to handle the signal crosses the user boundary (return from syscall, trap). When the thread finally handles SIGSTOP, it needs to stop all threads, which is done by lighting a flag-bit it each thread. This bit is checked as each thread crosses the user boundary. So, there will always be some state change in the target process from the time SIGSTOP is posted to the time all threads are actually stopped. I was wondering if I could improve this a bit by calling PT_SUSPEND on all threads, instead of posting SIGSTOP and waiting for all threads to stop. Once the core is generated, unsuspend all threads. As with SIGSTOP, individual thread will only notice suspension as they cross user boundary. But there is no overhead of tagging a thread to handle the signal and that thread doing the suspension. The idea is to try and generate the core file which reflects the running state of the process as closely as possible. Does this sound reasonable ? Thanks, Sushanth