Steps to reproduce: disconnect a full indexed node that has no “wallets” dir, in -datadir. and all node files in -datadir wait until you missed say 20 or more new blocks. A fast syncing high bandwide node might need a lag of more than 100 …. start the node with ui. wait until IBD had set in.. click [Open Wallet] ….
If your whole system or VM ui enters an unresponsive state,
Don;t panic, brew a tee !!!. System should leave dead lock after < 5 min.
Close ui., hmm… :woman_shrugging:
In essence that is an edge case, but new users who first time try to do the right thing and run there full nodes
might run in this …
refernced https://github.com/bitcoin/bitcoin/pull/19419
EDIT: Note: even that fixed, the other freeze of window refresh, if re-scanning a wallet lag;s behind, is a different gui issue.to be solved in pipeline. … Upwards v0.18 ,19. 20 release to master you could get ui also in local temporary freeze, with -reindex or mine more than say 3117 blocks on a different node to an address of your test node and than connect to that mining node. Unless you have a spared miner or to much btc, the preferred method to test is with regtest.
0a="/tmp/test_a"
1b="/tmp/test_b"
2ca="-regtest -datadir=$a"
3cb="-regtest -datadir=$b"
4mkdir $a
5mkdir $b
6bitcoind -daemon $ca -server -datadir=$a
7sleep 1
8adr=$(bitcoin-cli $ca getnewaddress)
9echo $adr
10bitcoin-cli $ca stop
11sleep 1
12bitcoin-qt $cb -server -listen -datadir=$b &
13sleep 1
14echo "wait for coins ... this could take some while to gen"
15gen=$(bitcoin-cli $cb generatetoaddress 3117 $adr)
16# Now start the node, should instant frezze repaint update
17bitcoin-qt $ca -connect=127.0.0.1 -port=1234 -datadir=$a &
18echo $gen
19
20////
21frezze b ?
22
23
So far observed in debian and lubuntu VM’s