Re: [PATCH] .gitlab-ci.d/windows: Work-around timeout and OpenGL problems of the MSYS2 jobs

[Thomas Huth]

On 06/01/2023 10.24, Bin Meng wrote:
> On Fri, Jan 6, 2023 at 3:35 AM Thomas Huth <thuth@redhat.com> wrote:
> > On 05/01/2023 09.34, Thomas Huth wrote:
> > > On 04/01/2023 23.01, Peter Maydell wrote:
> > > > On Wed, 4 Jan 2023 at 12:36, Thomas Huth <thuth@redhat.com> wrote:
> > > > > The windows jobs (especially the 32-bit job) recently started to
> > > > > hit the timeout limit. Bump it a little bit to ease the situation
> > > > > (80 minutes is quite long already - OTOH, these jobs do not have to
> > > > > wait for a job from the container stage to finish, so this should
> > > > > still be OK).
> > > > >
> > > > > Additionally, some update on the container side recently enabled
> > > > > OpenGL in these jobs - but the corresponding code fails to compile.
> > > > > Thus disable OpenGL here for the time being until someone figured
> > > > > out the proper fix in the shader code for this.
> > > > >
> > > > > Signed-off-by: Thomas Huth <thuth@redhat.com>
> > > > > ---
> > > > >    Now that the timeout and OpenGL problems are gone, the 64-bit is
> > > > >    working fine for me again. However, I'm still seeing random issues
> > > > >    with the 32-bit job ... not sure whether it's a problem on the
> > > > >    QEMU side or whether the builders are currently instable, since
> > > > >    the issues do not reproduce reliably...
> > > > >
> > > > >    .gitlab-ci.d/windows.yml | 7 ++++---
> > > > >    1 file changed, 4 insertions(+), 3 deletions(-)
> > > >
> > > > Thanks; applied to master on the assumption it will improve the
> > > > CI situation. I found that the msys2-32bit job still timed out
> > > > at 1h20, though:
> > > >
> > > > https://gitlab.com/qemu-project/qemu/-/jobs/3555245586
> > >
> > > I just gave it a try again, too, and for me, it finished within 65 minutes:
> > >
> > >    https://gitlab.com/thuth/qemu/-/jobs/3557600268
> > >
> > > ... let's keep looking for a while, maybe it's ok in most cases now, but if
> > > not, we have to consider something else.
> >
> > Ok, so after I've been struggling with a failing msys2-32bit job for my new
> > upcoming pull request the last two days (I thought I had a bad patch in
> > there), where I had some problems with the test-hmp and qom-test qtests,
> > I've come up with a new theory after looking at this CI run from the
> > qemu-project staging branch and seeing that these tests are also failing there:
> >
> >    https://gitlab.com/qemu-project/qemu/-/jobs/3558798544
> >    https://gitlab.com/qemu-project/qemu/-/jobs/3560870904
> >
> > That might also explain the timed-out job that you have seen earlier, Peter,
> > it was likely a hanging qom-test since that seems to be the first test to be
> > executed during the "make check" there.
> >
> > So the qtests for Windows are definitely not ready for the CI yet (after
> > we've enabled them just in December). I think it's best to disable them
> > there again completely until the issues are understood and fixed.
>
> I cannot reproduce the test failures of both tests (test-hmp and
> qom-test) with w32 executables. Neither did the w64 executables.
>
> My testing repo is at commit d1852caab131ea898134fdcea8c14bc2ee75fbe9.

Can you at least reproduce it in the Gitlab-CI? ... it also does not always 
occur, sometimes the jobs are working fine. I suspect it's some kind of race 
or memory problem ... is there something similar to "Valgrind" on Windows? 
If so, could you try to run those qtests there with such tooling enabled?

 Thomas