Skip to content

Conversation

jonatack
Copy link
Member

@jonatack jonatack commented Sep 24, 2021

This is the same approach as for the addpeeraddress test in test/functional/rpc_net.py in commit 869f136.

The probability of collision when adding an addrman entry is expected to be 1/2^16 = 1/65536 for an address from a different /16. This change hopes to avoid these collisions by adding 1 tried entry before adding 1 new table one, instead of 2 tried entries followed by 2 new entries, which appears to have caused a collision in the CI.

To verify the regression test still fails when expected:

  • git checkout 181a120 && git cherry-pick ef242f5
  • recompile bitcoind
  • git checkout this branch and run test/functional/feature_asmap.py. Expected output:
AssertionError: Unexpected stderr bitcoind: ./addrman.h:739: void CAddrMan::Check() const: Assertion `false' failed. !=

Closes #23078.

Co-authored-by: Martin Zumsande mzumsande@gmail.com

@jonatack
Copy link
Member Author

It seems the probability of collision when adding a second tried address with a different /16 may be 1/2^16 = 1/65536, which may be an acceptable level of failure in the absence of a deterministic addrman. The original versions of #22831 with a peers.dat file are also free of non-determinism.

@DrahtBot
Copy link
Contributor

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

Conflicts

Reviewers, this pull request conflicts with the following ones:

  • #22872 (log: improve checkaddrman logging with duration in milliseconds by jonatack)

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.

@mzumsande
Copy link
Contributor

The easiest way to prevent intermittent fails might be to only add 1 address to tried and then new (total 2), I don't think there need to be more addresses present for the regression test to work.
assert_equal(len(addrs), 4) could also fail, I think in an extremely unlikely edge case there may even only be 2 addrs present (A1 -> new, A1 new -> tried, A2 ->new , A2 -> tried collision, so it stays in new, A3 ->new collision with A2, A4 ->new collision with A2)

@jonatack
Copy link
Member Author

Makes sense. IIRC the test didn't fail with only one tried entry, but I will retest that. Failing which, can remove the added assert here. A possible alternative or supplementary test would be a tiny hardcoded 2+2 peers.dat directly in the test file.

@jonatack jonatack changed the title test: assert on result instead of log in asmap-addrman test test: avoid non-determinism in asmap-addrman test Sep 24, 2021
@jonatack
Copy link
Member Author

@mzumsande you are correct, thank you for making me re-verify this. Updated this patch. It is now the same approach as the addpeeraddress test in test/functional/rpc_net.py in commit 869f136.

@jonatack jonatack force-pushed the asmap-addrman-test-assert-on-result-instead-of-log branch from 94eaec1 to 78d27d1 Compare September 24, 2021 17:02
@mzumsande
Copy link
Contributor

Code Review ACK 78d27d1

Just for the sake of a minimal regression test, we wouldn't even need the second address in new, but I think it's better to include it.

@jonatack
Copy link
Member Author

jonatack commented Sep 24, 2021

Oh, just noticed I forgot to update the comment above the change. Done.

This is the same approach as for the addpeeraddress test in
`test/functional/rpc_net.py` in commit 869f136.

The probability of collision when adding an addrman entry is
expected to be 1/2^16 = 1/65536 for an address from a different /16.

This change hopes to avoid these collisions by adding 1 tried entry
before adding 1 new table one, instead of 2 tried entries followed
by 2 new entries, which appears to have caused a collision in the CI.

To verify the regression test stills fails when expected:

- git checkout 181a120 && git cherry-pick ef242f5
- recompile bitcoind
- git checkout this branch and run test/functional/feature_asmap.py. Expected output:

```
AssertionError: Unexpected stderr bitcoind: ./addrman.h:739: void CAddrMan::Check() const: Assertion `false' failed. !=
```

Co-authored-by: Martin Zumsande <mzumsande@gmail.com>
@jonatack jonatack force-pushed the asmap-addrman-test-assert-on-result-instead-of-log branch from 78d27d1 to 5825b34 Compare September 24, 2021 20:02
@hebasto
Copy link
Member

hebasto commented Sep 25, 2021

CI error fixed in #23089.

Does this PR fix the feature_asmap.py functional test on Windows? See:

EXCLUDE_TESTS: 'feature_addrman.py,feature_asmap.py'

@mzumsande
Copy link
Contributor

Re-ACK 5825b34

@maflcko maflcko merged commit ba3f0b2 into bitcoin:master Sep 27, 2021
@jonatack jonatack deleted the asmap-addrman-test-assert-on-result-instead-of-log branch September 27, 2021 07:46
sidhujag pushed a commit to syscoin/syscoin that referenced this pull request Sep 27, 2021
5825b34 test: avoid non-determinism in asmap-addrman test (Jon Atack)

Pull request description:

  This is the same approach as for the addpeeraddress test in `test/functional/rpc_net.py` in commit 869f136.

  The probability of collision when adding an addrman entry is expected to be 1/2^16 = 1/65536 for an address from a different /16.  This change hopes to avoid these collisions by adding 1 tried entry before adding 1 new table one, instead of 2 tried entries followed by 2 new entries, which appears to have caused a collision in the CI.

  To verify the regression test still fails when expected:

  - `git checkout 181a120 && git cherry-pick ef242f5`
  - recompile bitcoind
  - git checkout this branch and run `test/functional/feature_asmap.py`. Expected output:

  ```
  AssertionError: Unexpected stderr bitcoind: ./addrman.h:739: void CAddrMan::Check() const: Assertion `false' failed. !=
  ```

  Closes bitcoin#23078.

  Co-authored-by: Martin Zumsande <mzumsande@gmail.com>

ACKs for top commit:
  mzumsande:
    Re-ACK 5825b34

Tree-SHA512: eb6624a196fa5617c84aad860c8f91e8a8f60fc9fe2d7168facc298ee38db5e93b7e988e11c2ac1b399dc2c6b8fad360fb10bdbf10e598a1878300388475a200
maflcko pushed a commit to bitcoin-core/gui that referenced this pull request Sep 27, 2021
…ve Windows

4befc8f ci: Enable feature_asmap.py test on native Windows (Hennadii Stepanov)

Pull request description:

  This PR is a [follow up](bitcoin/bitcoin#23084 (comment)) of #23084. It enables the `feature_asmap.py` functional test which is fixed in #23084.

ACKs for top commit:
  MarcoFalke:
    cr ACK 4befc8f

Tree-SHA512: bdd813f0a360b7acc4be764bb402de91be519282c107ad1952f5dccd1171e39cca0e4ce11b6257de1135ddde8deb8465d1dccf29450a1cd16f6894ed86c67cb8
@jonatack
Copy link
Member Author

CI error fixed in #23089.

Does this PR fix the feature_asmap.py functional test on Windows? See:

EXCLUDE_TESTS: 'feature_addrman.py,feature_asmap.py'

Thanks @hebasto. I didn't realize they were disabled on Windows.

Fabcien pushed a commit to Bitcoin-ABC/bitcoin-abc that referenced this pull request Oct 24, 2022
Summary:
```
The probability of collision when adding an addrman entry is
expected to be 1/2^16 = 1/65536 for an address from a different /16.

This change hopes to avoid these collisions by adding 1 tried entry before adding 1 new table one, instead of 2 tried entries followed by 2 new entries, which appears to have caused a collision in the CI.
```

Backport of [[bitcoin/bitcoin#23084 | core#23084]].

Test Plan:
In a loop:
  ./test/functional/test_runner.py feature_asmap

Reviewers: #bitcoin_abc, PiRK

Reviewed By: #bitcoin_abc, PiRK

Differential Revision: https://reviews.bitcoinabc.org/D12363
@bitcoin bitcoin locked and limited conversation to collaborators Oct 30, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

ci: failure in feature_asmap
6 participants