Re: Simpler example of pathological behavior of directory caching

[Kyle Rose]

On Thu, Oct 6, 2016 at 12:06 PM, Paul Smith <address@hidden> wrote:

> 4.2.1 definitely broken, at least on my system.

It works on my system.  I've tried it multiple times.  I'm using Ubuntu
GNOME 16.04.1, with GNU libc 2.23, on an ext4 filesystem.

Broken here on on Debian using the Linux kernel with glibc 2.23 on ext4:

$ ldd ~/make-4.2.1
    linux-vdso.so.1 (0x00007ffdc316c000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fbd5495f000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fbd545be000)
    /lib64/ld-linux-x86-64.so.2 (0x000056101b9e3000)
$ dpkg -S /lib/x86_64-linux-gnu/libc.so.6
libc6:amd64: /lib/x86_64-linux-gnu/libc.so.6
$ dpkg -l libc6:amd64
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name             Version       Architecture  Description
+++-================-=============-=============-======================================
ii  libc6:amd64      2.23-5        amd64         GNU C Library: Shared libraries

Make was compiled from the source tarball with Debian's gcc 6.1.1.

I can't explain why your system is behaving differently.  Perhaps your
version of libc has an issue with the glob() or fnmatch() functions
(it's happened before).  Or maybe there's a bug in GNU make which is
system-dependent in some way.

It seems unlikely that this is an artifact of my specific system configuration, since I see the exact same behavior on MacOS. Starting from a clean directory (only Makefile exists there):

$ ~/make-4.2.1
touch target1
touch target2
touch target3
touch target4
touch target5
touch target6
touch target7
touch target8
touch target9
touch target10
glob:
$ ~/make-4.2.1
glob: target4 target2 target1 target5 target6 target7 target8 target9 target10 target3
$ uname -a
Darwin bos-mpi8u 15.6.0 Darwin Kernel Version 15.6.0: Mon Aug 29 20:21:34 PDT 2016; root:xnu-3248.60.11~1/RELEASE_X86_64 x86_64
$ ~/make-4.2.1 --version
GNU Make 4.2.1
Built for x86_64-apple-darwin15.6.0
Copyright (C) 1988-2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
$ otool -L ~/make-4.2.1
/Users/krose/make-4.2.1:
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)

Not Linux, not glibc, and not ext4.

Incidentally, make in this instance was also compiled from the same source tarball, but with Apple LLVM version 8.0.0 (clang-800.0.38).

 

Clearly, but it appears to be a defect that can only reproduced on your
system (so far), so you'll have to do a bit more digging.  Rewriting
the directory caching facility isn't the answer.

I trust you saw Martin's email?

If you send me a filtered ltrace:

ltrace -s 255 make 2>&1 >/dev/null | egrep -v -e '^(mem|str|free|malloc|__str|calloc|qsort)' -e resumed

I might be able to track down where the behavior differs on (AFAICT) very similar system configurations (Debian and Ubuntu with the same minor version of glibc). My gut tells me there's an inconsistency in the test setup, not in GNU make's behavior given the same starting conditions, which is exhibiting the same behavior on very different configurations (Debian vs. MacOS).

Kyle