[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Help with deadlock when using sound
From: |
Programmingkid |
Subject: |
Re: [Qemu-devel] Help with deadlock when using sound |
Date: |
Wed, 6 May 2015 17:19:01 -0400 |
On May 6, 2015, at 5:10 PM, Peter Maydell wrote:
> 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.
Already tried that. Something is wrong with my Linux distro because every time
I try to run QEMU, I see a floating point exception. Maybe somebody on the list
who does use Linux could let us know if using -soundhw pcspk works.
>
>> 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).
If it were still executing guest code, then accessing the monitor would still
work.
Re: [Qemu-devel] Help with deadlock when using sound, Paolo Bonzini, 2015/05/10