[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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]

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

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 
or any of the other 
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.




Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.