qemu-devel
[Top][All Lists]
Advanced

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

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


From: Peter Maydell
Subject: Re: [Qemu-devel] Help with deadlock when using sound
Date: Wed, 6 May 2015 22:10:45 +0100

On 6 May 2015 at 20:41, Programmingkid <address@hidden> wrote:
>
> On May 6, 2015, at 1:00 PM, Peter Maydell wrote:
>
>> On 6 May 2015 at 17:40, Programmingkid <address@hidden> wrote:
>>> (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.
>>
>> Recompile with optimization disabled and try again. It would
>> also be helpful to provide the backtraces for all threads.
>
> Here is my info:
>
> Configured like this:
> configure --target-list=ppc-softmmu,i386-softmmu --disable-gtk 
> --audio-drv-list=sdl --enable-debug

Does that work? I would not expect anything other than the
coreaudio backend to necessarily work on OSX... At any rate,
better to start with debugging the issue under coreaudio for
simplicity, since you say it happens there too. Checking
whether it works OK on x86/Linux host would also help
narrow down the possibilities.

> Thread 8 (process 29237):
> #0  tb_jmp_cache_hash_func (pc=1) at exec/exec-all.h:208
> #1  0x000000010000c9d7 in tb_find_slow (env=0x103846620, pc=133133655, 
> cs_base=133118944, flags=244) at 
> /Users/user/Documents/Development/Projects/Qemu/qemu-git/cpu-exec.c:309
> #2  0x000000010000cae3 in tb_find_fast (env=0x103846620) at 
> /Users/user/Documents/Development/Projects/Qemu/qemu-git/cpu-exec.c:327
> #3  0x000000010000cf66 in cpu_x86_exec (env=0x103846620) at 
> /Users/user/Documents/Development/Projects/Qemu/qemu-git/cpu-exec.c:485
> #4  0x000000010003978b in tcg_cpu_exec (env=0x103846620) at 
> /Users/user/Documents/Development/Projects/Qemu/qemu-git/cpus.c:1354
> #5  0x0000000100039878 in tcg_exec_all () at 
> /Users/user/Documents/Development/Projects/Qemu/qemu-git/cpus.c:1387
> #6  0x0000000100038dec in qemu_tcg_cpu_thread_fn (arg=0x10383e400) at 
> /Users/user/Documents/Development/Projects/Qemu/qemu-git/cpus.c:1032
> #7  0x00007fff8251bfd6 in _pthread_start ()
> #8  0x00007fff8251be89 in thread_start ()

This backtrace says QEMU hasn't hung -- it is still executing
guest code (though possibly the guest has crashed or gone off
into the weeds, of course).

-- PMM



reply via email to

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