qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Remaining CI failures


From: Daniel P . Berrangé
Subject: Re: [Qemu-devel] Remaining CI failures
Date: Mon, 14 Jan 2019 15:12:01 +0000
User-agent: Mutt/1.10.1 (2018-07-13)

On Mon, Jan 14, 2019 at 10:02:06AM -0500, Emilio G. Cota wrote:
> On Fri, Jan 11, 2019 at 19:10:07 +0000, Alex Bennée wrote:
> > So trying to narrow down the remaining failures in the CI system. There
> > is one with a patch in flight (use g_usleep instead of sleep) but there
> > remains two failure modes, both erratic.
> > 
> > tests/qht-par:
> > 
> > I can trigger this on my dev machine with a gprof enabled build:
> > 
> >   # QEMU configure log Fri Jan 11 14:10:45 GMT 2019
> >   # Configured with: './configure' '--disable-tools' '--disable-docs' 
> > '--enable-gprof' '--enable-gcov'
> > 
> > I only seem to be able to trigger it when running via the wrapper in the
> > make system:
> > 
> >   retry.py -n 30 --invert make check-tests/test-qht-par
> > 
> > Eventually this crashes with:
> > 
> >   ERROR:tests/test-qht-par.c:20:test_qht: assertion failed (rc == 0): 
> > (35584 == 0)
> > 
> > Leaving a core dump for the child:
> 
> I can't replicate this on my machine :-(
> 
> I suspect this is probably related to the fact that gprof
> is not even meant to support multi-threaded programs (like qht-bench).
> 
> Given that we've fixed the sleep issue (thanks!) and that there is no use
> in running test-qht-par under gprof, I propose to permanently skip
> it under gprof, e.g.:
> 
> --- a/tests/Makefile.include
> +++ b/tests/Makefile.include
> @@ -88,7 +88,8 @@ check-unit-y += tests/test-rcu-simpleq$(EXESUF)
>  check-unit-y += tests/test-rcu-tailq$(EXESUF)
>  check-unit-y += tests/test-qdist$(EXESUF)
>  check-unit-y += tests/test-qht$(EXESUF)
> -# FIXME: {test-qht-par + gprof} often break on Travis CI
> +# test-qht-par invokes qht-bench, which is multi-threaded.
> +# gprof doesn't support multi-threaded programs, so skip this test under 
> gprof.

If gprof doesn't support threads, then we potentially need to skip more
of our tests. eg test-io-channel-socket uses APIs that spawn threads
behind the scenes, not to mention the test-thread-pool test. Some
chardev tests probably hit APIs that spawn background threads too.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



reply via email to

[Prev in Thread] Current Thread [Next in Thread]