When drmemtrace tracing is done with -trace_after_instrs enabled, the timestamp in the trace buffer at thread-init is set to the then timestamp, but trace entries start pouring in only after the specified count of instrs have passed. This introduces a gap in the first and second timestamp in the trace, which is directly proportional to the requested -trace_after_instrs value.
Sounds like the timestamp solutions involving freezing or using restart timestamps for windows #6104 just need to include this delayed-trace case. Also xref the original frozen timestamps in #2039 and #5021.
When drmemtrace tracing is done with -trace_after_instrs enabled, the timestamp in the trace buffer at thread-init is set to the then timestamp, but trace entries start pouring in only after the specified count of instrs have passed. This introduces a gap in the first and second timestamp in the trace, which is directly proportional to the requested -trace_after_instrs value.
For a
simple_app
trace collected using:grepping for timestamps in the view tool output shows the diff.