Dear Lazyweb: How can I fix this deadlock on shutdown
Hello dear lazyweb,
I have a problem that I could not solve nor find help by my usual paths. I’m speaking about a deadlock on shutdown I get sometimes with what will become KDevelop 4.1. You can find a backtrace in this bug report:
https://bugs.kde.org/show_bug.cgi?id=239032
The thing is this: Apparently some global QMutex is getting destroyed by the exit handler but the call to __pthread_cond_destroy does not return.
I have no clue on how to fix this. Is there at least a way to find out which mutex this is? Someone told me to have a look in /proc/PID/maps but there I only found out that - what a suprise - ~QMutex is defined in libQtCore.so… Or should I have looked for the this=0xfffffe00 address? Speaking of which - isn’t that address messed up?
Does anyone have a better idea?
Comments
Want to comment? Send me an email!
Comment by Victor Vicente de Carvalho (not verified) (2010-10-04 04:43:00)
Oh, it’s not double free corruption :p So, maybe this is not the case of the condition variable not being notified before quitting? Then the mutex is locked waiting for the cond var while the shutdown is running and then creating a hell of a invalid state?
cheers
Comment by Victor Vicente de Carvalho (not verified) (2010-10-04 04:38:00)
Yeah, that address is messed up. Usually these kind of address refers to already freed itens on memory :(. I think valgrind’s memcheck would be useful (more than helgrind) because it points exactly to where the address is being double freed.
Comment by David Faure (not verified) (2010-09-30 18:11:00)
Maybe you could run it in valgrind —tool=helgrind? Hopefully upon a deadlock it will give you the backtrace of the creation of that mutex.
Alternatively, start your app in gdb, put a breakpoint in QMutex::QMutex, and then “run”. It will show you where a global mutex is being created, before even going to main. This might be a better first test (quicker).