Re: [PULL 00/21] Migration 20230428 patches

[Juan Quintela]

Peter Maydell <peter.maydell@linaro.org> wrote:
> On Tue, 2 May 2023 at 11:39, Juan Quintela <quintela@redhat.com> wrote:
>> Richard, once that we are here, one of the problem that we are having is
>> that the test is exiting with an abort, so we have no clue what is
>> happening.  Is there a way to get a backtrace, or at least the number
>
> This has been consistently an issue with the migration tests.
> As the owner of the tests, if they are not providing you with
> the level of detail that you need to diagnose failures, I
> think that is something that is in your court to address:
> the CI system is always going to only be able to provide
> you with what your tests are outputting to the logs.

Right now I would be happy just to see what test it is failing at.

I am doing something wrong, or from the links that I see on richard
email, I am not able to reach anywhere where I can see the full logs.

> For the specific case of backtraces from assertion failures,
> I think Dan was looking at whether we could put something
> together for that. It won't help with segfaults and the like, though.

I am waiting for that O:-)

> You should be able to at least get the number of the subtest out of
> the logs (either directly in the logs of the job, or else
> from the more detailed log file that gets stored as a
> job artefact in most cases).

Also note that the test is stopping in an abort, with no diagnostic
message that I can see.  But I don't see where the abort cames from:

$ grep abort tests/qtest/migration-*
tests/qtest/migration-test.c:    visit_type_SocketAddressList(iv, NULL, &addrs, 
&error_abort);
tests/qtest/migration-test.c:     * In non-multifd case when client aborts due 
to mismatched
tests/qtest/migration-test.c:     * In multifd case when client aborts due to 
mismatched
tests/qtest/migration-test.c:     * to load migration state, and thus just 
aborts the migration
$

Later, Juan.