Re: [PATCH 00/26] Migration PULL 2023-07-24

[Juan Quintela <quintela@redhat.com>]

Thomas Huth <thuth@redhat.com> wrote:
> On 24/07/2023 15.06, Juan Quintela wrote:
>> Hi
>> This is the migration PULL request.
>
> Maybe it would better to use "PULL" instead of "PATCH" in the subject?

Grrrr.

Resending.  Thanks.

>> Now a not on CI, thas has been really bad.  After too many problems
>> with last PULLS, I decided to learn to use qemu CI.  On one hand, it
>> is not so difficult, even I can use it O:-)
>> On the other hand, the amount of problems that I got is inmense.
>> Some
>> of them dissapear when I rerun the checks, but I never know if it is
>> my PULL request, the CI system or the tests themselves.
>
> I normally peek at https://gitlab.com/qemu-project/qemu/-/pipelines to
> see whether the problem occurred in one of the last staging CI runs
> already ... or I push the master branch to my own repo to see whether
> it reproduces with a clean state. That often helps in judging whether
> it's a new problem or a pre-existing one.

It don't happens for master branch at the time.  It only happens with my
changes.

But the change previous to that one runs well.  That one always fails in
the block layer.  And the changes on that "series" were only for
migration-test.c, so it shouldn't break any other tests.  No other files
are touched.

Yes, in the PULL request more files are touched, but the tests I was
doing on CI there weren't.

I have no clue what gcov is adding to those tests really (I know what
gcov is, not what gcov is trying to do on that test.)

>> This (last) patch is not part of the PULL request, but I have found
>> that it _always_ makes gcov fail.  I had to use bisect to find where
>> the problem was.
>> https://gitlab.com/juan.quintela/qemu/-/jobs/4571878922
>> I could use help to know how a change in test/qtest/migration-test.c
>> can break block layer tests, I am all ears.
>> Yes, I tried several times.  It always fails on that patch.  The
>> passes with flying colors.
>
> Can you reproduce it locally by running "make check-block"?

No.  make check with all architectures under the sun works as expected.

I have learn my lesson here, and know I have to terminals open.  One
compiles x86_64 natively and test natively.

The other compiles aarch64 and test it using TCG.

(I do more tests, but that is run after each patch got reviewed and
integrated for the PULL request)

> The tests/qemu-iotests/tests/copy-before-write test seems to be doing
> some things with snapshots ... maybe that's related?

It could.  But I am not changing that.  I am only changing
migration-test.c.

As Daniel answered on list, problably it is just a race that changing
timing makes it more probable.

Later, juan.