Nicholas Gaya wrote:
> The process hierarchy starts with tclsh (MacPorts), then a bunch of layers of
> make and sh (from oath-toolkit's recursive `make check`), and finally the
> test-fcntl executable. I was using MacPorts' "trace mode", which seems to be
> responsible for the particularly high
The process hierarchy starts with tclsh (MacPorts), then a bunch of layers of
make and sh (from oath-toolkit's recursive `make check`), and finally the
test-fcntl executable. I was using MacPorts' "trace mode", which seems to be
responsible for the particularly high number of inherited open file
Nicholas Gaya wrote:
> it seems like the test process inherits a lot of open files from its parent,
> as the actual fd returned by fcntl is 67.
That seems excessive. What is the chain of parent, grandparent etc. processes?
Bruno
I ran into this issue when running tests for the MacPorts port of oath-toolkit
(https://ports.macports.org/port/oath-toolkit/) on Mac OS 10.14.6. I don't know
the specific reason, but it seems like the test process inherits a lot of open
files from its parent, as the actual fd returned by fcntl
Hi,
Nicholas Gaya wrote:
> fd 10 is already in use (which happens to be the case in the testing
> environment where I ran into this bug)
3 questions:
1) What is this environment that leaves fd 10 open when it starts a process?
2) For which purpose does it use this fd?
3) What would happen if we c
Hello,
I believe I have found a bug in gnulib's test-fcntl.c. In order to test the
functionality of fcntl with FD_DUPFD_CLOEXEC, the test dups an open file
descriptor using the flag and execs a child process to check that the file
descriptor gets closed on exec. The problem is that the current
