From owner-freebsd-hackers Sat May 20 18: 2:49 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from sharmas.dhs.org (c62443-a.frmt1.sfba.home.com [24.0.69.165]) by hub.freebsd.org (Postfix) with ESMTP id 4CF3637B7EE for ; Sat, 20 May 2000 18:02:46 -0700 (PDT) (envelope-from adsharma@sharmas.dhs.org) Received: (from adsharma@localhost) by sharmas.dhs.org (8.9.3/8.9.3) id SAA04396 for freebsd-hackers@freebsd.org; Sat, 20 May 2000 18:02:29 -0700 Date: Sat, 20 May 2000 18:02:29 -0700 From: Arun Sharma To: FreeBSD Hackers Subject: truss(1) with support for fork(2) and friends Message-ID: <20000520180228.A4383@sharmas.dhs.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I just implemented the "-f" flag in truss, to trace across fork(2), rfork(2) and vfork(2) (the last one is not tested). The other day I observed that there were two truss processes when I was running "truss -f" on a Solaris box. I just thought it was a much simpler way of implementing "-f" than the strace (on Linux) way. So the implementation forks truss itself for each fork of the process being traced. It seems to work well for the most part, except for a race condition. The race condition happens because the child process could have gone away before the child truss could attach to it. Any suggestions to fix the race would be highly appreciated. I'm guilty of running indent against the source, before I did this work. So I can't generate a clean patch yet. But if I get good feedback on this work, I'll clean it up and produce a patch that can be commited. The tar ball is at: http://sharmas.dhs.org/~adsharma/projects/freebsd/truss.tar.gz This work could be useful to those of you thinking about implementing threads using rfork. -Arun To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message