From owner-freebsd-bugs@FreeBSD.ORG Tue Nov 30 17:20:20 2004 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3177F16A4CE for ; Tue, 30 Nov 2004 17:20:20 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1DA8F43D2D for ; Tue, 30 Nov 2004 17:20:20 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id iAUHKJwG087456 for ; Tue, 30 Nov 2004 17:20:19 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id iAUHKJrW087455; Tue, 30 Nov 2004 17:20:19 GMT (envelope-from gnats) Date: Tue, 30 Nov 2004 17:20:19 GMT Message-Id: <200411301720.iAUHKJrW087455@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: David Schultz Subject: Re: kern/70708: gcore/procfs not finding /proc/pid/file on repeated invocations when running from NFS X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: David Schultz List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Nov 2004 17:20:20 -0000 The following reply was made to PR kern/70708; it has been noted by GNATS. From: David Schultz To: Volker Stolz Cc: FreeBSD-gnats-submit@FreeBSD.ORG Subject: Re: kern/70708: gcore/procfs not finding /proc/pid/file on repeated invocations when running from NFS Date: Tue, 30 Nov 2004 12:14:39 -0500 This is due to a bug in procfs. Specifically, procfs uses vn_fullpath() to generate the appropriate symbolic link for /proc/$pid/file, and vn_fullpath() fails if one or more pathname components is missing from the name cache. We cannot solve this problem in procfs without a fully functional getcwd() implementation in the kernel. However, for this particular problem, it may be possible to work around the problem in procfs, since the only reason gcore needs procfs is to determine if the binary is ELF or not. Possible solutions: - Extend ptrace(2) to make it possible to open a traced process' text file without procfs. This is generally a good idea anyway, because /proc/$pid/file will never work for processes whose text files have been unlinked from the file system. - Don't bother checking whether the binary is ELF or not, since gcore no longer supports a.out. This would result in invalid dumps for non-ELF processes, and merely defers the problem until someone invents an ELF++ dump format. I have no time to work on this right now, so it would be great if someone could pick this up.