Re: detect valid fd
On Tue, Sep 16, 2014 at 12:51:24AM +0100, Justin Cormack wrote:
On Tue, Sep 16, 2014 at 12:20 AM, Patrick Welche pr...@cam.ac.uk wrote:
Given a filedescriptor, how can you tell that it is valid and has been
opened?
In the attached simple program, a file and a directory are opened
(with CLOEXEC set). I then call fcntl(fd, F_GETFD) on the range
fd = [3..15]. fd = {3,4} correspond to the open file and directory.
Why don't I get fcntl(4):
[EBADF]fildes is not a valid open file descriptor.
for fd = [5..15], but only for some of them?
$ ./cloexec
fd 3 testfile.txt flags = 0x1 (0x1)
fd 4 testdir flags = 0x1 (0x1)
fd 3's flags = 0x1 (0x1)
fd 4's flags = 0x1 (0x1)
fd 5's flags = 0x0 (0x0)
fd 6's flags = 0x0 (0x0)
fd 7's flags = 0x0 (0x0)
fd 8's flags = 0x0 (0x0)
fd 9's flags = 0x0 (0x0)
fd 10's flags = 0x0 (0x0)
cloexec: fcntl 11: Bad file descriptor
cloexec: fcntl 12: Bad file descriptor
fd 13's flags = 0x0 (0x0)
fd 14's flags = 0x0 (0x0)
cloexec: fcntl 15: Bad file descriptor
I get
fd 3 testfile.txt flags = 0x1 (0x1)
fd 4 testdir flags = 0x1 (0x1)
fd 3's flags = 0x1 (0x1)
fd 4's flags = 0x1 (0x1)
cloexec: fcntl 5: Bad file descriptor
cloexec: fcntl 6: Bad file descriptor
cloexec: fcntl 7: Bad file descriptor
cloexec: fcntl 8: Bad file descriptor
cloexec: fcntl 9: Bad file descriptor
cloexec: fcntl 10: Bad file descriptor
cloexec: fcntl 11: Bad file descriptor
cloexec: fcntl 12: Bad file descriptor
cloexec: fcntl 13: Bad file descriptor
cloexec: fcntl 14: Bad file descriptor
cloexec: fcntl 15: Bad file descriptor
Which looks fine, on netbsd6.1.4 and 7-pre, both on amd64.
What NetBSD version are you testing on?
So for both of you, things look correct!
This is on Sunday's NetBSD 7.99.1 amd64, but this is an old problem for
me...
Cheers,
Patrick
Re: detect valid fd
On Tue, Sep 16, 2014 at 12:59 AM, Patrick Welche pr...@cam.ac.uk wrote: So for both of you, things look correct! This is on Sunday's NetBSD 7.99.1 amd64, but this is an old problem for me... Very odd. What does ktrace output look like? Which other versions did you see this on before? Justin
Re: detect valid fd
On Sep 15, 2014, at 4:59 PM, Patrick Welche pr...@cam.ac.uk wrote:
On Tue, Sep 16, 2014 at 12:51:24AM +0100, Justin Cormack wrote:
On Tue, Sep 16, 2014 at 12:20 AM, Patrick Welche pr...@cam.ac.uk wrote:
Given a filedescriptor, how can you tell that it is valid and has been
opened?
In the attached simple program, a file and a directory are opened
(with CLOEXEC set). I then call fcntl(fd, F_GETFD) on the range
fd = [3..15]. fd = {3,4} correspond to the open file and directory.
Why don't I get fcntl(4):
[EBADF]fildes is not a valid open file descriptor.
for fd = [5..15], but only for some of them?
$ ./cloexec
fd 3 testfile.txt flags = 0x1 (0x1)
fd 4 testdir flags = 0x1 (0x1)
fd 3's flags = 0x1 (0x1)
fd 4's flags = 0x1 (0x1)
fd 5's flags = 0x0 (0x0)
fd 6's flags = 0x0 (0x0)
fd 7's flags = 0x0 (0x0)
fd 8's flags = 0x0 (0x0)
fd 9's flags = 0x0 (0x0)
fd 10's flags = 0x0 (0x0)
cloexec: fcntl 11: Bad file descriptor
cloexec: fcntl 12: Bad file descriptor
fd 13's flags = 0x0 (0x0)
fd 14's flags = 0x0 (0x0)
cloexec: fcntl 15: Bad file descriptor
I get
fd 3 testfile.txt flags = 0x1 (0x1)
fd 4 testdir flags = 0x1 (0x1)
fd 3's flags = 0x1 (0x1)
fd 4's flags = 0x1 (0x1)
cloexec: fcntl 5: Bad file descriptor
cloexec: fcntl 6: Bad file descriptor
cloexec: fcntl 7: Bad file descriptor
cloexec: fcntl 8: Bad file descriptor
cloexec: fcntl 9: Bad file descriptor
cloexec: fcntl 10: Bad file descriptor
cloexec: fcntl 11: Bad file descriptor
cloexec: fcntl 12: Bad file descriptor
cloexec: fcntl 13: Bad file descriptor
cloexec: fcntl 14: Bad file descriptor
cloexec: fcntl 15: Bad file descriptor
Which looks fine, on netbsd6.1.4 and 7-pre, both on amd64.
What NetBSD version are you testing on?
So for both of you, things look correct!
This is on Sunday's NetBSD 7.99.1 amd64, but this is an old problem for
me...
What does fstat show for your shell or add a pause to the program and fstat it?
fstat -p $$
Re: detect valid fd
On Mon, Sep 15, 2014 at 05:11:12PM -0700, Matt Thomas wrote:
On Sep 15, 2014, at 4:59 PM, Patrick Welche pr...@cam.ac.uk wrote:
On Tue, Sep 16, 2014 at 12:51:24AM +0100, Justin Cormack wrote:
On Tue, Sep 16, 2014 at 12:20 AM, Patrick Welche pr...@cam.ac.uk wrote:
Given a filedescriptor, how can you tell that it is valid and has been
opened?
In the attached simple program, a file and a directory are opened
(with CLOEXEC set). I then call fcntl(fd, F_GETFD) on the range
fd = [3..15]. fd = {3,4} correspond to the open file and directory.
Why don't I get fcntl(4):
[EBADF]fildes is not a valid open file descriptor.
for fd = [5..15], but only for some of them?
$ ./cloexec
fd 3 testfile.txt flags = 0x1 (0x1)
fd 4 testdir flags = 0x1 (0x1)
fd 3's flags = 0x1 (0x1)
fd 4's flags = 0x1 (0x1)
fd 5's flags = 0x0 (0x0)
fd 6's flags = 0x0 (0x0)
fd 7's flags = 0x0 (0x0)
fd 8's flags = 0x0 (0x0)
fd 9's flags = 0x0 (0x0)
fd 10's flags = 0x0 (0x0)
cloexec: fcntl 11: Bad file descriptor
cloexec: fcntl 12: Bad file descriptor
fd 13's flags = 0x0 (0x0)
fd 14's flags = 0x0 (0x0)
cloexec: fcntl 15: Bad file descriptor
What does fstat show for your shell or add a pause to the program and fstat
it?
prlw1cloexec 2336 wd /home1424735 drwxr-xr-x 512 r
prlw1cloexec 23360 /dev/pts 13 crw--w pts/5 rw
prlw1cloexec 23361 /dev/pts 13 crw--w pts/5 rw
prlw1cloexec 23362 /dev/pts 13 crw--w pts/5 rw
prlw1cloexec 23363 /home1424738 -rw-r--r-- 0 r
prlw1cloexec 23364 /home1424739 drwxr-xr-x 512 r
prlw1cloexec 23365 /usr 7438302 -r--r--r--5852 r
prlw1cloexec 23366 /usr 7431819 -r--r--r--5879 r
prlw1cloexec 23367 flags 0x80034ISTTY,MPSAFE,LOCKSWORK,CLEAN
prlw1cloexec 23368 flags 0x80034ISTTY,MPSAFE,LOCKSWORK,CLEAN
prlw1cloexec 23369* pipe 0xfe814d38cdc0 - 0x0 w
prlw1cloexec 2336 10 /usr 7439186 -r--r--r-- 58736 r
prlw1cloexec 2336 13 /home1375614 -rw-r--r-- 18 r
prlw1cloexec 2336 14 flags 0x80024ISTTY,LOCKSWORK,CLEAN
fd 3 4 are intended. Of the other inodes, I only found:
fd 10 is /usr/X11R7/lib/X11/fonts/TTF/VeraSeBd.ttf
fd 13 is /home/prlw1/.xsmstartup
Cheers,
Patrick
Re: detect valid fd
On Mon, Sep 15, 2014 at 05:11:12PM -0700, Matt Thomas wrote:
On Sep 15, 2014, at 4:59 PM, Patrick Welche pr...@cam.ac.uk wrote:
On Tue, Sep 16, 2014 at 12:51:24AM +0100, Justin Cormack wrote:
On Tue, Sep 16, 2014 at 12:20 AM, Patrick Welche pr...@cam.ac.uk wrote:
Given a filedescriptor, how can you tell that it is valid and has been
opened?
In the attached simple program, a file and a directory are opened
(with CLOEXEC set). I then call fcntl(fd, F_GETFD) on the range
fd = [3..15]. fd = {3,4} correspond to the open file and directory.
Why don't I get fcntl(4):
[EBADF]fildes is not a valid open file descriptor.
for fd = [5..15], but only for some of them?
$ ./cloexec
fd 3 testfile.txt flags = 0x1 (0x1)
fd 4 testdir flags = 0x1 (0x1)
fd 3's flags = 0x1 (0x1)
fd 4's flags = 0x1 (0x1)
fd 5's flags = 0x0 (0x0)
fd 6's flags = 0x0 (0x0)
fd 7's flags = 0x0 (0x0)
fd 8's flags = 0x0 (0x0)
fd 9's flags = 0x0 (0x0)
fd 10's flags = 0x0 (0x0)
cloexec: fcntl 11: Bad file descriptor
cloexec: fcntl 12: Bad file descriptor
fd 13's flags = 0x0 (0x0)
fd 14's flags = 0x0 (0x0)
cloexec: fcntl 15: Bad file descriptor
What does fstat show for your shell or add a pause to the program and fstat
it?
prlw1cloexec 2336 wd /home1424735 drwxr-xr-x 512 r
prlw1cloexec 23360 /dev/pts 13 crw--w pts/5 rw
prlw1cloexec 23361 /dev/pts 13 crw--w pts/5 rw
prlw1cloexec 23362 /dev/pts 13 crw--w pts/5 rw
prlw1cloexec 23363 /home1424738 -rw-r--r-- 0 r
prlw1cloexec 23364 /home1424739 drwxr-xr-x 512 r
prlw1cloexec 23365 /usr 7438302 -r--r--r--5852 r
prlw1cloexec 23366 /usr 7431819 -r--r--r--5879 r
prlw1cloexec 23367 flags 0x80034ISTTY,MPSAFE,LOCKSWORK,CLEAN
prlw1cloexec 23368 flags 0x80034ISTTY,MPSAFE,LOCKSWORK,CLEAN
prlw1cloexec 23369* pipe 0xfe814d38cdc0 - 0x0 w
prlw1cloexec 2336 10 /usr 7439186 -r--r--r-- 58736 r
prlw1cloexec 2336 13 /home1375614 -rw-r--r-- 18 r
prlw1cloexec 2336 14 flags 0x80024ISTTY,LOCKSWORK,CLEAN
and simple guesses for /home and /usr didn't find a -inum match. Trying
a long find now...
Cheers,
Patrick
Re: detect valid fd
In article 20140915232046.ga9...@quark.cable.rcn.com,
Patrick Welche pr...@cam.ac.uk wrote:
-=-=-=-=-=-
Given a filedescriptor, how can you tell that it is valid and has been
opened?
In the attached simple program, a file and a directory are opened
(with CLOEXEC set). I then call fcntl(fd, F_GETFD) on the range
fd = [3..15]. fd = {3,4} correspond to the open file and directory.
Why don't I get fcntl(4):
[EBADF]fildes is not a valid open file descriptor.
for fd = [5..15], but only for some of them?
$ ./cloexec
fd 3 testfile.txt flags = 0x1 (0x1)
fd 4 testdir flags = 0x1 (0x1)
fd 3's flags = 0x1 (0x1)
fd 4's flags = 0x1 (0x1)
fd 5's flags = 0x0 (0x0)
fd 6's flags = 0x0 (0x0)
fd 7's flags = 0x0 (0x0)
fd 8's flags = 0x0 (0x0)
fd 9's flags = 0x0 (0x0)
fd 10's flags = 0x0 (0x0)
cloexec: fcntl 11: Bad file descriptor
cloexec: fcntl 12: Bad file descriptor
fd 13's flags = 0x0 (0x0)
fd 14's flags = 0x0 (0x0)
cloexec: fcntl 15: Bad file descriptor
The motivation for the question is
https://bugs.freedesktop.org/show_bug.cgi?id=83899
Libc can open and keep file descriptors open internally. For example
if you run gethostbyname(foo) in your program, there is a file
descriptor kept open for the /etc/resolv.conf kqueue and one for
/etc/resolv.conf itself. There was a bug and this was not marked
close-on-exec, which I just fixed. Same is true if you use NIS, or
other subsystems that use file descriptors. Eventually all should
be close-on-exec. Unfortunately there are other things that use
file descriptors internally (crypto, semaphores) on NetBSD that
are possibly more difficult to tackle.
christos
of them close-on-exec
re: detect valid fd
prlw1cloexec 2336 10 /usr 7439186 -r--r--r-- 58736 r prlw1cloexec 2336 13 /home1375614 -rw-r--r-- 18 r fd 10 is /usr/X11R7/lib/X11/fonts/TTF/VeraSeBd.ttf fd 13 is /home/prlw1/.xsmstartup looks like X has some close-on-exec problems as well. xsm is probably not too hard to track down, but the font one might be. you could run ktrace -id startx when firing up X, and then see where these are opened and see if you can find what's missing to make them closed... the test that is failing for freedesktop bug 83899 looks like not so much a bug in netbsd proper (kernel, or libc -- granted, christos did just fix some stuff we should pull up), but a bug in something X11, your shell, or some other userland component. (there's also an argument to be made that the test isn't really valid. why shouldn't i be able to pass fds around here? but there are security-based arguments that also apply here.) .mrg.
