Date: Tue, 15 Jan 2013 23:53:05 +0100 From: Jilles Tjoelker <jilles@stack.nl> To: Garrett Cooper <yanegomi@gmail.com> Cc: FreeBSD Current <freebsd-current@freebsd.org>, kib@FreeBSD.org Subject: Re: ktrace -d broken on current/stable-9 Message-ID: <20130115225305.GA12294@stack.nl> In-Reply-To: <4850A09B-A054-4B38-891C-06673F7195B2@gmail.com> References: <4850A09B-A054-4B38-891C-06673F7195B2@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jan 14, 2013 at 06:48:13PM -0800, Garrett Cooper wrote: > I tried using ktrace on a kernel compiled a week ago, and it appears > to not be following forks like it should on amd64: > # ktrace -d ./regress -l > [snip] > Not sure how it broke, but it was working a couple months ago (in > particular I remember it working either around October or November), > and the bug seems to have worked its way back to 9-STABLE (I'm running > into the same problem if I do ktrace -d, enter a shell, then exec > another shell from that shell). Haven't spent the time to bisect the > commits looking for the culprit (yet), but if need be I'll trace down > the culprit sometime this week. > truss works, so it doesn't seem like ptrace(2) is broken. ktrace -d is not really useful in the synopsis with a command. It only means that the child processes of ktrace (at a time just before it executes the utility) should be traced as well. This is almost always an empty set, unless you do things like cmd1 & ktrace -d cmd2 which will trace cmd2 and part of cmd1. You probably want ktrace -i. -- Jilles Tjoelker
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130115225305.GA12294>