Re: [Qemu-devel] Help with deadlock when using sound

[Paolo Bonzini <pbonzini@redhat.com>]

On 12/05/2015 00:43, Programmingkid wrote:
> 
> On May 10, 2015, at 10:54 AM, Paolo Bonzini wrote:
> 
>>
>>
>> On 06/05/2015 18:40, Programmingkid wrote:
>>> When I try to use the pcspk sound hardware, QEMU freezes and uses
>>> 100% of the cpu time. This is the command I use:
>>>
>>> qemu-system-i386 -cdrom <anything you wan here> -soundhw pcspk
>>>
>>> This looks like a deadlock situation because some unknown code called
>>> qemu_mutex_lock(). Here is the stack trace at the freeze:
>>>
>>> (gdb) bt #0  0x00007fff824e2db6 in semaphore_wait_trap () #1
>>> 0x00007fff824e8417 in pthread_mutex_lock () #2  0x0000000100267199 in
>>> qemu_mutex_lock (mutex=<value temporarily unavailable, due to
>>> optimizations>) at util/qemu-thread-posix.c:73 #3  0x003c44016e95153b
>>> in ?? ()
>>>
>>> My host is Mac OS 10.6.8. My guest isn't really anything. I have used
>>> Windows XP before but it isn't necessary to reproduce the problem.
>>>
>>> The ?? is what appears to be the problem. I can't even print
>>> instructions at that address. Any ideas as to what is calling the
>>> qemu_mutex_lock() function could help.

The unknown code here is probably some place where gdb cannot find the
frame pointer.  Not a surprise if you are using a 5 year old debugger
with (presumably) a newer compiler.

>> Reproduced with a FreeDOS image from QEMU Advent Calendar.  It locks up
>> as soon as you type "beep".
>>
>> It works with the PulseAudio and ALSA backends, but it doesn't with the
>> SDL backend, even on Linux.
>>
>> Also, it deadlocks even with KVM enabled.
>>
>> Paolo
> 
> OK, I see a pattern. SDL and CoreAudio both don't support audio input. Both of them have this code:
>  .voice_size_in  = 0
> 
> Alsa and PulseAudio do support audio input and work. Coincidence?

Yes.  Locking in SDL is completely broken.  sdl_callback runs with the
SDL audio lock taken, but then it waits on a semaphore so you cannot
call any other SDL audio function from the main thread.  As soon as you
do that, you get a deadlock.  I'm strongly tempted to just remove the
driver.

On the other hand, CoreAudio seems to be okay.  Can you try "thread
apply all bt full" from gdb?

Paolo