[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [xen-unstable test] 130858: regressions - FAIL

>>> On 01.12.18 at 13:43, <osstest-admin@xxxxxxxxxxxxxx> wrote:
> flight 130858 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/130858/ 
> Regressions :-(
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-amd64                   6 xen-build                fail REGR. vs. 
> 129817

In sequence (from the make log) there is 

mkdir -p xen-root
rm -f linkfarm.stamp.tmp
set -e; \
 (mkdir -p xen-root/config; cd xen-root/config; find 
 -type d | sed 
 | xargs mkdir -p .);  (mkdir -p xen-root/xen; cd xen-root/xen; find 
-type d | sed 
 | xargs mkdir -p .); \
find config ! -type l -type f ! -name '*.[isoa]' ! -name '.*.d' ! -name 
'.*.d2') >> linkfarm.stamp.tmp ;   (cd 
find xen ! -type l -type f ! -name '*.[isoa]' ! -name '.*.d' ! -name '.*.d2') 
>> linkfarm.stamp.tmp ;  \
 echo Config.mk >> linkfarm.stamp.tmp ;

(i.e. a piece of the shim build process)

configure: loading cache ../.././config.cache
checking build system type... (cached) x86_64-unknown-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane...


rm -f /home/osstest/build.130858.build-amd64/xen/xen/.xen-syms.[0-9]*

(i.e. a piece of the main hypervisor build process afaict)

 No such file or directory
find: `xen/.xen-syms.1.S': No such file or directory
find: `xen/.xen-syms.1.S': No such file or directory

(i.e. a portion of the execution of above shim build step)

I think this points out a race between the main hypervisor build
and the shim part of the tools build, due to find (obviously) not
being an atomic operation, resulting in the intermediate
.xen-syms.[0-9]* files first being found, but then being
unavailable for find's stat() or whatever invocation. Depending
on the internal workings of find, adding the pattern to the
exclusion list may or may not help (and whether it does may
then also vary per build platform). The only proper solution I
can see is to invest the time into making at least the hypervisor
part of the build allow for out-of-tree operation (something
I think at least both Andrew and I have been having on their
to-do lists for a long time, without finding the time to actually
get this done).

One related observation / question: When a smoke flight has
already built what is needed, why does the "main" flight
re-build everything? A transiently failing smoke flight would be
much cheaper in terms of lost overall throughput.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.