Re: [PULL 00/21] Migration 20230428 patches

["Daniel P. Berrangé" <berrange@redhat.com>]

On Wed, May 03, 2023 at 11:17:33AM +0200, Juan Quintela wrote:
> 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:-)

I did have a play, but didn't get anything satisfactory working.
I could only capture a trace from a single thread and the hard
problems that really want traces usually involve multiple threads.
There's really no good substitute for an OS level crash collector
like systemd-coredump or abrtd :-( This is really worth an RFE
to GitLab as a possible enhancement to their shared runners.

> > 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:

Any g_assert  failure will result in an abort, so there are many
possibilities.

We should be uploading the testlog.txt from meson test to show what
one asserts, but I've just discovered we're lacking 'when: always'
on our 'artifacts' declarations. So the artifacts are only uploaded
when the job succeeds, which the least useful scenario for our test
logs !

With 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 :|