Resolves #21605 segfault on legacy wallet
I also encountered same [*] when resyncing a 2017 era blockchain.
373@@ -374,7 +374,7 @@ void LegacyScriptPubKeyMan::MarkUnusedAddresses(const CScript& script)
374 auto it = mapKeyMetadata.find(keyid);
375 if (it != mapKeyMetadata.end()){
376 CKeyMetadata meta = it->second;
377- if (!meta.hd_seed_id.IsNull() && meta.hd_seed_id != m_hd_chain.seed_id) {
378+ if (!meta.hd_seed_id.IsNull() && meta.hd_seed_id != m_hd_chain.seed_id && meta.key_origin.path.size() > 0) {
meta.key_origin.path.size() >= 3
be better if the worry is to go out of range here? Might also log a warning when this happens as it means (I guess?) that the wallet is somehow corrupted.
Resolves segfault on legacy wallet
Log warning when meta.key_origin.path is below expected size
The root cause of the problem this is fixing is that the wallet does not contain the upgraded key metadata because it is encrypted and has not been unlocked yet, and a transaction was found that involved inactive HD chains. So this segfault can be triggered with a non-corrupted wallet. I don’t think it is necessarily correct to log an error and move on as doing so could result in missing funds.
To avoid the crash, I think access to meta.key_origin.path
should be guarded by both the length check and meta.has_key_origin
. Then if has_key_origin == false
, meta.hdKeypath
can be used to figure out what to derive. This would avoid the segfault while not losing any functionality.
when I encountered this, this was the state of meta,
0(gdb)
1p meta
2$1 = {static VERSION_BASIC = 1, static VERSION_WITH_HDDATA = 10, static VERSION_WITH_KEY_ORIGIN = 12,
3 static CURRENT_VERSION = 12, nVersion = 10, nCreateTime = 1509688921, hdKeypath = "m/0'/0'/0'",
4 hd_seed_id = {<uint160> = {<base_blob<160>> = {static WIDTH = 20,
5 m_data = "4\264Y\351....", <incomplete sequence \313>}, <No data fields>}, <No data fields>}, key_origin = {fingerprint = "\000\000\000", path = std::vector of length 0, capacity 0}, has_key_origin = false}
6(gdb)
7
when I encountered this, this was the state of meta,
This matches what I expect. The meta is not upgraded (nVersion is 10, not 12, and has_key_origin is false).
Please squash your commits.
I will implement the derivation from the keypath string in a followup PR as that is a bit more complicated to deal with.
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
Reviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.