-
Notifications
You must be signed in to change notification settings - Fork 561
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
i#6354 test: Verify one CPU ID per stream with MAP_TO_RECORDED #6355
base: master
Are you sure you want to change the base?
i#6354 test: Verify one CPU ID per stream with MAP_TO_RECORDED #6355
Conversation
Added check to verify that output stream's CPU ID matches the CPU ID markers seen in the trace. Issue: #6354
@@ -391,6 +391,13 @@ if (X86 AND X64 AND ZIP_FOUND) | |||
add_test(NAME tool.scheduler_launcher | |||
COMMAND scheduler_launcher -trace_dir ${trace_dir}) | |||
set_tests_properties(tool.scheduler_launcher PROPERTIES TIMEOUT ${test_seconds}) | |||
|
|||
set(trace_dir_2 | |||
"${PROJECT_SOURCE_DIR}/clients/drcachesim/tests/drmemtrace.schedtest.x64") |
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.
Since the issue seems to be that there is an empty thread in here maybe we don't want to check in this test data but rather prevent future empty traces. Maybe add an invariant check that a (non-filtered) trace has at least one instruction, too.
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 created PR #6356 to attempt to do this but don't have a good test case: maybe you could test it in your tracing setup if that reliably generates this near-empty thread?
Tightens the normal-mode output rule to discard a thread with no instructions (keeping the no-data check for i-filtered modes). Adds the scheduler_launcher CPU check from PR #6355. It is not easy to create a test with a thread that reliably executes zero instructions yet still outputs some data. I added an invariant check for a zero-instruction thread and confirmed it fires on the trace in PR #6355: ``` $ bin64/drrun -t drcachesim -simulator_type invariant_checker -indir ~/tmp/drmemtrace.schedtest.x64 Trace invariant failure in T85300 at ref # 12 (0 instrs since timestamp 13341391214912820): An unfiltered thread should have at least 1 instruction ``` Issue: #6354
This issue is mostly resolved with #6356 but I still ran into a (very rare) failure. I have added a test trace where the threads have non-zero instructions, but we still see this failure. |
I put the analysis into the bug proper: #6354 (comment) |
Tightens the normal-mode output rule to discard a thread with no instructions (keeping the no-data check for i-filtered modes) and expands the empty-thread behavior to include regular exit runs and not just detach. Adds the scheduler_launcher CPU check from PR #6355. It is not easy to create a test with a thread that reliably executes zero instructions yet still outputs some data. I added an invariant check for a zero-instruction thread and confirmed it fires on the trace in PR #6355: ``` $ bin64/drrun -t drcachesim -simulator_type invariant_checker -indir ~/tmp/drmemtrace.schedtest.x64 Trace invariant failure in T85300 at ref # 12 (0 instrs since timestamp 13341391214912820): An unfiltered thread should have at least 1 instruction ``` Issue: #6354
…th-map_to_recorded
Added check to verify that output stream's CPU ID matches the CPU ID markers seen in the trace.
Issue: #6354