Date: Tue, 17 Nov 2009 11:21:52 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Attilio Rao <attilio@freebsd.org> Cc: Alexander Kabaev <kan@freebsd.org>, freebsd-current@freebsd.org, Ed Maste <emaste@sandvine.com>, Alfred Perlstein <alfred@freebsd.org> Subject: Re: [PATCH] Let gcore use ptrace interface rather than the procfs Message-ID: <alpine.BSF.2.00.0911171120050.47035@fledge.watson.org> In-Reply-To: <3bbf2fe10911160718j7784b311g2980aa02c79bc9ec@mail.gmail.com> References: <3bbf2fe10911160718j7784b311g2980aa02c79bc9ec@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.0911171120050.47035>