NetBSD Problem Report #57145
From www@netbsd.org Thu Dec 29 05:30:15 2022
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
by mollari.NetBSD.org (Postfix) with ESMTPS id 622BF1A923A
for <gnats-bugs@gnats.NetBSD.org>; Thu, 29 Dec 2022 05:30:15 +0000 (UTC)
Message-Id: <20221229053013.C63331A923B@mollari.NetBSD.org>
Date: Thu, 29 Dec 2022 05:30:13 +0000 (UTC)
From: andrew.cagney@gmail.com
Reply-To: andrew.cagney@gmail.com
To: gnats-bugs@NetBSD.org
Subject: gmake: *** INTERNAL: readdir: Operation not supported. Stop.
X-Send-Pr-Version: www-1.0
>Number: 57145
>Notify-List: riastradh@NetBSD.org
>Category: kern
>Synopsis: gmake: *** INTERNAL: readdir: Operation not supported. Stop.
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: mrg
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Thu Dec 29 05:35:01 +0000 2022
>Closed-Date:
>Last-Modified: Sun Nov 09 18:45:01 +0000 2025
>Originator: Andrew Cagney
>Release: 10-BETA
>Organization:
>Environment:
etBSD netbsd 10.0_BETA NetBSD 10.0_BETA (GENERIC) #0: Mon Dec 26 11:25:01 UTC 2022
>Description:
A test framework running NetBSD 10 in a VM gets this reproducible behaviour:
kvmsh w.netbsd 27.09: we're in after 0.1 seconds!
kvmsh w.netbsd 28.00: 'cd' to /source
[root@netbsd source]# time gmake install-base -j4
gmake: *** INTERNAL: readdir: Operation not supported. Stop.
>How-To-Repeat:
filling in the details:
- the VM, running on a Linux host, was built using:
sudo virt-install \
--connect=qemu:///system --check=path_in_use=off --graphics=none --virt-type=kvm --noreboot --console=pty,target_type=serial --cpu=host-passthrough --network=network:swandefault,model=virtio --rng=type=random,device=/dev/random --security=type=static,model=dac,label='1000:107',relabel=yes \
--vcpus=3 \
--memory=2560 \
--filesystem=target=bench,type=mount,accessmode=squash,source=/home/libreswan/wip-webkvm \
--filesystem=target=pool,type=mount,accessmode=squash,source=/home/pool \
--filesystem=target=source,type=mount,accessmode=squash,source=/home/libreswan/wip-webkvm \
--filesystem=target=testing,type=mount,accessmode=squash,source=/home/libreswan/wip-webkvm/testing \
--name=w.netbsd \
--os-variant=netbsd9.0 \
--disk=cache=writeback,path=/home/pool/w.netbsd.qcow2 \
--import \
--noautoconsole
- the i386 NetBSD guest is using automount to -noauto fstab entries:
[root@netbsd source]# cat /etc/fstab
ROOT.a / ffs rw,noatime 1 1
kernfs /kern kernfs rw
ptyfs /dev/pts ptyfs rw
procfs /proc procfs rw
tmpfs /var/shm tmpfs rw,-m1777,-sram%25
tmpfs /tmp tmpfs rw
192.168.234.1:/home/libreswan/wip-webkvm /source nfs rw,noauto
192.168.234.1:/home/libreswan/wip-webkvm/testing /testing nfs rw,noauto
- the VM is cold booted
- on login nothing is nfs mounted
- cd /source - triggering mount of /source
- time gmake install-base -j4 - triggering above error
Presumably there's some sort of race. Re-entering the make works fine.
>Fix:
>Release-Note:
>Audit-Trail:
From: Thomas Klausner <wiz@NetBSD.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/57145: gmake: *** INTERNAL: readdir: Operation not
supported. Stop.
Date: Thu, 29 Dec 2022 08:40:12 +0100
On Thu, Dec 29, 2022 at 05:35:01AM +0000, andrew.cagney@gmail.com wrote:
> >Number: 57145
> >Category: kern
> >Synopsis: gmake: *** INTERNAL: readdir: Operation not supported. Stop.
I saw this too when building emacs28 once:
ELC profiler.elc
gmake[3]: *** INTERNAL: readdir: Invalid argument. Stop.
gmake[3]: *** Waiting for unfinished jobs....
ELC ps-bdf.elc
The next build was successful again.
Thomas
From: Andrew Cagney <andrew.cagney@gmail.com>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: kern/57145: gmake: *** INTERNAL: readdir: Operation not
supported. Stop.
Date: Thu, 29 Dec 2022 10:27:40 -0500
`touch` also has problems vis:
Unhappy:
# set -x ; touch /source/. ; cd /source ; touch /source/. ; time gmake
install-base -j4
+ touch /source/.
touch: /source/.: Operation not supported
+ cd /source
+ touch /source/.
touch: /source/.: Operation not supported
+ gmake install-base -j4
gmake: *** INTERNAL: readdir: Operation not supported. Stop.
Happy:
# set -x ; ls /source/. ; cd /source ; touch /source/. ; time gmake
install-base -j4
+ ls /source/.
.git ...
+ cd /source
+ touch /source/.
+ gmake install-base -j4
...
On Thu, 29 Dec 2022 at 02:45, Thomas Klausner <wiz@netbsd.org> wrote:
>
> The following reply was made to PR kern/57145; it has been noted by GNATS.
>
> From: Thomas Klausner <wiz@NetBSD.org>
> To: gnats-bugs@netbsd.org
> Cc:
> Subject: Re: kern/57145: gmake: *** INTERNAL: readdir: Operation not
> supported. Stop.
> Date: Thu, 29 Dec 2022 08:40:12 +0100
>
> On Thu, Dec 29, 2022 at 05:35:01AM +0000, andrew.cagney@gmail.com wrote:
> > >Number: 57145
> > >Category: kern
> > >Synopsis: gmake: *** INTERNAL: readdir: Operation not supported. Stop.
>
> I saw this too when building emacs28 once:
>
> ELC profiler.elc
> gmake[3]: *** INTERNAL: readdir: Invalid argument. Stop.
> gmake[3]: *** Waiting for unfinished jobs....
> ELC ps-bdf.elc
>
> The next build was successful again.
> Thomas
>
From: Andrew Cagney <andrew.cagney@gmail.com>
To: kern-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/57145: gmake: *** INTERNAL: readdir: Operation not
supported. Stop.
Date: Thu, 29 Dec 2022 11:11:31 -0500
The code is doing:
open(".")
lseek(here) -> fails with not supported; should succeed
read(...)
lseek(here) -> fails with not supported; should fail with invalid
bad:
1371 1371 gmake CALL __stat50(0x499426,0xbfb07448)
1371 1371 gmake NAMI "."
1371 1371 gmake RET __stat50 0
1371 1371 gmake CALL open(0x499426,0x600004,0xf0)
1371 1371 gmake NAMI "."
1371 1371 gmake RET open 3
1371 1371 gmake CALL __fstatvfs190(3,0xbfb066c0,2)
1371 1371 gmake RET __fstatvfs190 0
1371 1371 gmake CALL lseek(3,0,0,0,1)
1371 1371 gmake RET lseek -1 errno 45 Operation not supported
1371 1371 gmake CALL __getdents30(3,0xbaa98000,0x1000)
1371 1371 gmake GIO fd 3 read 2048 bytes
....
1371 1371 gmake RET __getdents30 2048/0x800
1371 1371 gmake CALL lseek(3,0,0,0,1)
1371 1371 gmake RET lseek -1 errno 45 Operation not supported
1371 1371 gmake CALL __getdents30(3,0xbaa98000,0x1000)
1371 1371 gmake GIO fd 3 read 0 bytes
""
1371 1371 gmake RET __getdents30 0
Good:
1487 1487 gmake CALL __stat50(0xf7a426,0xbfb9d0dc)
1487 1487 gmake NAMI "."
1487 1487 gmake RET __stat50 0
1487 1487 gmake CALL open(0xf7a426,0x600004,0xf0)
1487 1487 gmake NAMI "."
1487 1487 gmake RET open 3
1487 1487 gmake CALL __fstatvfs190(3,0xbfb9c354,2)
1487 1487 gmake RET __fstatvfs190 0
1487 1487 gmake CALL lseek(3,0,0,0,1)
1487 1487 gmake RET lseek 0
1487 1487 gmake CALL __getdents30(3,0xbb185000,0x1000)
1487 1487 gmake GIO fd 3 read 2048 bytes
...
1487 1487 gmake RET __getdents30 2048/0x800
1487 1487 gmake CALL lseek(3,0,0,0,1)
1487 1487 gmake RET lseek -1 errno 22 Invalid argument
1487 1487 gmake CALL __getdents30(3,0xbb185800,0x800)
1487 1487 gmake GIO fd 3 read 0 bytes
""
1487 1487 gmake RET __getdents30 0
1487 1487 gmake CALL close(3)
From: Andrew Cagney <andrew.cagney@gmail.com>
To: kern-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/57145: gmake: *** INTERNAL: readdir: Operation not
supported. Stop.
Date: Thu, 29 Dec 2022 11:23:08 -0500
LS has the same problem, I guess it just ignores it:
first invocation is bad:
1247 1247 ls CALL open(0xae776000,0x600004,0xae771060)
1247 1247 ls NAMI "."
1247 1247 ls RET open 5
1247 1247 ls CALL __fstatvfs190(5,0xbfba9f48,2)
1247 1247 ls RET __fstatvfs190 0
...
1247 1247 ls CALL lseek(5,0,0,0,1)
1247 1247 ls RET lseek -1 errno 45 Operation not supported
1247 1247 ls CALL __getdents30(5,0xae770000,0x1000)
...
1247 1247 ls CALL lseek(5,0,0,0,1)
1247 1247 ls RET lseek -1 errno 45 Operation not supported
but second is good:
1328 1328 ls CALL open(0xabce7000,0x600004,0xabce2060)
1328 1328 ls NAMI "."
1328 1328 ls RET open 5
...
1328 1328 ls CALL lseek(5,0,0,0,1)
1328 1328 ls RET lseek 0
...
1328 1328 ls CALL lseek(5,0,0,0,1)
1328 1328 ls RET lseek -1 errno 22 Invalid argument
From: mlelstv@serpens.de (Michael van Elst)
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/57145: gmake: *** INTERNAL: readdir: Operation not supported. Stop.
Date: Thu, 29 Dec 2022 16:50:12 -0000 (UTC)
andrew.cagney@gmail.com (Andrew Cagney) writes:
>+ touch /source/.
>touch: /source/.: Operation not supported
That's probably an autofs artefact. touch (or a stat) on the mount point
doesn't trigger the mount operation and autofs itself does not support
most things.
When the filesystem got mounted by some other access, the touch operation
succeeds because its working on the mounted filesystem, not the autofs
mount point.
From: Andrew Cagney <andrew.cagney@gmail.com>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: kern/57145: gmake: *** INTERNAL: readdir: Operation not
supported. Stop.
Date: Thu, 29 Dec 2022 12:03:56 -0500
On Thu, 29 Dec 2022 at 11:55, Michael van Elst <mlelstv@serpens.de> wrote:
> >+ touch /source/.
> >touch: /source/.: Operation not supported
>
> That's probably an autofs artefact. touch (or a stat) on the mount point
> doesn't trigger the mount operation and autofs itself does not support
> most things.
>
> When the filesystem got mounted by some other access, the touch operation
> succeeds because its working on the mounted filesystem, not the autofs
> mount point.
yes, I figured that out while testing the same thing on FreeBSD
Per my follow-up the problem is with lseek()
Responsible-Changed-From-To: kern-bug-people->mrg
Responsible-Changed-By: mrg@NetBSD.org
Responsible-Changed-When: Tue, 20 Aug 2024 07:03:34 +0000
Responsible-Changed-Why:
this is a gmake bug. it checks errno after readdir() but readdir() is
not expected to set/clear errno for 'end of dir' condition, and thus
converts some prior random error into a readdir error.
State-Changed-From-To: open->feedback
State-Changed-By: mrg@NetBSD.org
State-Changed-When: Tue, 20 Aug 2024 07:09:21 +0000
State-Changed-Why:
i checked in a fix for gmake. pkgsrc gmake 4.4.1nb1 should work now.
State-Changed-From-To: feedback->open
State-Changed-By: mrg@NetBSD.org
State-Changed-When: Fri, 30 Aug 2024 21:52:34 +0000
State-Changed-Why:
my fix didn't do anything, but i've come to the conclusion that Andrew
is right about lseek() being the problem.
we store lseek() into dirp->dd_seek for later usage, and in the case
that it returns -1 and sets errno (this PR shows EOPNOTSUPP but most
instances i've and others have seen is EINVAL - mine happens on pure
FFS obj, not in a chroot.) we don't check this value in readdir()
so if it happens, it would explain how this issue happens. the other
case is that if getdents() returns 0 or negative and errno is set when
returning NULL.
From: Taylor R Campbell <riastradh@NetBSD.org>
To: matthew green <mrg@NetBSD.org>
Cc: Andrew Cagney <andrew.cagney@gmail.com>,
gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: pkg/57145: gmake: *** INTERNAL: readdir: Operation not supported. Stop.
Date: Sun, 1 Sep 2024 15:36:05 +0000
This is a multi-part message in MIME format.
--=_UO/DuVWULAgwAF6z8mwyycn6j85jhood
Content-Transfer-Encoding: quoted-printable
> Date: Tue, 20 Aug 2024 07:03:34 +0000
> From: mrg@NetBSD.org
>=20
> this is a gmake bug. it checks errno after readdir() but readdir() is
> not expected to set/clear errno for 'end of dir' condition, and thus
> converts some prior random error into a readdir error.
Not a gmake bug. readdir is required to preserve errno in the
end-of-directory case:
DESCRIPTION
[...]
Applications wishing to check for error situations should set errno
to 0 before calling readdir(). If errno is set to non-zero on
return, an error occurred.
RETURN VALUE
[...] When the end of the directory is encountered, a null pointer
shall be returned and errno is not changed.
POSIX 2024: https://pubs.opengroup.org/onlinepubs/9799919799.2024edition/fu=
nctions/readdir.html
SUSv2 1997: https://pubs.opengroup.org/onlinepubs/7908799/xsh/readdir.html
It's been this way for decades and we just screwed it up in the event
that lseek fails.
The attached patch arranges to preserve errno in the end-of-directory
case (and in the success case), and to set errno in error cases.
However, I would like to add an automatic test for this.
> Date: Fri, 30 Aug 2024 21:52:34 +0000
> From: mrg@NetBSD.org
>=20
> we store lseek() into dirp->dd_seek for later usage, and in the case
> that it returns -1 and sets errno (this PR shows EOPNOTSUPP but most
> instances i've and others have seen is EINVAL - mine happens on pure
> FFS obj, not in a chroot.)
Can you share your reproducer for this? Maybe we can adapt it to an
atf test.
--=_UO/DuVWULAgwAF6z8mwyycn6j85jhood
Content-Type: text/plain; charset="ISO-8859-1"; name="pr57145-readdirerrno-v6"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="pr57145-readdirerrno-v6.patch"
# HG changeset patch
# User Taylor R Campbell <riastradh@NetBSD.org>
# Date 1725116374 0
# Sat Aug 31 14:59:34 2024 +0000
# Branch trunk
# Node ID f39f4bb8989435150b682bb087c507f41adcaf8d
# Parent 9aaaa3422f6c6a29e9679ebd97936a4038ca0060
# EXP-Topic riastradh-pr57145-readdirerrno
readdir(3): Preserve errno on end-of-directory.
PR pkg/57145: gmake: *** INTERNAL: readdir: Operation not supported.
Stop.
diff -r 9aaaa3422f6c -r f39f4bb89894 lib/libc/gen/readdir.c
--- a/lib/libc/gen/readdir.c Thu Aug 29 13:39:42 2024 +0000
+++ b/lib/libc/gen/readdir.c Sat Aug 31 14:59:34 2024 +0000
@@ -56,35 +56,50 @@ static char sccsid[] =3D "@(#)readdir.c 8.
struct dirent *
_readdir_unlocked(DIR *dirp, int skipdeleted)
{
+ const int saved_errno =3D errno;
struct dirent *dp;
=20
for (;;) {
if (dirp->dd_loc >=3D dirp->dd_size) {
if (dirp->dd_flags & __DTF_READALL)
- return (NULL);
+ break;
dirp->dd_loc =3D 0;
}
if (dirp->dd_loc =3D=3D 0 && !(dirp->dd_flags & __DTF_READALL)) {
dirp->dd_seek =3D lseek(dirp->dd_fd, (off_t)0, SEEK_CUR);
dirp->dd_size =3D getdents(dirp->dd_fd,
dirp->dd_buf, (size_t)dirp->dd_len);
- if (dirp->dd_size <=3D 0)
- return (NULL);
+ if (dirp->dd_size =3D=3D 0) /* end of directory */
+ break;
+ if (dirp->dd_size =3D=3D -1) /* getdents sets errno */
+ return NULL;
+ if (dirp->dd_size < 0) { /* paranoia */
+ errno =3D EIO;
+ return NULL;
+ }
}
dp =3D (struct dirent *)
(void *)(dirp->dd_buf + (size_t)dirp->dd_loc);
- if ((intptr_t)dp & _DIRENT_ALIGN(dp))/* bogus pointer check */
- return (NULL);
+ /* bogus pointer check */
+ if ((intptr_t)dp & _DIRENT_ALIGN(dp)) {
+ errno =3D EIO;
+ return NULL;
+ }
/* d_reclen is unsigned; no need to compare it <=3D 0 */
- if (dp->d_reclen > dirp->dd_len + 1 - dirp->dd_loc)
- return (NULL);
+ if (dp->d_reclen > dirp->dd_len + 1 - dirp->dd_loc) {
+ errno =3D EIO;
+ return NULL;
+ }
dirp->dd_loc +=3D dp->d_reclen;
if (dp->d_ino =3D=3D 0 && skipdeleted)
continue;
if (dp->d_type =3D=3D DT_WHT && (dirp->dd_flags & DTF_HIDEW))
continue;
- return (dp);
+ return dp;
}
+
+ errno =3D saved_errno;
+ return NULL;
}
=20
struct dirent *
--=_UO/DuVWULAgwAF6z8mwyycn6j85jhood--
From: matthew green <mrg@eterna23.net>
To: Taylor R Campbell <riastradh@NetBSD.org>
Cc: Andrew Cagney <andrew.cagney@gmail.com>, gnats-bugs@NetBSD.org,
netbsd-bugs@NetBSD.org
Subject: re: pkg/57145: gmake: *** INTERNAL: readdir: Operation not supported. Stop.
Date: Mon, 02 Sep 2024 04:47:40 +1000
> > this is a gmake bug. it checks errno after readdir() but readdir() is
> > not expected to set/clear errno for 'end of dir' condition, and thus
> > converts some prior random error into a readdir error.
>
> Not a gmake bug. readdir is required to preserve errno in the
yes - the call in gmake always sets errno = 0 before calling
readdir, but it's via a macro and i missed this.
i *thought* the bug was not setting errno = 0 before.
> Can you share your reproducer for this? Maybe we can adapt it to an
> atf test.
"use pkgsrc, see this failure every few weeks or so".
.mrg.
From: Andrew Cagney <andrew.cagney@gmail.com>
To: gnats-bugs@netbsd.org
Cc: mrg@netbsd.org, gnats-admin@netbsd.org, pkgsrc-bugs@netbsd.org
Subject: Re: pkg/57145: gmake: *** INTERNAL: readdir: Operation not supported. Stop.
Date: Sun, 1 Sep 2024 16:19:23 -0400
> > Can you share your reproducer for this? Maybe we can adapt it to an
> > atf test.
probably
- set up a automounted NFS filesystem on /mnt/broken, say
- execute
chdir(/mnt/broken)
fd = open(".")
lseek(fd, 0,0,0/*,1?!?*/; /* 45 Operation not supported */
but I'm assuming this is a kernel problem (after the lseek() comes the
getdents()). I'll play with it in a few days.
From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: pkg/57145: gmake: *** INTERNAL: readdir: Operation not
supported. Stop.
Date: Mon, 2 Sep 2024 05:17:49 +0000
On Sun, Sep 01, 2024 at 03:40:01PM +0000, gnats-admin@netbsd.org wrote:
> Not a gmake bug.
I've moved this back to kern.
--
David A. Holland
dholland@netbsd.org
From: Taylor R Campbell <riastradh@NetBSD.org>
To: matthew green <mrg@eterna23.net>
Cc: Andrew Cagney <andrew.cagney@gmail.com>,
gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: pkg/57145: gmake: *** INTERNAL: readdir: Operation not supported. Stop.
Date: Mon, 2 Sep 2024 19:27:15 +0000
> Date: Mon, 02 Sep 2024 04:47:40 +1000
> from: matthew green <mrg@eterna23.net>
>
> > Can you share your reproducer for this? Maybe we can adapt it to an
> > atf test.
>
> "use pkgsrc, see this failure every few weeks or so".
This is very mysterious. I can't find any paths by which to explain
these results:
1371 1371 gmake CALL open(0x499426,0x600004,0xf0)
1371 1371 gmake NAMI "."
1371 1371 gmake RET open 3
1371 1371 gmake CALL __fstatvfs190(3,0xbfb066c0,2)
1371 1371 gmake RET __fstatvfs190 0
1371 1371 gmake CALL lseek(3,0,0,0,1)
1371 1371 gmake RET lseek -1 errno 45 Operation not supported
Or:
1487 1487 gmake CALL open(0xf7a426,0x600004,0xf0)
1487 1487 gmake NAMI "."
1487 1487 gmake RET open 3
1487 1487 gmake CALL __fstatvfs190(3,0xbfb9c354,2)
1487 1487 gmake RET __fstatvfs190 0
1487 1487 gmake CALL lseek(3,0,0,0,1)
1487 1487 gmake RET lseek 0
...
1487 1487 gmake CALL lseek(3,0,0,0,1)
1487 1487 gmake RET lseek -1 errno 22 Invalid argument
If I understand correctly, the funny ktrace output `lseek(3,0,0,0,1)'
means
fd=3
pad=0
offlo=0
offhi=0
whence=1
or, in other words, it means the function call:
lseek(/*fd*/3, /*off*/0, /*whence*/SEEK_CUR).
Somehow, that is returning EOPNOTSUPP or EINVAL. But:
- sys_lseek can return EBADF, ESPIPE, or whatever .fo_seek returns.
- When fd 3 is the result of open("."), I think it is guaranteed that
its underlying file's .fo_seek function is always vn_seek. So it
can return whatever vn_seek can return.
- vn_seek can return ESPIPE, whatever VOP_GETATTR returns, whatever
VOP_SEEK returns, or EINVAL -- but EINVAL is only for values of
whence other than SEEK_CUR/END/SET, so that can't be where EINVAL is
coming from.
- ufs_getattr and tmpfs_getattr always unconditionally return 0.
(nfs_getattr may fail, but mrg@ said this happens on ffs without any
nfs involved.)
- VOP_SEEK is genfs_seek on essentially all file systems, and it only
returns EINVAL if the new offset is negative, but this new offset is
zero, so that can't be where EINVAL is coming from. (Note: It does
not return EINVAL if the new offset exceeds the current size.)
That exhausts all possible error codes I can find from lseek(2) on the
result of open(".") on ffs or tmpfs.
So where is EINVAL or EOPNOTSUPP coming from?
From: Thomas Klausner <wiz@NetBSD.org>
To: Taylor R Campbell <riastradh@NetBSD.org>
Cc: NetBSD bugtracking <gnats-bugs@NetBSD.org>
Subject: Re: pkg/57145: gmake: *** INTERNAL: readdir: Operation not
supported. Stop.
Date: Sat, 7 Sep 2024 09:53:36 +0200
Here's a recent example:
http://www.ki.nu/pkgsrc/reports/current/NetBSD-9.0/20240904.2259/emacs27-27.2nb32/build.log
ELC tree-widget.elc
gmake[3]: *** readdir .: Invalid argument. Stop.
gmake[3]: *** Waiting for unfinished jobs....
ELC tutorial.elc
gmake[3]: Leaving directory '/tmp/editors/emacs27/work/emacs-27.2/lisp'
Thomas
From: Andrew Cagney <andrew.cagney@gmail.com>
To: gnats-bugs@netbsd.org
Cc: mrg@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: pkg/57145: gmake: *** INTERNAL: readdir: Operation not supported. Stop.
Date: Sat, 7 Sep 2024 14:56:51 -0400
This is after a reboot, /source and /testing are automounted.
[root@netbsd ~]# cd /source
[root@netbsd source]# df
Filesystem 512-blocks Used Avail %Cap Mounted on
/dev/wd0a 20643484 4176144 15435168 21% /
kernfs 2 2 0 100% /kern
ptyfs 2 2 0 100% /dev/pts
procfs 8 8 0 100% /proc
tmpfs 1048312 0 1048312 0% /var/shm
tmpfs 3897616 8 3897608 0% /tmp
map -noauto 0 0 0 100% /source
map -noauto 0 0 0 100% /testing
[root@netbsd source]# mount
/dev/wd0a on / type ffs (noatime, local)
kernfs on /kern type kernfs (local)
ptyfs on /dev/pts type ptyfs (local)
procfs on /proc type procfs (local)
tmpfs on /var/shm type tmpfs (local)
tmpfs on /tmp type tmpfs (local)
map -noauto on /source type autofs
map -noauto on /testing type autofs
Note that the mount of /source hasn't yet triggered. Now what I
believe is the test case:
[root@netbsd source]# cc open-lseek.c
[root@netbsd source]# ./a.out
missing mount-point[root@netbsd source 1]# ./a.out /testing
chdir(/testing)
flags 600004 vs 600004
mode f0 vs f0
open(.,600004,f0)
lseek(3, 0, SEEK_CUR)
lseek: Operation not supported
for comparison:
[root@freebsd source]# cc open-lseek.c
[root@freebsd source]# ./a.out
missing mount-point[root@freebsd source 1]# ./a.out /testing
chdir(/testing)
flags 120004 vs 120004
mode f0 vs f0
open(.,120004,f0)
lseek(3, 0, SEEK_CUR)
[root@freebsd source]# df
Filesystem 1K-blocks Used
Avail Capacity Mounted on
/dev/vtbd0s1a 9638812 5610152
3257556 63% /
devfs 1 0
1 0% /dev
map -noauto 0 0
0 100% /source
map -noauto 0 0
0 100% /testing
192.168.234.1:/home/libreswan/mainline 960302096 886320800
25126872 97% /source
192.168.234.1:/home/libreswan/mainline/testing 960302096 886320800
25126872 97% /testing
and the code:
#include <stdio.h>
#include <stdlib.h> /* for exit() */
#include <fcntl.h>
#include <errno.h>
#include <unistd.h>
#include <sys/stat.h>
#include <sys/param.h>
#include <sys/mount.h>
static void barf(const char *what)
{
perror(what);
exit(1);
}
static unsigned flags(const char *what, unsigned actual, unsigned expected)
{
printf("%s %x vs %x\n", what, actual, expected);
return expected;
}
int main(int argc, char *argv[])
{
if (argc < 2) {
fprintf(stderr, "missing mount-point");
exit(1);
}
const char *mount = argv[1];
printf("chdir(%s)\n", mount);
chdir(mount);
if (errno > 0) {
barf("chdir");
}
unsigned open_flags = flags("flags", O_DIRECTORY|O_CLOEXEC|O_NONBLOCK,
O_DIRECTORY|O_CLOEXEC|O_NONBLOCK);
unsigned open_mode = flags("mode", S_IWUSR|S_IXUSR|S_IRGRP|S_IWGRP, 0xf0);
printf("open(%s,%x,%x)\n", ".", open_flags, open_mode);
int fd = open(".", open_flags, open_mode);
if (errno > 0) {
barf("open");
}
printf("lseek(%d, 0, SEEK_CUR)\n", fd);
lseek(fd, /*offset*/0, /*wence*/SEEK_CUR);
if (errno > 0) {
barf("lseek");
}
exit(0);
}
From: mlelstv@serpens.de (Michael van Elst)
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: pkg/57145: gmake: *** INTERNAL: readdir: Operation not supported. Stop.
Date: Sat, 7 Sep 2024 19:59:24 -0000 (UTC)
gnats-admin@NetBSD.org (" Andrew Cagney via gnats") writes:
> [root@netbsd source]# cc open-lseek.c
> [root@netbsd source]# ./a.out
> missing mount-point[root@netbsd source 1]# ./a.out /testing
> chdir(/testing)
> flags 600004 vs 600004
> mode f0 vs f0
> open(.,600004,f0)
> lseek(3, 0, SEEK_CUR)
> lseek: Operation not supported
That's autofs that does implement readdir() but not lseek().
The result is the 'Operation not supported' error (instead of
something like EISDIR).
From: Taylor R Campbell <riastradh@NetBSD.org>
To: Thomas Klausner <wiz@NetBSD.org>
Cc: gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: pkg/57145: gmake: *** INTERNAL: readdir: Operation not
supported. Stop.
Date: Tue, 10 Sep 2024 16:04:58 +0000
It looks like the EOPNOTSUPP is explained by autofs's lack of lseek.
I'm still unclear on the EINVAL. My best guess is that:
1. somehow, fp->f_offset gets set to something negative
2. sys_lseek -> vn_seek -> VOP_SEEK -> genfs_seek fails with EINVAL
I can't find a way for (1) to happen on ufs or tmpfs, but maybe it
could happen with nfs -- reviewing that code is a lot of work.
One path that crossed my mind is a race in readdir by multiple threads
or processes on the same file object, which might have been fixed by
<https://mail-index.netbsd.org/source-changes/2023/04/22/msg144249.html>
(which has not been pulled up to netbsd-9), but I doubt that's
happening here.
So I'll go ahead and commit the readdir(3) fix, but I'm still
suspicious of EINVAL. It would be worthwhile to try to instrument
this and reproduce it to find out where it's coming from, in case
there's another bug lurking.
From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/57145 CVS commit: src/lib/libc/gen
Date: Tue, 10 Sep 2024 17:11:19 +0000
Module Name: src
Committed By: riastradh
Date: Tue Sep 10 17:11:19 UTC 2024
Modified Files:
src/lib/libc/gen: readdir.c
Log Message:
readdir(3): Preserve errno on end-of-directory.
PR pkg/57145: gmake: *** INTERNAL: readdir: Operation not supported.
Stop.
To generate a diff of this commit:
cvs rdiff -u -r1.26 -r1.27 src/lib/libc/gen/readdir.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: open->needs-pullups
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Tue, 10 Sep 2024 18:22:38 +0000
State-Changed-Why:
fixed in HEAD, needs pullup-10 and pullup-9
From: Andrew Cagney <andrew.cagney@gmail.com>
To: gnats-bugs@netbsd.org
Cc: mrg@netbsd.org, netbsd-bugs@netbsd.org, gnats-admin@netbsd.org,
riastradh@netbsd.org
Subject: Re: kern/57145 (gmake: *** INTERNAL: readdir: Operation not
supported. Stop.)
Date: Tue, 10 Sep 2024 14:27:35 -0400
I suspect this bug needs to be split.
autofs still doesn't support lseek()
On Tue, 10 Sept 2024 at 14:22, <riastradh@netbsd.org> wrote:
>
> Synopsis: gmake: *** INTERNAL: readdir: Operation not supported. Stop.
>
> State-Changed-From-To: open->needs-pullups
> State-Changed-By: riastradh@NetBSD.org
> State-Changed-When: Tue, 10 Sep 2024 18:22:38 +0000
> State-Changed-Why:
> fixed in HEAD, needs pullup-10 and pullup-9
>
>
>
From: Thomas Klausner <wiz@NetBSD.org>
To: Taylor R Campbell <riastradh@NetBSD.org>
Cc: gnats-bugs@NetBSD.org
Subject: Re: pkg/57145: gmake: *** INTERNAL: readdir: Operation not
supported. Stop.
Date: Tue, 10 Sep 2024 20:58:38 +0200
On Tue, Sep 10, 2024 at 04:04:58PM +0000, Taylor R Campbell wrote:
> It looks like the EOPNOTSUPP is explained by autofs's lack of lseek.
>
> I'm still unclear on the EINVAL. My best guess is that:
>
> 1. somehow, fp->f_offset gets set to something negative
> 2. sys_lseek -> vn_seek -> VOP_SEEK -> genfs_seek fails with EINVAL
>
> I can't find a way for (1) to happen on ufs or tmpfs, but maybe it
> could happen with nfs -- reviewing that code is a lot of work.
>
> One path that crossed my mind is a race in readdir by multiple threads
> or processes on the same file object, which might have been fixed by
> <https://mail-index.netbsd.org/source-changes/2023/04/22/msg144249.html>
> (which has not been pulled up to netbsd-9), but I doubt that's
> happening here.
To clarify - I saw this yesterday in wip/emacs-git:
gmake[3]: *** readdir .: Invalid argument. Stop.
gmake[3]: *** Waiting for unfinished jobs....
gmake[3]: Leaving directory '/scratch/wip/emacs-git/work/emacs/leim'
on 10.99.12/amd64 from Aug 28, so it's not fixed in HEAD yet.
I'm not using nfs in this setup, but a standard 'mksandbox' chroot.
tmpfs on /archive/sandboxes/client1 type tmpfs (local)
ptyfs on /archive/sandboxes/client1/dev/ptyfs type ptyfs (local)
procfs on /archive/sandboxes/client1/proc type procfs (local)
/bin on /archive/sandboxes/client1/bin type null (read-only, local)
/sbin on /archive/sandboxes/client1/sbin type null (read-only, local)
/lib on /archive/sandboxes/client1/lib type null (read-only, local)
/libexec on /archive/sandboxes/client1/libexec type null (read-only, local)
/usr/bin on /archive/sandboxes/client1/usr/bin type null (read-only, local)
/usr/games on /archive/sandboxes/client1/usr/games type null (read-only, local)
/usr/include on /archive/sandboxes/client1/usr/include type null (read-only, local)
/usr/lib on /archive/sandboxes/client1/usr/lib type null (read-only, local)
/usr/libdata on /archive/sandboxes/client1/usr/libdata type null (read-only, local)
/usr/libexec on /archive/sandboxes/client1/usr/libexec type null (read-only, local)
/usr/share on /archive/sandboxes/client1/usr/share type null (read-only, local)
/usr/sbin on /archive/sandboxes/client1/usr/sbin type null (read-only, local)
/usr/X11R7 on /archive/sandboxes/client1/usr/X11R7 type null (read-only, local)
/var/mail on /archive/sandboxes/client1/var/mail type null (read-only, local)
/usr/src on /archive/sandboxes/client1/usr/src type null (read-only, local)
/usr/pkgsrc on /archive/sandboxes/client1/usr/pkgsrc type null (local)
/usr/xsrc on /archive/sandboxes/client1/usr/xsrc type null (read-only, local)
/packages on /archive/sandboxes/client1/packages type null (local)
/distfiles on /archive/sandboxes/client1/distfiles type null (local)
Thomas
From: Taylor R Campbell <riastradh@NetBSD.org>
To: Thomas Klausner <wiz@NetBSD.org>
Cc: gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: pkg/57145: gmake: *** INTERNAL: readdir: Operation not
supported. Stop.
Date: Tue, 10 Sep 2024 23:56:36 +0000
> Date: Tue, 10 Sep 2024 20:58:38 +0200
> From: Thomas Klausner <wiz@NetBSD.org>
>
> On Tue, Sep 10, 2024 at 04:04:58PM +0000, Taylor R Campbell wrote:
> > One path that crossed my mind is a race in readdir by multiple threads
> > or processes on the same file object, which might have been fixed by
> > <https://mail-index.netbsd.org/source-changes/2023/04/22/msg144249.html>
> > (which has not been pulled up to netbsd-9), but I doubt that's
> > happening here.
>
> To clarify - I saw this yesterday in wip/emacs-git:
>
> gmake[3]: *** readdir .: Invalid argument. Stop.
> gmake[3]: *** Waiting for unfinished jobs....
> gmake[3]: Leaving directory '/scratch/wip/emacs-git/work/emacs/leim'
>
> on 10.99.12/amd64 from Aug 28, so it's not fixed in HEAD yet.
Great, that rules out that hypothesis!
It looks like emacs28 is a candidate for a reproducer. How frequently
does this reproduce? Can you run `gmake -jN clean && gmake -jN' in a
loop in the build tree to trigger it (for whatever N is appropriate)?
Might be worth running this concurrently:
dtrace -n '
fbt::VOP_SEEK:entry {
self->vp = arg0;
self->oldoff = arg1;
self->newoff = arg2;
}
fbt::VOP_SEEK:return /arg1 == 22/ {
printf("vp=%p oldoff=%d newoff=%d", self->vp,
self->oldoff, self->newoff);
print(*(struct vnode_impl *)self->vp);
@[stack()] = count();
}
fbt::VOP_SEEK:return {
self->vp = self->oldoff = self->newoff = 0
}
'
and hit ^C when it reproduces to get the stack trace output (which
will probably just show sys_lseek -> vn_seek -> VOP_SEEK, but let's
make sure it's not also nested in layerfs or something).
> I'm not using nfs in this setup, but a standard 'mksandbox' chroot.
>
> tmpfs on /archive/sandboxes/client1 type tmpfs (local)
> [...]
I don't see / or /scratch in your list of mounted file systems --
what's the file system that /scratch/wip/emacs-git/work/emacs/leim
lives on? Is this chrooted in /archive/sandboxes/client1 so the
answer is tmpfs?
From: matthew green <mrg@eterna23.net>
To: Taylor R Campbell <riastradh@NetBSD.org>
Cc: gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org,
Thomas Klausner <wiz@NetBSD.org>
Subject: re: pkg/57145: gmake: *** INTERNAL: readdir: Operation not supported. Stop.
Date: Thu, 12 Sep 2024 18:10:03 +1000
> I'm still unclear on the EINVAL. My best guess is that:
>
> 1. somehow, fp->f_offset gets set to something negative
> 2. sys_lseek -> vn_seek -> VOP_SEEK -> genfs_seek fails with EINVAL
>
> I can't find a way for (1) to happen on ufs or tmpfs, but maybe it
> could happen with nfs -- reviewing that code is a lot of work.
for my setup, this happens with local mounts. the pkg build dir
is a plain local ffs, and /usr/pkgsrc is a r/o nullfs mount of the
(different fs) local ffs r/w mount of pkgsrc.
ie, nfs isn't involved at all, and besides nullfs for pkgsrc itself,
the entire builddir is local ffs with no special options (no log,
UFS2, block/frag = 32k/4k, samsung 990 pro nvme.)
(i wonder if a type of build could be extra whiny about this and
give us all the info. for me, EINVAL happens *rarely*. i once tried
building something 500 times and it worked.)
.mrg.
From: Thomas Klausner <wiz@NetBSD.org>
To: NetBSD bugtracking <gnats-bugs@NetBSD.org>
Cc: Taylor R Campbell <riastradh@NetBSD.org>
Subject: Re: pkg/57145: gmake: *** INTERNAL: readdir: Operation not
supported. Stop.
Date: Tue, 17 Sep 2024 08:49:03 +0200
On Tue, Sep 10, 2024 at 11:56:36PM +0000, Taylor R Campbell wrote:
> dtrace -n '
> fbt::VOP_SEEK:entry {
> self->vp = arg0;
> self->oldoff = arg1;
> self->newoff = arg2;
> }
> fbt::VOP_SEEK:return /arg1 == 22/ {
> printf("vp=%p oldoff=%d newoff=%d", self->vp,
> self->oldoff, self->newoff);
> print(*(struct vnode_impl *)self->vp);
> @[stack()] = count();
> }
> fbt::VOP_SEEK:return {
> self->vp = self->oldoff = self->newoff = 0
> }
> '
>
> and hit ^C when it reproduces to get the stack trace output (which
> will probably just show sys_lseek -> vn_seek -> VOP_SEEK, but let's
> make sure it's not also nested in layerfs or something).
I tried this, but dtrace quite quickly reports:
...
dtrace: 4293 dynamic variable drops with non-empty dirty list
: Operation timed out
dtrace: 8511 dynamic variable drops with non-empty dirty list
: Operation timed out
dtrace: 12958 dynamic variable drops with non-empty dirty list
: Operation timed out
dtrace: 11577 dynamic variable drops with non-empty dirty list
: Operation timed out
...
(those keep coming) and Taylor told me that this means the dtrace might
have stopped working.
So I restarted it during a single emacs build, but before the build
was finished, these lines appeared again; so I'd have to keep
restarting dtrace all the time for a single build, and a single build
isn't even sure to reproduce this...
Thomas
State-Changed-From-To: needs-pullups->pending-pullups
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Tue, 08 Oct 2024 21:06:50 +0000
State-Changed-Why:
pullup-10 #935: https://releng.netbsd.org/cgi-bin/req-10.cgi?show=935
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/57145 CVS commit: [netbsd-10] src/lib/libc/gen
Date: Wed, 9 Oct 2024 11:19:21 +0000
Module Name: src
Committed By: martin
Date: Wed Oct 9 11:19:20 UTC 2024
Modified Files:
src/lib/libc/gen [netbsd-10]: readdir.c
Log Message:
Pull up following revision(s) (requested by riastradh in ticket #935):
lib/libc/gen/readdir.c: revision 1.27
readdir(3): Preserve errno on end-of-directory.
PR pkg/57145: gmake: *** INTERNAL: readdir: Operation not supported.
Stop.
To generate a diff of this commit:
cvs rdiff -u -r1.26 -r1.26.42.1 src/lib/libc/gen/readdir.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: pending-pullups->needs-pullups
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Wed, 09 Oct 2024 12:55:42 +0000
State-Changed-Why:
libc issue fixed in HEAD, pulled up to 10, still needs pullup-9
kernel issue remains open
State-Changed-From-To: needs-pullups->pending-pullups
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Fri, 11 Oct 2024 18:18:10 +0000
State-Changed-Why:
pullup-9 #1898 https://releng.netbsd.org/cgi-bin/req-9.cgi?show=1898
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/57145 CVS commit: [netbsd-9] src/lib/libc/gen
Date: Fri, 11 Oct 2024 18:42:26 +0000
Module Name: src
Committed By: martin
Date: Fri Oct 11 18:42:25 UTC 2024
Modified Files:
src/lib/libc/gen [netbsd-9]: readdir.c
Log Message:
Pull up following revision(s) (requested by riastradh in ticket #1898):
lib/libc/gen/readdir.c: revision 1.27
readdir(3): Preserve errno on end-of-directory.
PR pkg/57145: gmake: *** INTERNAL: readdir: Operation not supported.
Stop.
To generate a diff of this commit:
cvs rdiff -u -r1.26 -r1.26.34.1 src/lib/libc/gen/readdir.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: pending-pullups->open
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Fri, 11 Oct 2024 18:54:42 +0000
State-Changed-Why:
fixed in HEAD, pulled up to 9 and 10
kernel issue remains -- though maybe we should open a separate PR to
track why lseek sometimes fails inexplicably
From: Taylor R Campbell <riastradh@NetBSD.org>
To: gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org
Cc:
Subject: Re: kern/57145: gmake: *** INTERNAL: readdir: Operation not supported. Stop.
Date: Mon, 21 Oct 2024 12:50:05 +0000
Followup commit for pullup, not tagged with the PR:
https://mail-index.netbsd.org/source-changes/2024/10/20/msg154024.html
Module Name: src
Committed By: mlelstv
Date: Sun Oct 20 14:06:49 UTC 2024
Modified Files:
src/sys/fs/autofs: autofs_vnops.c
Log Message:
Handle seek operations on autofs mountpoints.
To generate a diff of this commit:
cvs rdiff -u -r1.8 -r1.9 src/sys/fs/autofs/autofs_vnops.c
From: Thomas Klausner <wiz@NetBSD.org>
To: NetBSD bugtracking <gnats-bugs@NetBSD.org>
Cc:
Subject: Re: pkg/57145: gmake: *** INTERNAL: readdir: Operation not
supported. Stop.
Date: Tue, 12 Nov 2024 16:51:58 +0100
I haven't seen this for a while, but today an emacs29 build triggered it:
ELC org/ob-haskell.elc
gmake[4]: *** readdir org: Invalid argument. Stop.
gmake[4]: *** Waiting for unfinished jobs....
gmake[4]: Leaving directory '/scratch/editors/emacs29/work/emacs-29.4/lisp'
So still here on NetBSD-current/amd64/10.99.12 from 20241109.
Thomas
From: matthew green <mrg@eterna23.net>
To: gnats-bugs@netbsd.org
Cc: riastradh@NetBSD.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
andrew.cagney@gmail.com
Subject: re: pkg/57145: gmake: *** INTERNAL: readdir: Operation not supported. Stop.
Date: Wed, 13 Nov 2024 08:26:30 +1100
i also saw this again recently in -10 branch from 2024-11-02.
From: Thomas Klausner <wiz@NetBSD.org>
To: NetBSD bugtracking <gnats-bugs@NetBSD.org>
Cc:
Subject: Re: pkg/57145: gmake: *** INTERNAL: readdir: Operation not
supported. Stop.
Date: Tue, 26 Nov 2024 09:14:57 +0100
Today I saw
ELC org/ob-latex.elc
gmake[3]: *** readdir org: Invalid argument. Stop.
gmake[3]: *** Waiting for unfinished jobs....
when building wip/emacs-git.
Slightly different error, and also to report on how often this happens.
Thomas
From: matthew green <mrg@eterna23.net>
To: riastradh@NetBSD.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
andrew.cagney@gmail.com, gnats-bugs@netbsd.org
Cc:
Subject: re: pkg/57145: gmake: *** INTERNAL: readdir: Operation not supported. Stop.
Date: Sun, 26 Oct 2025 15:45:44 +1100
*sigh*.
just saw this with today's -current on amd64.
on a new to me ryzen 7700x, which is the fastest core i've had.
.mrg.
From: Thomas Klausner <wiz@netbsd.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: pkg/57145: gmake: *** INTERNAL: readdir: Operation not
supported. Stop.
Date: Sun, 26 Oct 2025 21:04:52 +0100
Yes, I still see this happening from time to time too.
Thomas
From: "David H. Gutteridge" <david@gutteridge.ca>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: pkg/57145: gmake: *** INTERNAL: readdir: Operation not
supported. Stop.
Date: Sun, 09 Nov 2025 13:40:28 -0500
I've also just hit this, in my case with ten-year-old hardware, CPUs
being "Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz", running 11.99.3 from
late September, while doing a pkgsrc pbulk build with MAKE_JOBS=3D8. I
got the "gmake[1]: *** readdir .: Invalid argument. Stop." variant.
Dave
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.47 2022/09/11 19:34:41 kim Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2025
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home