Skip to content

Conversation

maflcko
Copy link
Member

@maflcko maflcko commented Jul 24, 2019

To run CheckBlockIndex also on failure was changed in 613c46f and uncovered the bug #16444.

This pull restores the previous behavior, where CheckBlockIndex was only called on success (return true in

CheckBlockIndex(chainparams.GetConsensus());
) and never on failure.

@jamesob
Copy link
Contributor

jamesob commented Jul 24, 2019

ACK fa21995

This restores the original behavior before #16194. Wonder why the failures we saw were intermittent, though.

Copy link
Contributor

@ryanofsky ryanofsky left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a stack trace, or any clue why CheckBlockIndex is failing?

utACK fa21995. It does make sense to restore the previous behavior and remove the extra CheckBlockIndex call as a workaround.

@maflcko maflcko changed the title validation: Run CheckBlockIndex only on success (Fixup) WIP: validation: Run CheckBlockIndex only on success (Fixup) Jul 24, 2019
@maflcko maflcko added this to the 0.19.0 milestone Jul 24, 2019
@maflcko
Copy link
Member Author

maflcko commented Jul 24, 2019

Wonder why the failures we saw were intermittent, though.

Yes, I don't really like my change. Ideally CheckBlockIndex passes any time (even on failure).

@maflcko
Copy link
Member Author

maflcko commented Jul 24, 2019

Closing for now. Hoping someone else comes up with a better fix.

@maflcko maflcko closed this Jul 24, 2019
@maflcko maflcko deleted the 1907-validationCheckBlockIndexSuccess branch July 24, 2019 21:05
@maflcko maflcko changed the title WIP: validation: Run CheckBlockIndex only on success (Fixup) validation: Run CheckBlockIndex only on success for now Aug 23, 2019
@maflcko maflcko restored the 1907-validationCheckBlockIndexSuccess branch August 23, 2019 22:41
@maflcko
Copy link
Member Author

maflcko commented Aug 23, 2019

A lot of the test runs are failing due to this and we are blindly resetting each failing test run, thus missing actual test failures. We need to either fix the underlying bug or restore the previous behavior.

@maflcko maflcko reopened this Aug 23, 2019
@DrahtBot
Copy link
Contributor

DrahtBot commented Aug 24, 2019

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

Reviewers, this pull request conflicts with the following ones:

  • #16324 (Get cs_main out of the critical path in ProcessMessages by TheBlueMatt)
  • #16323 (Call ProcessNewBlock() asynchronously by TheBlueMatt)

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.

@maflcko maflcko force-pushed the 1907-validationCheckBlockIndexSuccess branch from fa21995 to fa5ad3e Compare August 24, 2019 11:26
Copy link
Contributor

@ryanofsky ryanofsky left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

utACK fa5ad3e. Control flow simplified a little since last review, just moving CheckBlockIndex calls after returns.


if (!accepted) {
if (first_invalid) *first_invalid = header;
return false;
}
::ChainstateActive().CheckBlockIndex(chainparams.GetConsensus());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe comment that check can fail if header is not accepted. Could quote or link to #16444 (comment)

@jamesob
Copy link
Contributor

jamesob commented Aug 27, 2019

ACK fa5ad3e

@TheBlueMatt
Copy link
Contributor

I'd really prefer we at least attempt to fix InvalidateBlock to fix the issue in #16444 (comment) before we jump to removing CheckBlockIndex. Ideally we'd capture this case in CheckBlockIndex directly.

@sdaftuar
Copy link
Member

I'd really prefer we at least attempt to fix InvalidateBlock to fix the issue in #16444 (comment) before we jump to removing CheckBlockIndex. Ideally we'd capture this case in CheckBlockIndex directly.

Agreed -- please see #16849.

@maflcko maflcko closed this Sep 15, 2019
@maflcko maflcko deleted the 1907-validationCheckBlockIndexSuccess branch September 15, 2019 14:07
laanwj added a commit that referenced this pull request Sep 16, 2019
…c_invalidateblock

fae961d test: Establish only one connection between nodes in rpc_invalidateblock (MarcoFalke)

Pull request description:

  Headers and block sync should eventually converge to the same result, regardless of whether the peers treat each other as "inbound" or "outbound".

  `connect_nodes_bi` has been introduced as a (temporary?) workaround for bug #5113 and #5138, which has long been fixed in #5157 and #5662.

  Thus remove the `connect_nodes_bi` workaround from the rpc_invalidateblock test.

  Conveniently, this also closes #16453. See #16444 (comment) for rationale

ACKs for top commit:
  laanwj:
    ACK fae961d

Tree-SHA512: b3614c66a205823df73f64d19cacfbec269beb5db52ff79004d746e17d7c0dfb43ab9785fdddc97e2a76fe76286c8c605b34df3dda4a2bf5be035f01169ae89a
sidhujag pushed a commit to syscoin/syscoin that referenced this pull request Sep 16, 2019
…s in rpc_invalidateblock

fae961d test: Establish only one connection between nodes in rpc_invalidateblock (MarcoFalke)

Pull request description:

  Headers and block sync should eventually converge to the same result, regardless of whether the peers treat each other as "inbound" or "outbound".

  `connect_nodes_bi` has been introduced as a (temporary?) workaround for bug bitcoin#5113 and bitcoin#5138, which has long been fixed in bitcoin#5157 and bitcoin#5662.

  Thus remove the `connect_nodes_bi` workaround from the rpc_invalidateblock test.

  Conveniently, this also closes bitcoin#16453. See bitcoin#16444 (comment) for rationale

ACKs for top commit:
  laanwj:
    ACK fae961d

Tree-SHA512: b3614c66a205823df73f64d19cacfbec269beb5db52ff79004d746e17d7c0dfb43ab9785fdddc97e2a76fe76286c8c605b34df3dda4a2bf5be035f01169ae89a
gabriel-bjg added a commit to gabriel-bjg/dash that referenced this pull request Oct 26, 2021
vijaydasmp pushed a commit to vijaydasmp/dash that referenced this pull request Dec 6, 2021
…s in rpc_invalidateblock

fae961d test: Establish only one connection between nodes in rpc_invalidateblock (MarcoFalke)

Pull request description:

  Headers and block sync should eventually converge to the same result, regardless of whether the peers treat each other as "inbound" or "outbound".

  `connect_nodes_bi` has been introduced as a (temporary?) workaround for bug dashpay#5113 and dashpay#5138, which has long been fixed in dashpay#5157 and dashpay#5662.

  Thus remove the `connect_nodes_bi` workaround from the rpc_invalidateblock test.

  Conveniently, this also closes bitcoin#16453. See bitcoin#16444 (comment) for rationale

ACKs for top commit:
  laanwj:
    ACK fae961d

Tree-SHA512: b3614c66a205823df73f64d19cacfbec269beb5db52ff79004d746e17d7c0dfb43ab9785fdddc97e2a76fe76286c8c605b34df3dda4a2bf5be035f01169ae89a
vijaydasmp pushed a commit to vijaydasmp/dash that referenced this pull request Dec 10, 2021
…s in rpc_invalidateblock

fae961d test: Establish only one connection between nodes in rpc_invalidateblock (MarcoFalke)

Pull request description:

  Headers and block sync should eventually converge to the same result, regardless of whether the peers treat each other as "inbound" or "outbound".

  `connect_nodes_bi` has been introduced as a (temporary?) workaround for bug dashpay#5113 and dashpay#5138, which has long been fixed in dashpay#5157 and dashpay#5662.

  Thus remove the `connect_nodes_bi` workaround from the rpc_invalidateblock test.

  Conveniently, this also closes bitcoin#16453. See bitcoin#16444 (comment) for rationale

ACKs for top commit:
  laanwj:
    ACK fae961d

Tree-SHA512: b3614c66a205823df73f64d19cacfbec269beb5db52ff79004d746e17d7c0dfb43ab9785fdddc97e2a76fe76286c8c605b34df3dda4a2bf5be035f01169ae89a
vijaydasmp pushed a commit to vijaydasmp/dash that referenced this pull request Dec 13, 2021
…s in rpc_invalidateblock

fae961d test: Establish only one connection between nodes in rpc_invalidateblock (MarcoFalke)

Pull request description:

  Headers and block sync should eventually converge to the same result, regardless of whether the peers treat each other as "inbound" or "outbound".

  `connect_nodes_bi` has been introduced as a (temporary?) workaround for bug dashpay#5113 and dashpay#5138, which has long been fixed in dashpay#5157 and dashpay#5662.

  Thus remove the `connect_nodes_bi` workaround from the rpc_invalidateblock test.

  Conveniently, this also closes bitcoin#16453. See bitcoin#16444 (comment) for rationale

ACKs for top commit:
  laanwj:
    ACK fae961d

Tree-SHA512: b3614c66a205823df73f64d19cacfbec269beb5db52ff79004d746e17d7c0dfb43ab9785fdddc97e2a76fe76286c8c605b34df3dda4a2bf5be035f01169ae89a
vijaydasmp pushed a commit to vijaydasmp/dash that referenced this pull request Dec 13, 2021
…s in rpc_invalidateblock

fae961d test: Establish only one connection between nodes in rpc_invalidateblock (MarcoFalke)

Pull request description:

  Headers and block sync should eventually converge to the same result, regardless of whether the peers treat each other as "inbound" or "outbound".

  `connect_nodes_bi` has been introduced as a (temporary?) workaround for bug dashpay#5113 and dashpay#5138, which has long been fixed in dashpay#5157 and dashpay#5662.

  Thus remove the `connect_nodes_bi` workaround from the rpc_invalidateblock test.

  Conveniently, this also closes bitcoin#16453. See bitcoin#16444 (comment) for rationale

ACKs for top commit:
  laanwj:
    ACK fae961d

Tree-SHA512: b3614c66a205823df73f64d19cacfbec269beb5db52ff79004d746e17d7c0dfb43ab9785fdddc97e2a76fe76286c8c605b34df3dda4a2bf5be035f01169ae89a
vijaydasmp pushed a commit to vijaydasmp/dash that referenced this pull request Dec 15, 2021
…s in rpc_invalidateblock

fae961d test: Establish only one connection between nodes in rpc_invalidateblock (MarcoFalke)

Pull request description:

  Headers and block sync should eventually converge to the same result, regardless of whether the peers treat each other as "inbound" or "outbound".

  `connect_nodes_bi` has been introduced as a (temporary?) workaround for bug dashpay#5113 and dashpay#5138, which has long been fixed in dashpay#5157 and dashpay#5662.

  Thus remove the `connect_nodes_bi` workaround from the rpc_invalidateblock test.

  Conveniently, this also closes bitcoin#16453. See bitcoin#16444 (comment) for rationale

ACKs for top commit:
  laanwj:
    ACK fae961d

Tree-SHA512: b3614c66a205823df73f64d19cacfbec269beb5db52ff79004d746e17d7c0dfb43ab9785fdddc97e2a76fe76286c8c605b34df3dda4a2bf5be035f01169ae89a
@bitcoin bitcoin locked as resolved and limited conversation to collaborators Dec 16, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants