Two other crazy clues:
If we start here with this error...
find /usr -type l -exec stat -f '%N' {} + |wc -l
find: fts_read: Cannot allocate memory
   3054
..and then walk down the hierarchy, it turns out that (unsurprisingly)
man3 must be within the encompassing path for the error to happen:
find /usr/share/man/man3 -type l -exec ls -d {} + |wc
find: fts_read: Cannot allocate memory
   1335   1335   58596
(i used
ls instead of
stat there, but... same difference).
Now watch this: take
out the
-type l parameter, and poof: no more error...
find /usr/share/man/man3 -exec ls -d {} + |wc
   6803   6804   285957
...despite the large amount of data (almost 286K worth of pathnames, involving three calls to
ls as opposed to one).
Another odd couple, this time using the
-size primary:
find /usr/share/man/man3 -size -24c -exec ls -d {} + |wc
   842   843   30658
find /usr/share/man/man3 -size -25c -exec ls -d {} + |wc
find: fts_read: Cannot allocate memory
   919   920   33604
Looks like the character count (of the pathname data) crosses the 32K boundary there... but i'm not sure if that was the tipping point or just coincidence.
I think the authors of
find and
fts need to meet each other.
