Urgent: Fix parsing when a bad trace.txt exists
Created by: bjackman
TRAPpy requires that trace.txt files are created with certain events printed raw, rather than formated. When given a trace.dat, it currently creates a trace.txt that fits that requirement, then uses that for parsing.
It used to create one trace.txt with non-raw formatting, and a trace.raw.txt with raw formatting. Therefore it currently uses the presence of trace.raw.txt as a hint to suggest that the trace.txt contains non-raw formatting (as created by an older version of TRAPpy), and raises an error in this case.
However bad (non-raw) trace.txt files may have been created by the user or other tools such as Workload Automation[1].
Therefore, this patch presents a new approach to finding and creating input files:
-
Ignore trace.raw.text
-
When given a trace.dat file, convert it to a trace.trappy.txt file with all the required events formatted as raw (unless this has already been done). We can hope that this file is not created by any other tool.
-
When the trace.dat is not present but a trace.trappy.txt is present, assume that TRAPpy created the trace.trappy.txt and that the user has since deleted the corresponding trace.dat. Warn, and continue using trace.trappy.txt.
-
If only a trace.txt is present, warn the user (because there are likely non-raw events in it, in which case we cannot recover and will crash cryptically), but continue anyway, so that if the user has manually created a correctly formatted trace.txt then they can still use that.