Re: [PATCH 30/35] virshtest: Adapt 'virsh-read-bufsiz' and 'virsh-read-non-seekable'

On Tue, May 07, 2024 at 04:56:00PM +0000, Andrea Bolognani wrote: > On Fri, Mar 22, 2024 at 06:56:08PM GMT, Peter Krempa wrote: > > +static void > > +testPipeFeeder(void *opaque) > > +{ > > + /* feed more than observed buffer size which was historically 128k in the > > + * test this was adapted from */ > > + size_t emptyspace = 140 * 1024; > > This test seems to fail consistently at least on ppc64le, among other > less common architectures. This can be seen both in Debian[1] and > Fedora[2]. It runs for a while, then it hits the timeout gets > terminated by meson. > > I've reproduced it locally and this is the output: > > # LIBVIRT_DEBUG=1 VIR_TEST_DEBUG=1 VIR_TEST_RANGE=71 ./tests/virshtest > ninja: no work to do. > TEST: virshtest > 71) read-big-pipe > ... 2024-05-07 16:43:17.099+0000: 69735: info : libvirt version: > 10.4.0 > 2024-05-07 16:43:17.099+0000: 69735: debug : virThreadJobSet:96 : > Thread 69735 is now running job testPipeFeeder > 2024-05-07 16:43:17.099+0000: 69734: debug : virCommandRunAsync:2657 > : About to run LANG=C /root/libvirt/build/tools/virsh --connect > test:///default 'define /tmp/libvirt_virshtest_XUTXGN2/pipe ; list > --all' > 2024-05-07 16:43:17.099+0000: 69735: debug : virThreadJobClear:121 : > Thread 69735 finished job testPipeFeeder with ret=0 > 2024-05-07 16:43:17.099+0000: 69734: debug : virCommandRunAsync:2659 > : Command result 0, with PID 69736 > > I've bumped the size of emptyspace to 1024*1024 and that causes the > test to pass. 1023*1024 doesn't. Could it be something about the > fifo's capacity being different across architectures? I had multiple builds fail in Fedora, but today a ppc64 build magically passed. So even on ppc64 it is racy :-( The virFileReadAll method reads in BUFSIZ chunks but that hasn't changed in years. The new test is pretty trivial, and I struggle to see why changing the buffer size would affect it, given the old test this replaced did largely the same thing.