upenn-acg / det-stresstests Goto Github PK

On older machines this just tries to execute the rdrand, disregarding cpuid:

$ ./rdrand.bin
Illegal instruction (core dumped)

So how could this test work for us, since we depend on cpuid interception? (Furthermore, how could rr handle this as written? I doesn't seem to on the machines I've tried.)

Shouldn't this test be changed to check cpuid and print a different message if it reports absence of HW randomness?

Currently, we compared every test against the previous saved "expected output". This means, if our implementation changes, we end up with false positives and have to go back and manually edit or regenerate the created output files. Instead, a better scheme would involve running the test twice (or even N times) and verifying the results always match the previous outputs.

One example is the latest commit a6b29ab I commented out the mq test says it fails on DeTtrace.

On one hand, it's great adding new tests like mq since we keep a "log" of tests which we don't pass yet. On the other hand, since DetTrace relies on this repo, it makes DetTrace development harder, since we see a failure when testing our latest changes in DetTrace. How should we go about solving this?

Ideas:

1. Have DetTrace/systrace target a specific commit on det-stresstest. This way, even new tests will now break the existing testing functionality. Git submodules do this by default, so it's a natural workflow. The problem is what happens like now, when Kelly wants to add more thread tests, if Baojun has added new tests and the repository points several commits ahead, Kelly cannot easily add her tests, and we're back to the original problem.
2. Have master contain only tests that are supported by dettrace/systrace, new tests like mq are each on their own branch, which will be merged once dettrace/systrace support that test. This is awkward since dettrace and systrace are artificially gating each others tests though...
3. Learning from "(2", instead we have master which contains all the tests, DeTtrace and systrace both have a separate branch in this repo, branch dettrace and systrace, The test submodule in the DetTrace repo points to the det-stresstest branch dettrace. This way, we can add all tests to master, and simply merge the passing ones over to our branch.

Thoughts? Does "(3" sound resonable? @krs85 @wangbj

Currently the sample program open_tmpfile.c does not work inside a Docker container. Just running ./open_tmpfile.c fails with Operation Not Supported. Everything works fine outside the container, with/without dettrace.