[Top][All Lists]

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

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

From: Paolo Bonzini
Subject: Re: [Qemu-devel] Help with deadlock when using sound
Date: Tue, 12 May 2015 09:45:52 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0

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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]