From owner-freebsd-current@FreeBSD.ORG Tue Nov 17 11:21:53 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D536106568D; Tue, 17 Nov 2009 11:21:53 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id DDB018FC0C; Tue, 17 Nov 2009 11:21:52 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 7296D46B03; Tue, 17 Nov 2009 06:21:52 -0500 (EST) Date: Tue, 17 Nov 2009 11:21:52 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Attilio Rao In-Reply-To: <3bbf2fe10911160718j7784b311g2980aa02c79bc9ec@mail.gmail.com> Message-ID: References: <3bbf2fe10911160718j7784b311g2980aa02c79bc9ec@mail.gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Alexander Kabaev , freebsd-current@freebsd.org, Ed Maste , Alfred Perlstein Subject: Re: [PATCH] Let gcore use ptrace interface rather than the procfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 11:21:53 -0000 On Mon, 16 Nov 2009, Attilio Rao wrote: > This patch allows gcore to use the ptrace interface rather than procfs: > http://www.freebsd.org/~attilio/Sandvine/STABLE_8/gcore/gcore.diff > > The main visible effect of that is that gcore can now work on a per-thread > scope, offering a granularity procfs can't reach. A downside, though, is > that the process to be targeted is going to be stopped with ptrace. This > patch has been contributed back by Sandvine Incorporated. Comments, reviews > and testing are welcome. Am I right in thinking that this may run into a number of other issues that the procfs version didn't: - gcore may no longer work on processes that are actively being debugged with gdb or traced with truss. - gcore may cause interruptible system calls in the target process to return EINTR, and interfere with signal delivery. If so, these aren't show-stoppers, but we should make sure they're documented in the gcore man page. Fixing gcore would be excellent, it got missed in the initial sweep of things broken by disabling procfs by default. Thanks for doing this work, Robert N M Watson Computer Laboratory University of Cambridge