generateto{address|descriptor} RPCs freeze the GUI #122
Comments
fanquake
added a commit
that referenced
this issue
Oct 7, 2024
This should be long enough (with headroom) for our longest running tests, which even under MSAN, TSAN, Valgrind, etc max out at about 800s. i.e under Valgrind I see the longer runtimes as: ```bash 135/136 Test #8: bench_sanity_check_high_priority ..... Passed 371.19 sec 136/136 Test #122: coinselector_tests ................... Passed 343.39 sec ``` In the CI `tests` under TSAN: ```bash tests ................................ Passed 795.20 sec ``` and MSAN: ```bash tests ................................ Passed 658.48 sec ``` This will also prevent the current issue we are seeing of `ctest` running until it reaches the CI timeout, see #30969. However, we still need to figure out what underlying issue is causing the tests to (sometimes) run for so long, but in the mean time, this will stop `ctest` wasting our CI CPU.
fanquake
added a commit
that referenced
this issue
Oct 7, 2024
… minutes) 56aad83 ci: set a ctest timeout of 1200 (20 minutes) (fanquake) Pull request description: This should be long enough (with headroom) for our longest running tests, which even under MSAN, TSAN, Valgrind, etc max out at about 800s. i.e under Valgrind I see the longer runtimes as: ```bash 135/136 Test #8: bench_sanity_check_high_priority ..... Passed 371.19 sec 136/136 Test #122: coinselector_tests ................... Passed 343.39 sec ``` In the CI `tests` [under TSAN](https://cirrus-ci.com/task/6321297691508736?logs=ci#L2520): ```bash tests ................................ Passed 795.20 sec ``` [and MSAN](https://cirrus-ci.com/task/4913922807955456?logs=ci#L2226): ```bash tests ................................ Passed 658.48 sec ``` This will also prevent the current issue we are seeing of `ctest` running until it reaches the CI timeout, see #30969. We still need to figure out what underlying issue is causing the tests to (sometimes) run for so long, but in the mean time, this will stop `ctest` wasting our CI CPU. It should also make it more clear in the logs, exactly which test is the one that is hitting the timeout. ACKs for top commit: maflcko: review ACK 56aad83 tdb3: re ACK 56aad83 Tree-SHA512: 43c0dc12b8b12b1d9804751a9816935e2abbe962b451e12a268f2d2c430bc568b83995dbc405f100b596dfb0f1e9f65b78074de98916592d3ae4ebc2126e3a6c
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
During execution of the
generateto{address|descriptor}RPCs theNotifyBlockTipandNotifyTransactionChangedsignals are emitted, which in turn interact with the GUI viaClientModel,WalletModel, andTransactionTableModelclasses.On regtest it is possible to run the mentioned RPCs with a large enough
num_blockargument. That causes the GUI to freeze, as noted by jonasschnelli.Please note that the GUI hangs regardless of whether the RPC is called via
bitcoin-clior in the GUI console.The text was updated successfully, but these errors were encountered: