-
Notifications
You must be signed in to change notification settings - Fork 38.7k
test: exempt previous release binaries from valgrind #27228
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 CoverageFor detailed information about the code coverage, see the test coverage report. ReviewsSee the guideline for information on the review process.
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update. ConflictsNo conflicts as of last run. |
|
Example failure: |
|
What about |
|
For some reason that didn't fail. So an alternative could be to fix the ones that break for me, but not sure if that's worth the effort. |
|
It might be more useful to disable them all here for the compat test only and instead run the full test suite on the guix binaries on release tags. |
|
This seems arbitrary, and the |
|
I presume the reason is that the valgrind supp file is not valid for previous releases. Actually, it might not even be valid for guix-compiled binaries on master? |
d1f6e7e to
5a0f71a
Compare
|
I disabled all tests that use previous releases under valgrind. Also tried a different error message.
I added a code comment and some more context to the commit to help answer that, if anyone does want to run these under valgrind. |
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.
nit: Might be a smaller diff, and more clear, if this was put into the skip_if_no_previous_releases function?
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.
Thought about that, but there may be other (future) tests we want to skip under valgrind (e.g. things that use a brittle dependency). Conversely, since some tests do work, maybe someone wants to enable one later.
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.
Yea. If they are all going to be disabled in that case any way, no point duplicating all this logic and commentary.
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.
(future) tests we want to skip under valgrind
Let's not worry about unwritten tests, that we apparently might not want to test properly for some arbitrary reason.
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 was also thinking existing tests, e.g. I haven't been able to run valgrind with BDB configured (didn't try very hard).
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 was also thinking existing tests, e.g. I haven't been able to run valgrind with BDB configured (didn't try very hard).
It definitely works. The native valgrind CI job is already configured to run with BDB.
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.
Conversely, since some tests do work, maybe someone wants to enable one later.
If you want to make it more fine grained, it could make sense to move the check to the test_node and condition it on the version number?
BDB
Good point. I also can't run --valgrind with BDB on my system. Which raises the question how many settings we want --valgrind to be supported under.
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.
Which raises the question how many settings we want --valgrind to be supported under.
I thnk currently the only realistic place we can fully support Valgrind, is within the CI system, where things like BDB are working, and we can more easily control settings and suppressions. Outside of that, things may work fine, or may not at all, depending on the system where it is being run.
luke-jr
left a comment
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.
Approach NACK: Would prefer to run all the tests, but only execute the older binaries without Valgrind (ie, still run the current version with Valgrind)
|
Running the old binaries without valgrind makes sense. I'll see if I can figure out how. |
5a0f71a to
3eb9bd7
Compare
|
lgtm ACK 3eb9bd7ccae6366eb548fa79cbdf78816354dc60 |
|
Changed this PR so that it now runs the old binaries without valgrind, rather than skipping the backward compatibility test entirely. |
This is unnecessary and caused test failures. The backward compatibility tests are meant to find regressions in the current codebase, not to detect bugs in older releases.
3eb9bd7 to
850670e
Compare
|
Rebased. |
|
lgtm ACK 850670e |
…rind 850670e test: don't run old binaries under valgrind (Sjors Provoost) Pull request description: Some, but not all, backward compatibility tests fail for me and it seems useless to run old release binaries under valgrind anyway. Can be tested by running `test/functional/feature_txindex_compatibility.py --valgrind --timeout-factor=10` with and without this PR. — The previous version of this PR disabled these test entirely under valgrind. The current version does run the test, but starts the old binaries without valgrind. ACKs for top commit: maflcko: lgtm ACK 850670e Tree-SHA512: ebdf461083f1292528e6619963b910f486b60b4f6b183f0aea2c8bfcafa98caeb204d138700cd288450643bcec5e49e12b89f2f7537fccdf495a2a33acd9cea0
Some, but not all, backward compatibility tests fail for me and it seems useless to run old release binaries under valgrind anyway.
Can be tested by running
test/functional/feature_txindex_compatibility.py --valgrind --timeout-factor=10with and without this PR.—
The previous version of this PR disabled these test entirely under valgrind. The current version does run the test, but starts the old binaries without valgrind.