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

[Programmingkid]

On May 12, 2015, at 3:45 AM, Paolo Bonzini wrote:

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

Found out why QEMU is deadlocking. It is because a mutex that has been unlocked over 20 times in a row is being locked. 

http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_mutex_lock.html

According to the above link, if pthread_mutex_unlock() is called on a mutex that isn't locked, undefined behavior results. This means the mutex that has been unlocked so many times in a row cannot be trusted. There isn't a way to find out who owns a mutex on Mac OS X, so I made my own logging code to help find out what was going on. If you have access to Mac OS 10.6, you could try out this code by just pasting it in qemu-thread-posix.c:

// Debugging code

#define MAX_SIZE 100

int thread_dict[MAX_SIZE] = {0};

int mutex_dict[MAX_SIZE] = {0};

int addToDict(int id, int * a_dict)

{

    static int index = 0;

    if(index > 99) {

        printf("ERROR: too many threads to keep track of!\n");

        return -1;

    }

    a_dict[index] = id;

    index++;

    return index;

}

int getID(int origID, int* a_dict)

{

    int index;

    for (index = 0; index < MAX_SIZE; index++) {

        if(a_dict[index] == origID) {

            return index;

        }

    }

    return addToDict(origID, a_dict);

}

#include <sys/syscall.h>

void qemu_mutex_lock(QemuMutex *mutex)

{

    int err;

    static int count = 0;

    printf("Lock\tThread = %d\tMutex = %d\n", getID(syscall(SYS_thread_selfid), thread_dict), getID(&mutex, mutex_dict));

    

    err = pthread_mutex_lock(&mutex->lock);

    if (err)

        error_exit(err, __func__);

}

int qemu_mutex_trylock(QemuMutex *mutex)

{

    printf("Trying lock\tThread = %d\tMutex = %d\n", getID(syscall(SYS_thread_selfid), thread_dict), getID(&mutex, mutex_dict));

    return pthread_mutex_trylock(&mutex->lock);

}

void qemu_mutex_unlock(QemuMutex *mutex)

{

    int err;

    static int count = 0;

    printf("Unlock\tThread = %d\tMutex = %d\n", getID(syscall(SYS_thread_selfid), thread_dict), getID(&mutex, mutex_dict));

    err = pthread_mutex_unlock(&mutex->lock);

    if (err)

        error_exit(err, __func__);

}

Locking mutex 38 is where qemu-system-i386 seems to fail the most. 

To test the code, I just ran qemu with -soundhw pcspk.