Deadlock on exit after low disk space during syncing #4083

I'm seeing this behavior pretty consistently on current master.

Since #4058 ?

Probably, I'm about to test reverting those commits.

This is what's happening, grepping out the net locks:

2014-04-22 21:42:19 Locking: cs_main main.cpp:3806 2014-04-22 21:42:19 Locking: cs_nTimeOffset util.cpp:1250 2014-04-22 21:42:19 Locking: cs_main transactiontablemodel.cpp:193 2014-04-22 21:42:19 Unlocked: cs_nTimeOffset util.cpp:1250 2014-04-22 21:42:19 Locking: cs_LastBlockFile main.cpp:2199 2014-04-22 21:42:19 Locking: csPathCached util.cpp:995 2014-04-22 21:42:19 Unlocked: csPathCached util.cpp:995 2014-04-22 21:42:19 *** Error: Disk space is low!

Also, it only happens with bitcoin-qt, not with the daemon, and it doesn't happen with 55a1db4fa2cf62b9766ef382c1e14b3ecbdf67fe reverted (but it do have other issues).

Does it report anything about a deadlock if you compile with DEBUG_LOCKORDER? (which locks, acquired where, are causing this deadlock?)

I managed to reproduce this. This is a very sneaky deadlock, not a conventional one.

The problem is that the P2P thread does a synchronous call to the GUI thread to show a notification, with locks held. It is synchronous because the shutdown needs to wait for the user to click 'Ok' on the dialog box (so they can read the error message...).

One solution would be for the GUI thread to use TRY_LOCKs for periodically updating various stats from the core. This would avoid it getting stuck when the lock is already held.

Edit: Hmm I tried this but it doesn't always work either. An update can come from Qt itself, and the various model update functions also need locks. These are harder to skip than periodical polls and would need to show cached data.

See #4085