Skip to content

Fix SeccompTests bug on older kernels / add defense #14126

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

Merged
merged 1 commit into from
Oct 15, 2015

Conversation

rmuir
Copy link
Contributor

@rmuir rmuir commented Oct 15, 2015

This test failed only on a feature branch, because that feature branch has
a different build randomization script and is the only place
randomizing tests.security.manager (this test cannot run with it enabled).

On old kernels without TSYNC support, the test fails because (surprise to me) the thread that
runs the test is not the same thread that runs static initializers:
https://github.com/randomizedtesting/randomizedtesting/blob/7571489190d677969c768836e1576f4e851f83e8/randomized-runner/src/main/java/com/carrotsearch/randomizedtesting/RandomizedRunner.java#L573-L574

To fix this test (its not an issue in practice, since we do this before creating threadpools),
we just record for testing purposes that we couldn't TSYNC, and re-run the whole thing for the test thread in setUp(), failing if something goes wrong.

Also add a bunch of additional paranoia and narrow our defensive checks better here after reading
through more chrome bug reports: they don't impact us but those linux distros are too cowboy
with the backports and the spirit of the checks makes me feel better.

This test failed only on a feature branch, because that feature branch has
a different build randomization script and is the only place
randomizing tests.security.manager (this test cannot run with it enabled).

On old kernels without TSYNC support, the test fails because (surprise to me) the thread that
runs the test is not the same thread that runs static initializers:
https://github.com/randomizedtesting/randomizedtesting/blob/7571489190d677969c768836e1576f4e851f83e8/randomized-runner/src/main/java/com/carrotsearch/randomizedtesting/RandomizedRunner.java#L573-L574

To fix this test (its not an issue in practice, since we do this before creating threadpools),
we just record for testing purposes that we couldn't TSYNC, and re-run the whole thing for the test thread
in setUp(), failing if something goes wrong.

Also add a bunch of additional paranoia and narrow our defensive checks better here after reading
through more chrome bug reports: they don't impact us but those linux distros are too cowboy
with the backports and the spirit of the checks makes me feel better.
@rmuir rmuir added the >test Issues or PRs that are addressing/adding tests label Oct 15, 2015
@rjernst
Copy link
Member

rjernst commented Oct 15, 2015

LGTM

rmuir added a commit that referenced this pull request Oct 15, 2015
Fix SeccompTests bug on older kernels / add defense
@rmuir rmuir merged commit 0dcac14 into elastic:master Oct 15, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>test Issues or PRs that are addressing/adding tests
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants