Re: pkg/57145: gmake: *** INTERNAL: readdir: Operation not supported. Stop.

["Havard Eidnes via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR kern/57145; it has been noted by GNATS.

From: Havard Eidnes <he%NetBSD.org@localhost>
To: gnats-bugs%netbsd.org@localhost, gnats-admin%NetBSD.org@localhost
Cc: mrg%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost, andrew.cagney%gmail.com@localhost,
 riastradh%NetBSD.org@localhost
Subject: Re: pkg/57145: gmake: *** INTERNAL: readdir: Operation not
 supported. Stop.
Date: Tue, 20 Jan 2026 17:12:12 +0100 (CET)

 Hi,
 
 I just observed this problem on NetBSD/amd64 10.1 with
 gmake-4.4.1 while trying to build wip/wsjtx/, with:
 
 gmake[5]: *** readdir .: Invalid argument.  Stop.
 gmake[5]: *** Waiting for unfinished jobs....
 
 The gmake is from NetBSD bulk build:
 
 BUILD_DATE=3D2025-07-02 19:43:11 +0000
 BUILD_HOST=3DNetBSD shadow.netbsd.org 10.0 NetBSD 10.0 (LIBKVER) #0: Tu=
 e Jan 19 00:00:00 UTC 2038 root@localhost:/sys/arch/amd64/compile/LIBKV=
 ER amd64
 
 This is on a build done with MAKE_JOBS=3D40 on a 20-physical-cores
 and 40 "virtual cores" with HT enabled system.
 
 After the initial failure of this type, I decided to try to
 capture the system call information with "ktrace -i", and as it
 happened, the problem was reproduced with a ktrace.out file of a
 mere 520MB.
 
 The gmake system calls preceding this error were:
 
  14717  14717 gmake    CALL  lseek(6,0,0,1)
  14717  14717 gmake    RET   lseek 0
  14717  14717 gmake    CALL  __getdents30(6,0x79e73d4a0000,0x1000)
  14717  14717 gmake    GIO   fd 6 read 4080 bytes
 ...(omitted here)...
  14717  14717 gmake    RET   __getdents30 4080/0xff0
  14717  14717 gmake    CALL  lseek(6,0,0,1)
  14717  14717 gmake    RET   lseek 3132/0xc3c
  14717  14717 gmake    CALL  __getdents30(6,0x79e73d4a0000,0x1000)
  14717  14717 gmake    RET   __getdents30 -1 errno 22 Invalid argument
 
 and it's all downhill from there.
 
 Does anyone want access to the 520MB ktrace.out file for a closer
 look, as there is (of course) intervening syscalls from other
 processes in the process tree covered by the top-level make
 invocation?
 
 Regards,
 
 - H=E5vard