From: "Alex Bennée" <alex.bennee@linaro.org>
To: Dario Faggioli <dfaggioli@suse.com>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"cfontana@suse.de" <cfontana@suse.de>,
"pbonzini@redhat.com" <pbonzini@redhat.com>
Subject: Re: make -j check failing on master, interesting valgrind errors on qos-test vhost-user-blk-test/basic
Date: Fri, 27 May 2022 12:02:54 +0100 [thread overview]
Message-ID: <87ilprz13b.fsf@linaro.org> (raw)
In-Reply-To: <559271048dfe01bf1a77c36321ceb1c5b4f6efe0.camel@suse.com>
Dario Faggioli <dfaggioli@suse.com> writes:
> [[PGP Signed Part:Undecided]]
> On Fri, 2022-05-27 at 10:18 +0200, Claudio Fontana wrote:
>> On 5/27/22 9:26 AM, Dario Faggioli wrote:
>> > >
>> > Yes, this kind of matches what I've also seen and reported about in
>> > <5bcb5ceb44dd830770d66330e27de6a4345fcb69.camel@suse.com>. If
>> > enable/run just one of:
>> > - reconnect
>> > - flags_mismatch
>> > - connect_fail
>> >
>> > I see no issues.
>>
>> On the countrary, for me just running a single one of those can fail.
>>
> Well, but you said (or at least so I understood) that running the test
> for the first time, works.
>
> Then, when you run it multiple times, things start to fail.
>
> That was, in fact, my point... I was making the parallelism between the
> fact running only one of those tests works for me and the fact that
> running the test for the first time works for you too.
Hmm so the qos-test is a bit weird as it:
- forks itself to run a single subtest (g_test_trap_subprocess)
- forks itself again for provide the dummy vhost-user daemon
- as well as the fork/execve for qemu itself
while all the paths used for communication should be unique I wouldn't
be surprised if there is a racey interaction or two in the whole thing.
We even see a bit of this is the fact we don't cleanly tear stuff down
so QEMU sees the vhost-user socket disappear under it's feet.
>
> And between the fact that running two tests, one after the other, fails
> for me and the fact that running the same tests multiple times fails
> for you too.
>
> :-)
>
>> > However, Claudio, AFAIUI, you're seeing this with an older GCC and
>> > without LTO, right?
>>
>> Yes, to provide a different angle I tried on veteran OpenSUSE Leap
>> 15.2, so gcc is based on 7.5.0.
>>
>> I don't think LTO is being used in any way.
>>
> Yep, agreed. Now I don't think it's related to LTO specifically either.
>
> Although, it's at least a bit of an Heisenbug. I mean, we're seeing it
> (with two different setups), but for others, things work fine, I guess?
>
> Regards
--
Alex Bennée
prev parent reply other threads:[~2022-05-27 11:15 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-26 18:06 make -j check failing on master, interesting valgrind errors on qos-test vhost-user-blk-test/basic Claudio Fontana
2022-05-26 18:18 ` Claudio Fontana
2022-05-27 7:26 ` Dario Faggioli
2022-05-27 8:18 ` Claudio Fontana
2022-05-27 10:10 ` Claudio Fontana
2022-05-27 10:41 ` Dario Faggioli
2022-05-27 11:02 ` Alex Bennée [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ilprz13b.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=cfontana@suse.de \
--cc=dfaggioli@suse.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.