-
Notifications
You must be signed in to change notification settings - Fork 38.7k
test: locking -testdatadir when not specified and then deleting lock and dir at end of test #31328
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. Code Coverage & BenchmarksFor details see: https://corecheck.dev/bitcoin/bitcoin/pulls/31328. ReviewsSee the guideline for information on the review process. ConflictsNo conflicts as of last run. |
src/test/util/setup_common.cpp
Outdated
There was a problem hiding this comment.
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.".
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
updated in fe6da3744420bcbac9002ae324dfa04902aed490
d599673 to
fe6da37
Compare
…and dir at end of test
fe6da37 to
8963bc8
Compare
|
Code review 8963bc8 Think this PR might be overly paranoid. Regardless of whether const auto rand{HexStr(g_rng_temp_path.randbytes(10))}Should provide this many possible patterns: Surely concurrent collisions should be practically non-existent on a given machine? Locking is more necessary when |
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. |
|
I think its fine to leave this as-is for now. So going to close. |
Description
Motivated by this comment #31317 (comment)
I wanted to lock the temp directory like we do when we specify the
-testdatadirparamChanges
Now when we run
BasicTestingSetup::~BasicTestingSetup()we unlock the directory no matter what and we always delete unless-testdatadiris usedTesting
FUZZ=utxo_total_supply ./build_fuzz/src/test/fuzz/fuzz -jobs=2 -workers=2