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

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> Date: Tue, 10 Sep 2024 20:58:38 +0200
> From: Thomas Klausner <wiz%NetBSD.org@localhost>
> 
> 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?