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, 13 May 2015 10:38:10 +0100

On 13 May 2015 at 04:23, Programmingkid <address@hidden> wrote:
> Found out why QEMU is deadlocking. It is because a mutex that has been
> unlocked over 20 times in a row is being locked.

OSX supports 'error checking' mutexes which will fail in these
undefined-behaviour cases like double-unlock. (The error checking
slows things down which is why it's not the default). If you make
qemu_mutex_init() something like:

void qemu_mutex_init(QemuMutex *mutex)
{
    int err;
    pthread_mutexattr_t mta;

    err = pthread_mutexattr_init(&mta);
    if (err) {
        error_exit(err, __func__);
    }
    err = pthread_mutexattr_settype(&mta, PTHREAD_MUTEX_ERRORCHECK);
    if (err) {
        error_exit(err, __func__);
    }
    err = pthread_mutex_init(&mutex->lock, &mta);
    if (err) {
        error_exit(err, __func__);
    }
    pthread_mutexattr_destroy(&mta);
    if (err) {
        error_exit(err, __func__);
    }
}

then we'll turn on the error checking, and a double-unlock
will result in a call to abort(). If you run QEMU under
a debugger you'll get a backtrace which will tell you which
code did the second unlock (and thus which mutex it is).

(Linux has a similar attribute, though it is named
PTHREAD_MUTEX_ERRORCHECK_NP; we might want to consider
turning on mutex debugging for --enable-debug builds.)

-- PMM



reply via email to

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