On Fri, Jun 23, 2023 at 03:04:21PM +0000, osstest service owner wrote:
> flight 181558 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/181558/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-amd64-xl-qcow2 21 guest-start/debian.repeat fail REGR. vs.
> 181545
The test failing here is hitting the assert in qemu_cond_signal() as
called by worker_thread():
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007ffff740b535 in __GI_abort () at abort.c:79
#2 0x00007ffff740b40f in __assert_fail_base (fmt=0x7ffff756cef0 "%s%s%s:%u:
%s%sAssertion `%s' failed.\n%n", assertion=0x55555614abcb "cond->initialized",
file=0x55555614ab88 "../qemu-xen-dir-remote/util/qemu-thread-posix.c",
line=198, function=<optimized out>) at assert.c:92
#3 0x00007ffff74191a2 in __GI___assert_fail (assertion=0x55555614abcb
"cond->initialized", file=0x55555614ab88
"../qemu-xen-dir-remote/util/qemu-thread-posix.c", line=198,
function=0x55555614ad80 <__PRETTY_FUNCTION__.17104> "qemu_cond_signal") at
assert.c:101
#4 0x0000555555f1c8d2 in qemu_cond_signal (cond=0x7fffb800db30) at
../qemu-xen-dir-remote/util/qemu-thread-posix.c:198
#5 0x0000555555f36973 in worker_thread (opaque=0x7fffb800dab0) at
../qemu-xen-dir-remote/util/thread-pool.c:129
#6 0x0000555555f1d1d2 in qemu_thread_start (args=0x7fffb8000b20) at
../qemu-xen-dir-remote/util/qemu-thread-posix.c:505
#7 0x00007ffff75b0fa3 in start_thread (arg=<optimized out>) at
pthread_create.c:486
#8 0x00007ffff74e206f in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95
I've been trying to figure out how it can get in such state, but so
far I had no luck. I'm not a QEMU expert, so it's probably better if
someone else could handle this.
In the failures I've seen, and the reproduction I have, the assert
triggers in the QEMU dom0 instance responsible for locally-attaching
the disk to dom0 in order to run pygrub.
This is also with QEMU 7.2, as testing with upstream QEMU is blocked
ATM, so there's a chance it has already been fixed upstream.
Thanks, Roger.
