Wrong number of instructions in the trace header

[MCher]

I see that "trace_reader -header" reports implausible results. Within qemu trace_stop reports almost 100M instructions written to trace, which results in a 6GB file, which is plausible. The header says: Number of instructions: 0.  In another instance the passing trace is more than twice the size of the failing trace (4GB vs 2GB), but the header in the passing trace claims one-tenth the number of instructions (4M) of the failing trace.  So 1K per instruction is unrelistic.

A known bug? Something I've done wrong? Most importantly, is the resulting trace usable or somehow corrupted?.

  --Mike

[Noah]

Note that the 'Number of instructions' reported by trace_reader is not
based on the trace file header -- this value is not actually stored
anywhere in the trace. Instead, it is computed based on the size of
the trace index file (generated with the -createindex option), which
contains an 8-byte offset for each instruction.

In your first case, it's most likely you didn't generate the index
file. In the second case, it's hard to know for sure what's going on
without actually looking at the files. It's possible that one or both
of your traces is corrupt, or your index files are stale (this could
happen, for instance, if you generated this file then subsequently
overwrote the original trace). Try (re-)running:

% trace_reader -trace <trace file> -createindex

on each of your trace files, and see if the output appears more
reasonable.

-- Noah

[MCher]

Ah, yes; indexing fixed it up. Seems a good case for a diag message:
"index missing or older than the trace -- please re-index". Thanks.
--Mike