bug#13516: tests/rm/unread3 fails on Mac OS X 10.8

[Pádraig Brady]

On 01/21/2013 07:51 PM, Assaf Gordon wrote:
> Hello,
>
> Testing the latest coreutils on Mac OS X, "tests/rm/unread3" fails.
> The immediate cause is:
> "rm: unable to record current working directory: Too many open files"


> Attached is the relevant part from the log file.
>
> The programs were compiled using:
> ===
> $ ./configure CC=clang
>
> ## --------- ##
> ## Platform. ##
> ## --------- ##
>
> hostname = minimacc.local
> uname -m = i386
> uname -r = 10.8.0
> uname -s = Darwin
> uname -v = Darwin Kernel Version 10.8.0: Tue Jun  7 16:33:36 PDT 2011; 
> root:xnu-1504.15.3~1/RELEASE_I386
>
> /usr/bin/uname -p = i386
> /bin/uname -X     = unknown
>
> /bin/arch              = unknown
> /usr/bin/arch -k       = unknown
> /usr/convex/getsysinfo = unknown
> /usr/bin/hostinfo      = Mach kernel version:
>           Darwin Kernel Version 10.8.0: Tue Jun  7 16:33:36 PDT 2011; 
> root:xnu-1504.15.3~1/RELEASE_I386
> Kernel configured for up to 2 processors.
> 2 processors are physically available.
> 2 processors are logically available.
> Processor type: i486 (Intel 80486)
> Processors active: 0 1
> Primary memory available: 2.00 gigabytes
> Default processor set: 71 tasks, 267 threads, 2 processors
> Load average: 0.19, Mach factor: 1.80
> /bin/machine           = unknown
> /usr/bin/oslevel       = unknown
> /bin/universe          = unknown
> [...]
> configure:4946: clang --version >&5
> Apple clang version 4.1 (tags/Apple/clang-421.11.66) (based on LLVM 3.1svn)
> Target: x86_64-apple-darwin10.8.0
> Thread model: posix
> configure:4957: $? = 0
> configure:4946: clang -v >&5
> Apple clang version 4.1 (tags/Apple/clang-421.11.66) (based on LLVM 3.1svn)
> Target: x86_64-apple-darwin10.8.0
> Thread model: posix
> ===
>
> -gordon
>
> P.S.
> To compile it on Mac, Paul Eggert's fix is required ( 
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13495 ).


Interesting. That's coming from openat_save_fail() in gnulib.
There was a similar issue reported on AIX 5.1 recently:
http://lists.gnu.org/archive/html/coreutils/2012-01/msg00059.html
Do the gnulib tests pass?
Perhaps you could add some instrumentation to the
gnulib code in that's being called in lib/
to see why that's happening?

thanks,
Pádraig.