On 13 May 2015 at 04:23, Programmingkid <[email protected]> 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
