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

[Programmingkid <programmingkidx@gmail.com>]

On May 13, 2015, at 5:38 AM, Peter Maydell wrote:

> On 13 May 2015 at 04:23, Programmingkid <programmingkidx@gmail.com> 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

Thanks for the code, but it didn't work as it was expected to. The abort or stack trace never happened. I did recompile using enable-debug.