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