From owner-freebsd-threads@FreeBSD.ORG Tue Dec 11 20:07:44 2007 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C12D16A468 for ; Tue, 11 Dec 2007 20:07:44 +0000 (UTC) (envelope-from emaste@freebsd.org) Received: from gw.sandvine.com (gw.sandvine.com [199.243.201.138]) by mx1.freebsd.org (Postfix) with ESMTP id DE31813C469 for ; Tue, 11 Dec 2007 20:07:43 +0000 (UTC) (envelope-from emaste@freebsd.org) Received: from labgw2.phaedrus.sandvine.com ([192.168.3.11]) by gw.sandvine.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Dec 2007 14:55:41 -0500 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 12627) id 8371811657; Tue, 11 Dec 2007 14:55:41 -0500 (EST) Date: Tue, 11 Dec 2007 14:55:41 -0500 From: Ed Maste To: Vaidehi Shukla Message-ID: <20071211195541.GA51608@sandvine.com> References: <90242b1f0611220412l4ef4c92jd6f3e308f7c882fd@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <90242b1f0611220412l4ef4c92jd6f3e308f7c882fd@mail.gmail.com> User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 11 Dec 2007 19:55:41.0711 (UTC) FILETIME=[CF2E59F0:01C83C2F] Cc: freebsd-threads@freebsd.org Subject: Re: gcore thread problem? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2007 20:07:44 -0000 On Wed, Nov 22, 2006 at 05:42:33PM +0530, Vaidehi Shukla wrote: > 'gcore' doesn't display correct backtrace (info threads) for multi-threaded > application. Is there any way to get correct backtrace (i.e. info threads) > with gcore in freebsd?. Let me know if you can suggest some method to get > correct backtrace. I've patched gcore to use the ptrace(2) interface instead of procfs to get the per-thread state and plan to commit this in the not-too-distant future. One issue with the change though is that gcore can currently create a core asynchronously (i.e., without stopping the process). The core may have inconsistent data in it in this case, but it may be that the process is critical and cannot be stopped during the core creation. The ptrace change I made requires the process to be stopped for at least a short interval. -Ed