Bug#1082747: cod-tools: FTBFS (only) on riscv64

[Aurelien Jarno]

control: reassign -1 make-dfsg
control: retitle -1 make-dfsg: directory cache not invalidated after invoking command
control: affects -1 cod-tools

On 2024-09-29 16:02, Aurelien Jarno wrote:
> Hi,
> 
> On 2024-09-29 02:10, Bernhard Übelacker wrote:
> > On Fri, 27 Sep 2024 19:25:10 +0200 Aurelien Jarno <aurelien at aurel32.net> wrote:
> > 
> > > TIL disorderfs. I have also been able to reproduce it with disorderfs.
> > > In addition knowing the root of the issue, I have been able to
> > > reproduce the issue on a riscv64 machine using tmpfs as a build
> > > directory, just like on the build daemons.
> > > 
> > > > Didn't have time to debug it further yet.
> > > > > Hope this helps,
> > > 
> > > Definitely, thanks a lot!
> > > 
> > 
> > 
> > Hello everyone,
> > I am also amazed, I did not know about disorderfs before.
> > 
> > I could reproduce the failure with rr-debugger on top of
> > a disorderfs and compared it with a successful run (both on amd64).
> > In the unsuccessful run the iteration through the
> > predicted readdir does not return the expected file [1].
> > 
> > So in the bad case readdir of directory src/components/codcif
> > does "just" not return the file "cif_list_tags" in my example
> > and at least for the disorderfs case.
> 
> Is it really the output from readdir when looking for that file, or a
> cache of it? Running make under strace seems to show it's a cache, as I
> do not see a call to the getdents64 syscall for that directory, although
> there are some for others:

This is definitely a cache issue in make, the following upstream commit
fixes the issue:

https://git.savannah.gnu.org/cgit/make.git/commit/?id=9e2fa24649b870d79e2582f46e851fb34daa4762

Regards
Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien at aurel32.net                     http://aurel32.net