On May 13, 2015, at 5:38 AM, Peter Maydell wrote:
> 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
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.
