wallet: Ignore MarkConflict if block hash is not known #7491

Merged
merged 1 commit into from Feb 10, 2016

Conversation

Projects
None yet
5 participants
@laanwj
Member

laanwj commented Feb 9, 2016

If number of conflict confirms cannot be determined, this means that the block is still unknown or not yet part of the main chain, for example during a reindex. Do nothing in that case, instead of crash with an assertion failure.
(the block will pass by the wallet again eventually, re-marking the transaction as conflict)

Fixes #7234.

wallet: Ignore MarkConflict if block hash is not known
If number of conflict confirms cannot be determined, this means
that the block is still unknown or not yet part of the main chain,
for example during a reindex. Do nothing in that case,
instead of crash with an assertion.

Fixes #7234.
@sipa

This comment has been minimized.

Show comment
Hide comment
@sipa

sipa Feb 10, 2016

Member

utACK

Member

sipa commented Feb 10, 2016

utACK

@btcdrak

This comment has been minimized.

Show comment
Hide comment
@btcdrak

btcdrak Feb 10, 2016

Member

utACK

Member

btcdrak commented Feb 10, 2016

utACK

@morcos

This comment has been minimized.

Show comment
Hide comment
@morcos

morcos Feb 10, 2016

Member

@sipa Why is it necessary to have the call to MarkConflicted from the fFromLoadWallet code block in the first place? I assume that's the call site that causes this problem?

OK Thanks for the answer on IRC. It's for backwards compatibility so conflict information is created (to the extent possible) for pre-0.12 wallets.

Member

morcos commented Feb 10, 2016

@sipa Why is it necessary to have the call to MarkConflicted from the fFromLoadWallet code block in the first place? I assume that's the call site that causes this problem?

OK Thanks for the answer on IRC. It's for backwards compatibility so conflict information is created (to the extent possible) for pre-0.12 wallets.

@laanwj

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Feb 10, 2016

Member

I assume that's the call site that causes this problem?

Yes (the other callsite should never hit this, as it is called with a block that has just become the new tip).

Member

laanwj commented Feb 10, 2016

I assume that's the call site that causes this problem?

Yes (the other callsite should never hit this, as it is called with a block that has just become the new tip).

@morcos

This comment has been minimized.

Show comment
Hide comment
@morcos

morcos Feb 10, 2016

Member

utACK

Member

morcos commented Feb 10, 2016

utACK

@paveljanik

This comment has been minimized.

Show comment
Hide comment
Contributor

paveljanik commented Feb 10, 2016

@laanwj laanwj merged commit 40e7b61 into bitcoin:master Feb 10, 2016

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

laanwj added a commit that referenced this pull request Feb 10, 2016

Merge #7491: wallet: Ignore MarkConflict if block hash is not known
40e7b61 wallet: Ignore MarkConflict if block hash is not known (Wladimir J. van der Laan)

laanwj added a commit that referenced this pull request Feb 10, 2016

wallet: Ignore MarkConflict if block hash is not known
If number of conflict confirms cannot be determined, this means
that the block is still unknown or not yet part of the main chain,
for example during a reindex. Do nothing in that case,
instead of crash with an assertion.

Fixes #7234.

Github-Pull: #7491
Rebased-From: 40e7b61
@laanwj

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Feb 10, 2016

Member

Cherry-picked to 0.12 as 00ec73e

Member

laanwj commented Feb 10, 2016

Cherry-picked to 0.12 as 00ec73e

@laanwj laanwj removed the Needs backport label Feb 10, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment