kern/70708: gcore/procfs not finding /proc/pid/file on repeated invocations when running from NFS

Volker Stolz vs at FreeBSD.org
Fri Aug 20 06:30:14 PDT 2004


>Number:         70708
>Category:       kern
>Synopsis:       gcore/procfs not finding /proc/pid/file on repeated invocations when running from NFS
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Aug 20 13:30:13 GMT 2004
>Closed-Date:
>Last-Modified:
>Originator:     Volker Stolz
>Release:        FreeBSD 4.10-STABLE i386
>Organization:
Lehrstuhl für Informatik II; RWTH Aachen Universität
>Environment:

System: FreeBSD menelaos.informatik.rwth-aachen.de 4.10-STABLE FreeBSD 4.10-STABLE #17: Tue Jun 22 17:00:16 CEST 2004 root at menelaos.informatik.rwth-aachen.de:/usr/obj/usr/src/sys/MENELAOS i386
Effect: Can't find /proc/pid/file on repeated invocations

System: FreeBSD monster.theater.foldr.org 5.2.1-RELEASE FreeBSD 5.2.1-RELEASE #0: Mon Feb 23 20:45:55 GMT 2004     root at wv1u.btc.adaptec.com:/usr/obj/usr/src/sys/GENERIC  i386
Effect: gcore fails to restart the program(?)

>Description:
The attached program invokes /usr/bin/gcore via system() to obtain its core.
Interestingly, it only works for the first time on 4.10 when on a NFS-mounted directory
and then only again after 'changing' the directory. It does not happen on a local drive!
See How-To-Repeat below. The procfs-file-entry for some reason gets set to "uknown"
in between.

On 5.2.1, gcore 'fails to wake up the process' despite the -s (in quotes because
I'm not sure what's going on).

vs at monster [15:00:42]> ./a.out
I'm 50559
Calling gcore -s 50559

[1]+  Stopped                 ./a.out
vs at monster [15:12:52]>
...
vs at monster [15:13:00]> jobs
[1]+  Stopped                 ./a.out


>How-To-Repeat:
Compile attached program on a NFS-directory. Note that I was only able to
reliably reproduce this when /invoking/via/long/nfs/mounted/path/to/a.out!
It takes longer to happen when I'm simply in NFS-mounted $HOME and doesn't seem to
happen at all on a local drive. Notice how an intermediate "cd ." helps.

pthread at menelaos [15:18:45]> ./a.out
I'm 78260
Calling gcore -s 78260

[1]+  Stopped                 ./a.out
pthread at menelaos [15:18:46]> ./a.out
I'm 78263
Calling gcore -s 78263
gcore: /proc/78263/file: No such file or directory
system failed: 256
lr-xr-xr-x  1 stolz  info2  7 Aug 20 15:18 /proc/78263/file -> unknown
[1]+  Done                    ./a.out
pthread at menelaos [15:18:46]> ./a.out
I'm 78268
Calling gcore -s 78268
gcore: /proc/78268/file: No such file or directory
system failed: 256
lr-xr-xr-x  1 stolz  info2  7 Aug 20 15:18 /proc/78268/file -> unknown
pthread at menelaos [15:18:48]> cd .
pthread at menelaos [15:18:49]> ./a.out
I'm 78273
Calling gcore -s 78273

[1]+  Stopped                 ./a.out
pthread at menelaos [15:18:51]> ./a.out
I'm 78276
Calling gcore -s 78276
gcore: /proc/78276/file: No such file or directory
system failed: 256
lr-xr-xr-x  1 stolz  info2  7 Aug 20 15:18 /proc/78276/file -> unknown
[1]+  Done                    ./a.out

=================================================================
#include <sys/types.h>
#include <unistd.h>

#include <signal.h>
#include <stdlib.h>
#include <stdio.h>

static void gencore(char *);

static char buf[256];
static char lsbuf[256];

static pid_t pid;

int main(int argc, char** argv) {

        pid = getpid();
        fprintf(stderr,"I'm %i\n",pid);
        sprintf(buf,"gcore -s %i",pid);
        sprintf(lsbuf,"ls -l /proc/%i/file",pid);
        gencore(buf);
        exit(0);
}

void gencore(char *buf) {
	int res;
	fprintf(stderr,"Calling %s\n",buf);
        res = system(buf);
	if (res != 0) {
	  fprintf(stderr,"system failed: %i\n",res);
	  system(lsbuf);
	}
        exit(0);
}
=================================================================

>Fix:

	


>Release-Note:
>Audit-Trail:
>Unformatted:


More information about the freebsd-bugs mailing list