Peter Maydell <peter.mayd...@linaro.org> wrote: > On Tue, 2 May 2023 at 11:39, Juan Quintela <quint...@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.
