bugmake - Bugs: bug #63330, readdir() error in 4.4 on Solaris 8

 
 

bug #63330: readdir() error in 4.4 on Solaris 8

Submitter:  None
Submitted:  Mon 07 Nov 2022 03:37:45 PM UTC
   
 
Severity:  3 - Normal Item Group:  Bug
Status:  Not A Bug Privacy:  Public
Assigned to:  None Open/Closed:  Closed
Component Version:  4.4 Operating System:  POSIX-Based
Fixed Release:  None Triage Status:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 08 Nov 2022 05:35:26 PM UTC, comment #12: 

Ah!  Good news!  Thanks for letting us know.

Paul D. Smith <psmith>
Group administrator
Tue 08 Nov 2022 05:06:29 PM UTC, comment #11: 

I was working from a git checkout and it appears that it somehow got into a strange state.  A build of a fresh download of the 4.4 tarball is fine.  My apologies for the confusion, this can be closed.

Anonymous
Tue 08 Nov 2022 03:41:25 PM UTC, comment #10: 

Wow I'm REALLY confused.  I've examined the config.log file you provided and I can't make heads or tails of it.  There is no reference anywhere in that file, to checking for largefile support.  This likely explains why it's not enabled on this system.

Just to be clear, you did download the official source build from https://ftp.gnu.org/gnu/make/make-4.4.tar.gz right?  Or, did you create the package yourself from Git?

Can you run md5sum on the downloaded package and the "configure" script in the directory; I get:

d7575a26a94ee8427130e9db23cdaa78  make-4.4.tar.gz
3d5221bb26db5cfa8b297738320f33b3  make-4.4/configure


When I look at your log file, I see this:

configure:6535: checking for ranlib
configure:6556: found /usr/ccs/bin/ranlib
configure:6567: result: ranlib
configure:6647: checking for size_t


Right in between the check for ranlib and the check for size_t, is where the check for largefile support is supposed to be.  Not only is there no output for it here, but the line numbers in the script are such that it doesn't seem like there's even any space in the configure script where this might be run!

When I run configure from make-4.4 on my system, I get this:

configure:6506: checking for ranlib
configure:6527: found /usr/bin/ranlib
configure:6538: result: ranlib
configure:6572: checking for special C compiler options needed for large files
configure:6620: result: no
configure:6626: checking for _FILE_OFFSET_BITS value needed for large files
configure:6652: gcc -c -g -O2  conftest.c >&5
configure:6652: $? = 0
configure:6687: result: no
configure:6962: checking for size_t


Note that it does do the check, and note that all the line numbers are a little off but the size_t check is a full 300 lines different (presumably where the largefile support check should be).


PS. from the config.log I note you invoked the configure script as just "configure".  I recommend you use "./configure" explicitly, if building from within the source directory, to avoid relying on the PATH settings.  I have no reason to believe this is the problem since the config.log appears to have been created from the GNU Make 4.4 configure, but I still recommend using a specific path.

Paul D. Smith <psmith>
Group administrator
Tue 08 Nov 2022 03:40:21 PM UTC, comment #9: 

Depending on _LARGEFILE64_SOURCE and _FILE_OFFSET_BITS dirent has d_ino and d_off fields 32 or 64 bits wide.
Looks like in your case the remote machine has 64bit d_ino and d_off and make is built with 32bit d_ino and d_off.

i don't see checks for _FILE_OFFSET_BITS in your config.log.
Does make work if you build 64 bit or set -D_FILE_OFFSET_BITS=64?
What is the difference, in regards to large file support, between your good working make-4.3 config.log and config.status and this one that fails?

In regards to the error see https://docs.oracle.com/cd/E19455-01/806-1075/msgs-2215/index.html


Dmitry Goncharov <dgoncharov>
Tue 08 Nov 2022 01:15:40 PM UTC, comment #8: 

Just checked and this also affects Solaris 10.  The issue looks identical, let me know if you want details from that system.

Anonymous
Tue 08 Nov 2022 12:53:15 PM UTC, comment #7: 

Oh and yes, 4.3 works just fine on NFS mounts.  It's what I've been using to build 4.4.  The NFS mount is definitely over 4GB but this is the first time I've run into issues with that.

Anonymous
Tue 08 Nov 2022 12:49:31 PM UTC, comment #6: 

I definitely don't expect everything to work perfectly on a system this old, and if it does turn out to be a Solaris bug I'll certainly find a way to deal with it locally.  That being said I find that compiling on these older systems sometimes turns up interesting corner cases.

Attached are config.log and config.status from a build configured with GCC 4.7.4.  Note that I had to manually remove -Wformat-signedness and -Wduplicated-cond from the generated Makefile because GCC 4.7.4 doesn't understand them, and disable -Werror for src/getopt.c, src/misc.c, and src/posixos.c all for harmless/unrelated warnings.

(file #53940, file #53941)

Anonymous
Tue 08 Nov 2022 05:49:46 AM UTC, comment #5: 

That's certainly disturbing and I would very much like to figure out what's wrong.  Just to be sure I built and ran the GNU Make regression tests on an NFS-mounted partition and it worked fine, but this was a GNU/Linux client and a NetApp NFS server so very different.  I unfortunately don't have access to a Solaris system.

It's hard to understand how a simple readdir() on an NFS directory would return EOVERFLOW.  The only thing I can think of is that your version of GNU make was not built with large file support enabled, and your NFS partition has sizes >4G, but that should not be the case as we include the gnulib largefile module.  Solaris 8 was released 22 years ago and went EOL >10 years ago, but presumably the largefile support will work there regardless.

Just to be clear, when you said that GNU Make 4.3 worked OK did you mean it worked on this same NFS partition where GNU Make 4.4 fails?

Can you either attach to this bug, or email to me directly at psmith@gnu.org, the config.log file and config.status file from the GNU Make 4.4 configure step?

Paul D. Smith <psmith>
Group administrator
Tue 08 Nov 2022 05:16:27 AM UTC, comment #4: 

It looks like this is somehow related to NFS.  I was running the newly-generated make in the root of the source tree, and on an NFS mounted directory it fails immediately.  If I copy the tree to a local directory I have no problems.

Anonymous
Mon 07 Nov 2022 06:04:35 PM UTC, comment #3: 

It's very strange because the code in 4.4 dir.c was changed in many places (to introduce directory cache invalidation) but this specific code related to readdir() is the same as in 4.3.

I think we will need to either get a repro case (even if it only repros on Solaris 8 just seeing the makefile that fails, and the "make -d" debug output, could be enlightening), or else access to a system where we can log in to reproduce the problem, or else someone willing to serve as "remote debugger" for us to track it down.

Paul D. Smith <psmith>
Group administrator
Mon 07 Nov 2022 03:59:53 PM UTC, comment #2: 

Oh, actually that can't be it.  I forgot that ENULLLOOP() sets errno=0 before it tries the command.

Hm.  Well, POSIX does allow EOVERFLOW to be returned by readdir() (that's the error you see).  So maybe there's something about the directory it's trying to read, that is problematic.

You may need to enhance the error message to show the name of the directory being parsed, then if you use "ls -al" on it do you see anything strange there?

For more debugging you could also show each filename as this readdir() reads it in, then perhaps you'd get an idea of which one is causing the problem (maybe).

Paul D. Smith <psmith>
Group administrator
Mon 07 Nov 2022 03:48:43 PM UTC, comment #1: 

Hm.  Maybe on Solaris readdir() doesn't reset errno?  In src/dir.c you'll find this code:


      ENULLLOOP (d, readdir (dir->dirstream));
      if (d == 0)
        {
          if (errno)
            pfatal_with_name ("INTERNAL: readdir");
          break;
        }


Try changing it to set errno first:


      errno = 0; /* add this line */
      ENULLLOOP (d, readdir (dir->dirstream));
      if (d == 0)
        {
          if (errno)
            pfatal_with_name ("INTERNAL: readdir");
          break;
        }


Paul D. Smith <psmith>
Group administrator
Mon 07 Nov 2022 03:37:45 PM UTC, original submission:  

I'm getting an error in readdir() on Solaris 8 with 4.4 compiled with both gcc and Sun Studio 11:

make: * INTERNAL: readdir: Value too large for defined data type.  Stop.

4.3 was fine.  Everything looks OK from a cursory glance, I'm not sure what's happening here.

Starting program: /scratch/make/make

Breakpoint 1, 0xff2cc484 in readdir () from /usr/lib/libc.so.1
(gdb) where
#0  0xff2cc484 in readdir () from /usr/lib/libc.so.1
#1  0x00019ac8 in dir_contents_file_exists_p (dir=0x6e988, filename=0x44db0 "GNUmakefile") at src/dir.c:726
#2  0x00019fd0 in dir_file_exists_p (filename=0x44db0 "GNUmakefile", dirname=0x40740 ".") at src/dir.c:805
#3  file_exists_p (name=0x44db0 "GNUmakefile") at src/dir.c:854
#4  0x000324b0 in read_all_makefiles (makefiles=0x0) at src/read.c:256
#5  0x00015b94 in main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at src/main.c:2069

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #53940:  config.log added by None (186KiB - application/octet-stream)
file #53941:  config.status added by None (47KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by dgoncharov (Posted a comment)
  • -email is unavailable- added by psmith (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-11-08 psmith StatusNone Not A Bug
        Open/ClosedOpen Closed
    2022-11-08 None Attached File- Added config.log, #53940
        Attached File- Added config.status, #53941

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code