Re: [Qemu-devel] intermittent make check failure: "tcg_handle_interrupt: assertion failed: (qemu_mutex_iothread_locked())"

[Mark Cave-Ayland]

On 01/03/17 12:41, Alex Bennée wrote:

>> Here's the backtrace from my test case of qemu-system-sparc running on
>> an x86_64 host that I posted yesterday:
>>
>>
>> $ gdb --args ./qemu-system-sparc -cdrom
>> /home/build/src/qemu/image/sparc32/debian-40r4a-sparc-netinst.iso -boot d
>> GNU gdb (GDB) 7.4.1-debian
>> Copyright (C) 2012 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later
>> <http://gnu.org/licenses/gpl.html>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
>> and "show warranty" for details.
>> This GDB was configured as "x86_64-linux-gnu".
>> For bug reporting instructions, please see:
>> <http://www.gnu.org/software/gdb/bugs/>...
>> Reading symbols from /home/build/rel-qemu-git/bin/qemu-system-sparc...done.
>> (gdb) r
>> Starting program: /home/build/rel-qemu-git/bin/qemu-system-sparc -cdrom
>> /home/build/src/qemu/image/sparc32/debian-40r4a-sparc-netinst.iso -boot d
>> warning: no loadable sections found in added symbol-file system-supplied
>> DSO at 0x7ffff7ffa000
>> [Thread debugging using libthread_db enabled]
>> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
>> [New Thread 0x7fffe9eee700 (LWP 18040)]
>> [New Thread 0x7fffe66d6700 (LWP 18041)]
>> [New Thread 0x7fffe5ed5700 (LWP 18042)]
>> qemu-system-sparc: -cdrom
>> /home/build/src/qemu/image/sparc32/debian-40r4a-sparc-netinst.iso:
>> warning: bus=0,unit=2 is deprecated with this machine type
>> [Thread 0x7fffe66d6700 (LWP 18041) exited]
>> [New Thread 0x7fffe66d6700 (LWP 18043)]
>> **
>> ERROR:/home/build/src/qemu/git/qemu/translate-common.c:34:tcg_handle_interrupt:
>> assertion failed: (qemu_mutex_iothread_locked())
>>
>> Program received signal SIGABRT, Aborted.
>> [Switching to Thread 0x7fffe5ed5700 (LWP 18042)]
>> 0x00007ffff2939125 in *__GI_raise (sig=<optimized out>) at
>> ../nptl/sysdeps/unix/sysv/linux/raise.c:64
>>
>>
>>
>> 64      ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
>> (gdb) thread apply all bt
>>
>> Thread 5 (Thread 0x7fffe66d6700 (LWP 18043)):
>> #0  sem_timedwait () at
>> ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_timedwait.S:106
>> #1  0x000055555591435c in qemu_sem_timedwait (sem=0x5555561ad408,
>> ms=10000) at util/qemu-thread-posix.c:255
>> #2  0x000055555590cb51 in worker_thread (opaque=0x5555561ad3a0) at
>> util/thread-pool.c:92
>> #3  0x00007ffff2c9ab50 in start_thread (arg=<optimized out>) at
>> pthread_create.c:304
>> #4  0x00007ffff29e4fbd in clone () at
>> ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
>> #5  0x0000000000000000 in ?? ()
>>
>> Thread 4 (Thread 0x7fffe5ed5700 (LWP 18042)):
>> #0  0x00007ffff2939125 in *__GI_raise (sig=<optimized out>) at
>> ../nptl/sysdeps/unix/sysv/linux/raise.c:64
>> #1  0x00007ffff293c3a0 in *__GI_abort () at abort.c:92
>> #2  0x00007ffff407e477 in g_assertion_message () from
>> /lib/x86_64-linux-gnu/libglib-2.0.so.0
>> #3  0x00007ffff407e994 in g_assertion_message_expr () from
>> /lib/x86_64-linux-gnu/libglib-2.0.so.0
>> #4  0x000055555561b54f in tcg_handle_interrupt (cpu=0x5555561b3af0,
>> mask=2) at /home/build/src/qemu/git/qemu/translate-common.c:34
>> #5  0x00005555556a8e7d in cpu_interrupt (cpu=0x5555561b3af0, mask=2) at
>> /home/build/src/qemu/git/qemu/include/qom/cpu.h:801
>> #6  0x00005555556a95ec in cpu_check_irqs (env=0x5555561bbd80) at
>> /home/build/src/qemu/git/qemu/hw/sparc/sun4m.c:157
> 
> Am I correct assuming all the helper functions themselves are concerned
> with the vCPU environment they are running in? If so it looking like
> cpu_check_irqs() would be the place to wrap the BQL lock in.
> 
> I'll make the change and test against your test case.

For the window helpers, definitely yes - each SPARC vCPU contains a
large bank of registers of which the current window is a pointer as to
which register set is currently active. The current window itself is
controlled by a special register called CWP (current window pointer)
which is part of the PSR register in 32-bit CPUs or a standalone
register for 64-bit CPUs.

I ran out of time yesterday to run through all my SPARC64 tests, however
if this is the case then the issue will definitely appear in
qemu-system-sparc64 which seems to be supported by people seeing
intermittent failures in prom-env-test.


ATB,

Mark.