Date: Tue, 30 Nov 2004 17:20:19 GMT From: David Schultz <das@FreeBSD.ORG> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/70708: gcore/procfs not finding /proc/pid/file on repeated invocations when running from NFS Message-ID: <200411301720.iAUHKJrW087455@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/70708; it has been noted by GNATS. From: David Schultz <das@FreeBSD.ORG> To: Volker Stolz <stolz@i2.informatik.rwth-aachen.de> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200411301720.iAUHKJrW087455>