POTENTIAL DEADLOCK FYI #7314

If anyone cares. I haven't had the time to look into this potential deadlock on regtest (after generating two blocks). The annoying error is related to #5405, so ignore that.

2016-01-08 03:13:42 keypool reserve 17 2016-01-08 03:13:42 CreateNewBlock(): total size 1000 txs: 0 fees: 0 sigops 100 2016-01-08 03:13:42 UpdateTip: new best=5c1a7a90c6d94ff3a54c42c621f05942dba3945a455d8d1dc3183e1893c961f7 height=338 log2_work=9.4051415 tx=393 date=2016-01-08 03:13:42 progress=1.000000 cache=0.0MiB(1tx) 2016-01-08 03:13:42 AddToWallet 95e658f43e5d2ef31ea15f5f7fef37b8d1461d46a28457ac8ab378113f091e34 new 2016-01-08 03:13:42 keypool keep 17 2016-01-08 03:13:42 CreateNewBlock(): total size 1000 txs: 0 fees: 0 sigops 100 2016-01-08 03:13:42 ERROR: CheckProofOfWork(): hash doesn't match nBits 2016-01-08 03:13:42 ERROR: CheckProofOfWork(): hash doesn't match nBits 2016-01-08 03:13:42 UpdateTip: new best=3a3a194bcfcb9a11b5f71c0a177823ae1fa9f2459dcc30f93954596ce655c59f height=339 log2_work=9.4093909 tx=394 date=2016-01-08 03:13:42 progress=1.000000 cache=0.0MiB(2tx) 2016-01-08 03:13:42 AddToWallet 2aa2dcbde5483019739c2900dba89638661e34d83aa660acb1d458ce13cb00d9 new 2016-01-08 03:13:42 POTENTIAL DEADLOCK DETECTED 2016-01-08 03:13:42 Previous lock order was: 2016-01-08 03:13:42 pnode->cs_vRecvMsg net.cpp:1747 (TRY) 2016-01-08 03:13:42 (1) cs_main main.cpp:4628 2016-01-08 03:13:42 (2) cs_vSend net.cpp:2461 2016-01-08 03:13:42 Current lock order is: 2016-01-08 03:13:42 (2) pnode->cs_vSend net.cpp:1766 (TRY) 2016-01-08 03:13:42 (1) cs_main main.cpp:5339 (TRY) 2016-01-08 03:13:42 (1) cs_main main.cpp:1369

Relating to #4493

False-positive (note the "(TRY)")

The logs are getting a little (unduly? #5405) crowded. We may want to rein it in, regtest particularly, as unorthodox as that sounds.

For kicks, every entry in the sampling below being printed on regtest is arguably an issue, some of which have been logged.

2016-01-08 04:01:05 ERROR: CheckProofOfWork(): hash doesn't match nBits 2016-01-08 04:01:05 ERROR: CheckProofOfWork(): hash doesn't match nBits 2016-01-08 04:01:05 ERROR: CheckProofOfWork(): hash doesn't match nBits 2016-01-08 04:01:16 ERROR: Read: Failed to open file /someexoticlocation/DataDir/regtest/banlist.dat 2016-01-08 04:01:16 Invalid or missing banlist.dat; recreating 2016-01-08 04:01:16 Loading addresses from DNS seeds (could take a while) 2016-01-08 04:01:16 0 addresses found from DNS seeds 2016-01-08 04:01:21 POTENTIAL DEADLOCK DETECTED 2016-01-08 04:01:21 Previous lock order was: 2016-01-08 04:01:21 pnode->cs_vRecvMsg net.cpp:1747 (TRY) 2016-01-08 04:01:21 (1) cs_main main.cpp:4628 2016-01-08 04:01:21 (2) cs_vSend net.cpp:2461 2016-01-08 04:01:21 Current lock order is: 2016-01-08 04:01:21 (2) pnode->cs_vSend net.cpp:1766 (TRY) 2016-01-08 04:01:21 (1) cs_main main.cpp:5339 (TRY) 2016-01-08 04:01:21 (1) cs_main main.cpp:1369 2016-01-08 04:01:33 Adding fixed seed nodes as DNS doesn't seem to be available.

Relating #5397

The logs are getting a little (unduly? #5405) crowded. We may want to rein it in, regtest particularly, as unorthodox as that sounds.

Hmm... IIRC, you only get the "POTENTIAL DEADLOCK" warnings if you have enabled DEBUG_LOCKORDER. No need to clean/reduce that IMO.

Right. DEBUG_LOCKORDER does that on purpose. It is meant to be verbose. It isn't enabled for production builds.

It may have been a mistake to enable that by default for --enable-debug though. The interpretation of that option is ambiguous, e.g. some developers just enable it to get debug information in the executable.