find breaks due to "EDC5113I Bad file descriptor"

[IgorTodorovskiIBM]

find . -name "test"

The output is:

find: '.': EDC5113I Bad file descriptor.

[MikeFultonDev]

fwiw, confirmed :)

[MikeFultonDev]

added a __ctrace("") call in the 'error' code. This generates a CEEDUMP containing:

    1     ctrace      +000000B8              CELQLIB                                             HLE77C0  Call
    2     error       +00000122              find                                                         Call
    3     report_file_err
                      +0000009A              find                                                         Call
    4     nonfatal_target_file_error
                      +00000038              find                                                         Call
    5     consider_visiting
                      +00000256              find                                                         Call
    6     find        +00000314              find                                                         Call
    7     process_all_startpoints
                      +000008B4              find                                                         Call
    8     main        +0000039A              find                                                         Call

so at least we know where the error is coming from

[MikeFultonDev]

rebuilding with -Wc,gonum to get line numbers in the traceback:

    1     ctrace      +000000B8              CELQLIB                                             HLE77C0  Call
    2     error       +00000128  325         find                 error.c                                 Call
    3     report_file_err
                      +0000009A  1122        find                 util.c                                  Call
    4     nonfatal_target_file_error
                      +00000038  1136        find                 util.c                                  Call
    5     consider_visiting
                      +00000262  304         find                 ftsfind.c                               Call
    6     find        +0000031E  536         find                 ftsfind.c                               Call
    7     process_all_startpoints
                      +000008C6  709         find                 ftsfind.c                               Call
    8     main        +000003AC  816         find                 ftsfind.c                               Call
    9     CELQINIT    +00001ACA              CELQLIB              CELQINIT                       HLE77C0  Call

[MikeFultonDev]

running with the -D search option:

find/find -D search /tmp -name "*.c"
consider_visiting (early): '/tmp': fts_info=FTS_D , fts_level= 0, prev_depth=-2147483648 fts_path='/tmp', fts_accpath='/tmp'
consider_visiting (late): '/tmp': fts_info=FTS_D , isdir=1 ignore=0 have_stat=1 have_type=1
consider_visiting (early): '/tmp': fts_info=FTS_ERR, fts_level= 0, prev_depth=0 fts_path='/tmp', fts_accpath='/tmp'

[MikeFultonDev]

zeroing in, fts_build is calling fcntl (dir_fd, F_DUPFD_CLOEXEC, STDERR_FILENO + 1); with a file descriptor of 4 and is getting back -1 and errno of invalid file descriptor``

[MikeFultonDev]

Doing a 'stat' on file descriptor 4 shows it is invalid (so the error is earlier)

[MikeFultonDev]

Investigating, but two things that look to be true...

1. the dd_fd in the DIR structure doesn't appear to be something you can just 'dup'. A testcase follows that shows this
2. there is no F_DUPFD_CLOEXEC in the LE headers and so this function may not exist

#define _ALL_SOURCE

#include <sys/types.h>
#include <dirent.h>
#include <stdio.h>
#include <fcntl.h>
#include <errno.h>

int main() {
  const char* dirname = "/tmp";
  int new;

  DIR* dir;
  dir = opendir(dirname);

  printf("dir:%p\n", dir);
  printf("fd: %d\n", dir->dd_fd);

  new = fcntl(dir->dd_fd, F_DUPFD, 3);
  printf("new fd: %d errno:%d\n", new, errno);

  return 0;
}

[MikeFultonDev]

Changing configure to not look for dd_fd, I am still seeing the same problem that fcntl is trying to use a file descriptor that fstat doesn't like.
There is 'gl' (gnulib code) to provide the function for the various file descriptor services needed, like dirfd... Need to figure out what can be done with a 'directory' file descriptor.

[MikeFultonDev]

What appears to be the issue is that opendirat() calls fdopendir with the newfd.
The processing of fdopendir creates the DIR structure but as a side effect, it closes the newfd (presumably because the code will use the file descriptor inside the DIR structure now - but unfortunately that doesn't seem to work).

The code is a bit confusing because it's a mix of functions provided by LE and functions provided by gnulib included functions.

Also, flags are being passed down to openat, then passed into open (which is the z/OS open, not the provided open from find), which itself is presumably coming from zoslib. The flags being passed down aren't valid on z/OS but seem to be being ignored ok (e.g. O_DIRECTORY, O_CLOEXEC)

After all this, I'm thinking it might be easier to put back the search for dd_fd

[MikeFultonDev]

It would be interesting to see how this works on a z/OS 2.5 system that apparently has fdopendir()

[dougburns]

Is this still an issue?
I was going to see if the z/OS 2.5 build gives different behaviour, but I don't see the error with builds at 2.5 or 2.4 (my own or the current Jenkins build).

[IgorTodorovskiIBM]

This should be resolved, please close if ok