Re: make check(s) pre-release problems

[Jan Engelhardt]

On Wednesday 2022-10-05 23:24, Karl Berry wrote:
>
>What troubles me most is that there's no obvious way to debug any test
>failure involving parallelism, since they go away with serial execution.
>Any ideas about how to determine what is going wrong in the parallel
>make?  Any way to make parallel failures more reproducible?

1. Throw more processes in the mix (make -jN with more-than-normal N)
   so that either
   - for each (single) process the "critical section" execution time goes up
   - for the whole job set, the total time spent in/around critical sections
     goes up

2. determine which exact (sub-)program and syscall failed in what process in
  what job (strace), then construct a hypothesis around that failure

3. watch if any one job is somehow executed twice, or a file is written to
   concurrently

   foo: foo.c foo.h
        ld -o foo ...
   foo.c foo.h:
        generate_from_somewhere

3b. or a file is read and written to concurrently

   %.o: %.c
     generate_version.h
     cc -o $@ $<

   foo: foo.o bar.o

(and foo.c, bar.c, nongenerated, have a #include "version.h")
I've seen something like that in libtracefs commit 
b64dc07ca44ccfed40eae8d345867fd938ce6e0e