hushd: wallet/wallet.cpp:2795: int CWallet::ScanForWalletTransactions(CBlockIndex*, bool): Assertion `pcoinsTip->GetSaplingAnchorAt(pindex->pprev->hashFinalSaplingRoot, saplingTree)' failed.
This assertion is very hostile to users, we need to do something better. Today I got it on two different wallets when trying to rescan what I thought was a valid non-corrupt wallet. We need to give the user a better error message and put something in the debug log, because currently this only is sent to stderr and a GUI wallet shows a user nothing if this happens.
When I got this assertion it was when I tried to do a rescan from a block height after doing one successful rescan from a block height, where the second rescan was from a lower block height.
```
hushd: wallet/wallet.cpp:2795: int CWallet::ScanForWalletTransactions(CBlockIndex*, bool): Assertion `pcoinsTip->GetSaplingAnchorAt(pindex->pprev->hashFinalSaplingRoot, saplingTree)' failed.
```
This assertion is very hostile to users, we need to do something better. Today I got it on two different wallets when trying to rescan what I thought was a valid non-corrupt wallet. We need to give the user a better error message and put something in the debug log, because currently this only is sent to stderr and a GUI wallet shows a user nothing if this happens.
When I got this assertion it was when I tried to do a `rescan` from a block height after doing one successful `rescan` from a block height, where the second rescan was from a lower block height.
I was seeing the same when testing asyncnotedecryption but thought it was related to some of the changes and my wallet being jacked up. I have seen it on other wallets since then with latest release.
I was seeing the same when testing `asyncnotedecryption` but thought it was related to some of the changes and my wallet being jacked up. I have seen it on other wallets since then with latest release.
@fekt I think that originally when you had not ported all the asyncnotedecryption code, the assertion was triggering in a "valid" sense, something was wrong and the assertion caught that. I also think that the assertion can be triggered when the code is valid and the wallet is not corrupt. Looking at git blame I see this code is some of the oldest code we have, back from the Sprout days. Many things have changed since then and the assumptions that the assertion assumes are likely no longer valid. The code should be smarter, if pindex->pprev->hashFinalSaplingRoot != saplingTree a useful message in debug.log should be printed and maybe a rescan done. Almost anything is better than crashing the node with a coredump.
@fekt I think that originally when you had not ported all the `asyncnotedecryption` code, the assertion was triggering in a "valid" sense, something was wrong and the assertion caught that. I also think that the assertion can be triggered when the code is valid and the wallet is not corrupt. Looking at `git blame` I see this code is some of the oldest code we have, back from the Sprout days. Many things have changed since then and the assumptions that the assertion assumes are likely no longer valid. The code should be smarter, if `pindex->pprev->hashFinalSaplingRoot != saplingTree` a useful message in debug.log should be printed and maybe a rescan done. Almost anything is better than crashing the node with a coredump.
@fekt I also just realized that there are at least 6 places that do this assert, so it's not clear if we were both getting the same assertion from the same places
@fekt I also just realized that there are at least 6 places that do this assert, so it's not clear if we were both getting the same assertion from the same places
@fekt I believe I just found and fixed a bug related to this: 558f662a33 (currently only on the duke branch)
We may want to push out a release soon to include this, because I think it breaks full rescans or rescans from block height 1. A workaround is to rescan from block height 2.
@fekt I believe I just found and fixed a bug related to this: 558f662a3356e971056305ed43756849d5f22a87 (currently only on the `duke` branch)
We may want to push out a release soon to include this, because I think it breaks full rescans or rescans from block height 1. A workaround is to rescan from block height 2.
This assertion is very hostile to users, we need to do something better. Today I got it on two different wallets when trying to rescan what I thought was a valid non-corrupt wallet. We need to give the user a better error message and put something in the debug log, because currently this only is sent to stderr and a GUI wallet shows a user nothing if this happens.
When I got this assertion it was when I tried to do a
rescanfrom a block height after doing one successfulrescanfrom a block height, where the second rescan was from a lower block height.I was seeing the same when testing
asyncnotedecryptionbut thought it was related to some of the changes and my wallet being jacked up. I have seen it on other wallets since then with latest release.@fekt I think that originally when you had not ported all the
asyncnotedecryptioncode, the assertion was triggering in a "valid" sense, something was wrong and the assertion caught that. I also think that the assertion can be triggered when the code is valid and the wallet is not corrupt. Looking atgit blameI see this code is some of the oldest code we have, back from the Sprout days. Many things have changed since then and the assumptions that the assertion assumes are likely no longer valid. The code should be smarter, ifpindex->pprev->hashFinalSaplingRoot != saplingTreea useful message in debug.log should be printed and maybe a rescan done. Almost anything is better than crashing the node with a coredump.@fekt I also just realized that there are at least 6 places that do this assert, so it's not clear if we were both getting the same assertion from the same places
@fekt I believe I just found and fixed a bug related to this:
558f662a33(currently only on thedukebranch)We may want to push out a release soon to include this, because I think it breaks full rescans or rescans from block height 1. A workaround is to rescan from block height 2.
The fix is now on the
devbranch