Fixing a possible memory access violation in CPartialMerkleTree::CalcHash().
This can happen if we some how a merkle tree with zero txids. I don't think this can happen in practice as we only send merkle block messages on the p2p network as of now -- we cannot receive them.
This was found with #8469, specifically using this generator which will cause a memory access violation on this test case.
If it shouldn't happen, maybe an assert is better?
@TheBlueMatt what was the behavior before if the elements list was empty?
nvm it returned 0 so this maintains the original behavior
Probably best to assert that vTxid has non-zero length, as that would represent generating a tree for an invalid block.
Changed to what @dcousens and @TheBlueMatt suggested. I think that makes sense at the end of the day. Also, from what I can tell, that assert cannot be hit from the p2p code.
I would have set fBad, so we don't risk later to reach a network reachable assert(0) by inadvertance. :)
Looks good. Lightly tested ACK 51802ccc4561bd5a94499c665a333517f5eadd10
if you're adding an assert, can you put some commenting in explaining the assumptions that you're testing (either around the assert or the function declaration).
Also please remove the merge commits from this PR.
EDIT: cool that this was found using your property-based testing. I've been meaning to review #8469 for a while.
@jnewbery Addressed the concerns you had.
If you want to chat about 8469 don't be afraid to ping me on irc. I think it will allow us to streamline testing AND exhaustively test invariants better than we are now.
why no just setting fBad and returning ? I really don't like having an assert, this code might be reached from the network one day for some reason (maybe unsuspecting new feature). Putting an assert here is a tragedy waiting to happen.
@NicolasDorier - I had the same concerns as you, so I spent some time reading around the code to convince myself that this was ok. This code is only called from the CMerkleBlock constructor, which is only called from the gettxoutproof RPC or in response to a MSG_FILTERED_BLOCK getdata request. In both cases, we're constructing the Merkle Block from a block that's already in our mapBlockIndex. Therefore to hit this assert, we'd need there to be an invalid block in the mapBlockIndex, which would mean:
in which case, asserting is appropriate.
As for concerns about future code calling this without knowing about the assert - they'd have to be constructing a merkle block for a block that they hadn't already validated, which is a very bad idea! Just to make sure, Chris has now also added a comment above the assert to clarify assumptions.
Hope that allays your concerns!
utACK bbdd771e4c1a9ae405a266c0b158bf6825acef15, though it would be nice to add a comment to CMerkleBlock noting that the block containing transactions will be asserted-on.
@TheBlueMatt Added the comment, is this ready for merge?
EDIT: Also rebased
Adding comment to assert in PartialMerkleTree::CalcHash()
Adding comment on CMerkleBlock indicating it calls something that contains an assert
Removing EOL whitespace
120 | @@ -121,6 +121,8 @@ class CPartialMerkleTree 121 | /** 122 | * Used to relay blocks as header + vector<merkle branch> 123 | * to filtered nodes. 124 | + * 125 | + * NOTE: This is asserted on when building CPartialMerkleTree
Wait, what is asserted? Also note extra space at EOL here.
utACK.
utACK 8276e70de15c5c3a7525471ad619edd1237b424a
utACK 8276e70de15c5c3a7525471ad619edd1237b424a