See entire call tree on std::mutex locks
-
We've faced a problem which should be quite easy to look into, however with QT Creator it doesn't seem to be that obvious; maybe there's something we've overlooked, and hopefully you can point us in the right direction.
In short, we've been trying to investigate a dead-lock issue. Normally we would have expected the debug-view to be able to show FULL stack-frames of each thread. So that in case of a dead-lock situation, we would have expected stack frames with for ex. calls to std::mutex's lock() functions awaiting to acquire a lock. This way we could investigate precisely which thread is stuck at which mutex acquisition attempt. sound like a typical way to go around the problem.
However, this does not seem to be so straightforward with QT creator. Instead of debug-info pointing straight to files in our code, the debig view shows only code stuck at libc.so and portions of stack frames below are reported as '??'. Debug symbols are available. The screenshot below was taken after the app was paused.
The above is a stack-frame reported by QT Creator after the code below got executed:
There's a deadlock situation since mFieldsGuardian is locked and attempted to be locked again in a call to getTools() below; however, from the debugger's output there's no way to know which user-code function lead to that lock() invocation. We would like to be able to see the entire stack frame leading to invocation of that very libc instruction.
By the way - it's an iOS/Android app.
Of course, 'no way to know' is an exaggeration; there are still memory pointers supposedly available next to '??'
Ideas?
-
IIUC, what you show is what I would expect. The waiting lock syscalls are called from within in libc, so of course the numerous threads waiting would be blocked from within libc. Also, multi-thread debugging is a biatch, any way you slice it. ;^P
Two things.
First, if you are developing a Qt app then directly using std::mutex may be hiding things from creator. Why not using QMutex?
Second, if it were me I might consider replacing the system mutex with one that is implemented in userspace using an atomic var reference. In that case you should see the blocked threads spinning in a loop waiting for the atomic variable acquisition.
