Re: [xen-unstable test] 149520: regressions - FAIL

[Jürgen Groß <jgross@xxxxxxxx>]

On 09.04.20 12:35, Jan Beulich wrote:
> On 09.04.2020 12:23, Jürgen Groß wrote:
> > On 09.04.20 11:00, Jan Beulich wrote:
> > > On 09.04.2020 10:56, Jürgen Groß wrote:
> > > > On 09.04.20 10:00, Jan Beulich wrote:
> > > > > On 09.04.2020 09:31, Jürgen Groß wrote:
> > > > > > On 09.04.20 04:30, osstest service owner wrote:
> > > > > > > flight 149520 xen-unstable real [real]
> > > > > > > http://logs.test-lab.xenproject.org/osstest/logs/149520/
> > > > > > >
> > > > > > > Regressions :-(
> > > > > > >
> > > > > > > Tests which did not succeed and are blocking,
> > > > > > > including tests which could not be run:
> > > > > > >      test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-saverestore 
> > > > > > > fail REGR. vs. 149478
> > > > > > >      test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install 
> > > > > > > fail REGR. vs. 149478
> > > > > > Is it possible to get the ioemu-stubdom binary used in those tests?
> > > > > Isn't this the usr/local/lib/xen/boot/ioemu-stubdom.gz in
> > > > > http://logs.test-lab.xenproject.org/osstest/logs/149520/build-amd64-xsm/build/dist.tar.gz
> > > > No, the crashed one was a 32-bit stubdom, while this file is a 64-bit
> > > > one. According to the log the path should be fine, but the file in no
> > > > way matches the crashed one.
> > > Then look under 
> > > http://logs.test-lab.xenproject.org/osstest/logs/149520/build-i386-xsm/build/
> > > or any of the other 
> > > http://logs.test-lab.xenproject.org/osstest/logs/149520/build-*/build/?
> > > I'm pretty sure all produced binaries get collected and made available.
> > Yes, there it could be found.
> >
> > I'm still struggling to understand why the stubdom is built as 32-bit
> > binary for this test.
> Aiui in test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
> the first amd64 stands for the host (Xen) architecture, the
> last for the guest one, and the i386 for the tool stack's. I
> assume the stubdom binary chosen is picked based on the tool
> stack properties, despite it running in a different domain.
I have managed to reproduce the problem.

It happens only in 32-bit ioemu-stubdom, not in 64-bit.

It happens only with the guest's vif configured with "type=ioemu".

This makes Mini-OS commit d225f4012d69a19 suspicious, and I think
I have found a double free() in it.

Will send a patch.


Juergen