bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

"*** INTERNAL: readdir: Invalid argument" error


From: Eli Zaretskii
Subject: "*** INTERNAL: readdir: Invalid argument" error
Date: Wed, 15 May 2013 12:29:32 +0300

For the actual use case, see the discussion on the MinGW mailing list
about that.  The important part starts here:

  https://sourceforge.net/mailarchive/message.php?msg_id=30846737

To make the long story short:

  . The problem is a complete failure of Make to run, where it bails
    out before even trying to look for a Makefile, with the error
    message cited in the subject.  (The error message is quite
    cryptic, and it took a while to understand what is causing it.)

  . This happens when Make looks for a suitable shell, see the
    function find_and_set_default_shell, which is Windows specific.
    As part of that function, Make looks along PATH for the executable
    file named sh.exe.  For each directory on PATH, Make calls
    file_exists_p to find out whether sh.exe exists in that directory.
    That call then eventually winds up in dir_contents_file_exists_p,
    where we have this snippet:

      ENULLLOOP (d, readdir (dir->dirstream));
      if (d == 0)
        {
          if (errno)
            fatal (NILF, "INTERNAL: readdir: %s\n", strerror (errno));
          break;
        }

  . It turns out that, for whatever reasons, if there's a file with
    non-ASCII characters in some directory on PATH, MinGW's 'readdir'
    sometimes returns a non-zero errno value.  (I suspect that the
    problem is with non-ASCII characters that are not representable in
    the current console codepage encoding, but that's a guess, since I
    cannot reproduce this on my system.)

  . When that problem happens, Make exits with a fatal error, as you
    see from the code snippet above.  The user is left wondering what
    the heck happened, since no useful diagnostics is shown.

Question: Why do we force a fatal error when 'readdir' fails in that
way?  Would it be better to display a warning, perhaps even under some
debug command-line option, and otherwise simply treat that as the end
of the directory stream?

If we do want to force a failure in this case, I guess I will need to
look for a Windows-specific solution, since other platforms don't use
dir_contents_file_exists_p to look for files that are not explicitly
mentioned in the Makefile.  Most probably, I will refrain from calling
file_exists_p entirely in find_and_set_default_shell, and instead test
for the existence of the shell executable file by trying to access it
directly.

Comments?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]