Skip to content

Conversation

@kevkevinpal
Copy link
Contributor

Description

Motivated by this comment #31317 (comment)
I wanted to lock the temp directory like we do when we specify the -testdatadir param

Changes

Now when we run BasicTestingSetup::~BasicTestingSetup() we unlock the directory no matter what and we always delete unless -testdatadir is used

Testing

  • I've validated by both running the fuzz test runner and individual fuzz tests like so
  • FUZZ=utxo_total_supply ./build_fuzz/src/test/fuzz/fuzz -jobs=2 -workers=2
  • functional tests are passing

@DrahtBot
Copy link
Contributor

DrahtBot commented Nov 20, 2024

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

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/31328.

Reviews

See the guideline for information on the review process.
A summary of reviews will appear here.

Conflicts

No conflicts as of last run.

Copy link
Member

Choose a reason for hiding this comment

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

I think the error message was a bit incorrect. "The test executable is probably already running." may not be accurate, because a lockfile may be present when the test executable crashed, no?

Also, it may be confusing for the default case, which should never have a colliding test dir. The issue in that case would be the path collision, not that "The test executable is probably already running.".

Copy link
Contributor Author

@kevkevinpal kevkevinpal Nov 20, 2024

Choose a reason for hiding this comment

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

maybe we can update the error message to be

ExitFailure("Cannot obtain a lock on test data lock directory " + fs::PathToString(m_path_lock) + '\n' + "The directory and .lock file already exist.");

it is fine if the directory exists, we are just don't want .lock file to be present?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

updated in fe6da3744420bcbac9002ae324dfa04902aed490

@hodlinator
Copy link
Contributor

Code review 8963bc8

Think this PR might be overly paranoid.

Regardless of whether G_TEST_GET_FULL_NAME returns a value for the given test, is locking really necessary if directories are sufficiently unique (random) thanks to faaaf59 being included in the already merged #31317?

const auto rand{HexStr(g_rng_temp_path.randbytes(10))}

Should provide this many possible patterns:

$$2^{8*10} = 256^{10} \approx 1.21*10^{24}$$

Surely concurrent collisions should be practically non-existent on a given machine?

Locking is more necessary when -testdatadir is set and randomness is not included in the path.

@kevkevinpal
Copy link
Contributor Author

Code review 8963bc8

Think this PR might be overly paranoid.

Regardless of whether G_TEST_GET_FULL_NAME returns a value for the given test, is locking really necessary if directories are sufficiently unique (random) thanks to faaaf59 being included in the already merged #31317?

const auto rand{HexStr(g_rng_temp_path.randbytes(10))}

Should provide this many possible patterns:
2 8 ∗ 10 = 256 10 ≈ 1.21 ∗ 10 24

Surely concurrent collisions should be practically non-existent on a given machine?

Locking is more necessary when -testdatadir is set and randomness is not included in the path.

That is a fair point, if others agree I can close this PR. But I do think adding a lock to the directory does add a bit more robustness and protection to the test suite.

@fanquake
Copy link
Member

I think its fine to leave this as-is for now. So going to close.

@fanquake fanquake closed this Feb 20, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants