-
Notifications
You must be signed in to change notification settings - Fork 35.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
migratewallet crashes on an freshly created datadir ( wallet/wallet.h:959: int wallet::CWallet::GetLastBlockHeight() const: Assertion `m_last_block_processed_height >= 0' failed.) #28510
Comments
The datadir is not corrupt, because it is empty. However, the wallet may be corrupt, as it is just a random file I found on my storage. |
For reference, this is my normal regtest wallet, which may or may not be corrupt as well: wallet.dat.gpg.not.txt (encrypted to DB88DB0BD2EDFBFC) |
That's not a supported use case. |
Yeah, I wasn't sure how to check for wallet corruption. |
The issue appears to be due to having txs that are conflicted. |
This is a more general issue with Specifically the issue is caused by |
…nd conflicting heights in MarkConflicted 782701c test: Test loading wallets with conflicts without a chain (Andrew Chow) 4660fc8 wallet: Check last block and conflict height are valid in MarkConflicted (Andrew Chow) Pull request description: `MarkConflicted` assumes that `m_last_block_processed_height` is always valid. However it may not be valid when a chain is not attached, as happens in the wallet tool and during migration. In such situations, when the conflicting height is also negative (which occurs on loading when no chain is available), the calculation of the number of conflict confirms results in a non-negative value which passes the existing check for valid values. This will subsequently hit an assertion in `GetTxDepthInMainChain`. Furthermore, `MarkConflicted` is also only called on loading a transaction whose parent has a stored state of `TxStateConflicted` and was loaded before the child transaction. This depends on the loading order, which for both sqlite and bdb depends on the txids. We can avoid this by explicitly checking that both `m_last_block_processed_height` and `conflicting_height` are non-negative. Both `tool_wallet.py` and `wallet_migration.py` are updated to create wallets with a state that triggers the assertion. Fixes bitcoin#28510 ACKs for top commit: ryanofsky: Code review ACK 782701c. Nice catch, and clever test (grinding the txid) furszy: ACK 782701c Tree-SHA512: 1344e0279ec5413a43a2819d101fb571fbf4821de2d13958a0fdffc99f57082ef3243ec454c8343f97dc02ed1fce8c8b0fd89388420ab2e55618af42ad5630a9
Is there an existing issue for this?
Current behaviour
crash
Expected behaviour
no crash
Steps to reproduce
Relevant log output
How did you obtain Bitcoin Core
Compiled from source
What version of Bitcoin Core are you using?
current master
Operating system and version
Linux
Machine specifications
yes
The text was updated successfully, but these errors were encountered: