When compiling with -DDEBUG_LOCKORDER:
2014-06-06 05:56:32 POTENTIAL DEADLOCK DETECTED
2014-06-06 05:56:32 Previous lock order was:
2014-06-06 05:56:32 (1) cs_main qt/clientmodel.cpp:102
2014-06-06 05:56:32 (2) cs_vNodes qt/clientmodel.cpp:48
2014-06-06 05:56:32 Current lock order is:
2014-06-06 05:56:32 (2) cs_vNodes qt/peertablemodel.cpp:52
2014-06-06 05:56:32 (1) cs_main qt/peertablemodel.cpp:73
2014-06-06 05:56:32 (1) cs_main main.cpp:316
My code is not holding both locks at the same time. It should be releasing cs_vNodes and then acquiring cs_main, so my understanding is that there shouldn't be a potential for deadlock?
To prevent that warning I could lock cs_main and then acquire cs_vNodes, but I'd need to hold both at the same time to do it in that order, because the cs_main lock is needed only once the node information is retrieved with cs_vNodes.
Holding only one at a time is great.
But something is going wrong, somehow it's holding both cs_main and cs_vNodes at some point. This could be due to GetNodeStateStats aquiring the cs_main lock, as well.
Also: in https://github.com/bitcoin/bitcoin/blob/master/src/qt/peertablemodel.cpp#L52 you should have the TRY_LOCK inside the braces instead of outside it if you want it to be released when execution flow leaves them.
you should have the TRY_LOCK inside the braces instead of outside it if you want it to be released when execution flow leaves them
Ahh, that would explain why it's holding both. I'll fix that. Should the fix go to the old pull request, or a new one?
A new one; the old one has been merged, so cannot be changed anymore.
How do I make with DEBUG_LOCKORDER?
./configure ... CPPFLAGS="-DDEBUG_LOCKORDER"