LOG: Consistent naming between CRASH, PERF, and Verbose logs.

[kevindeland]

Currently, the CRASH and PERF logs are named differently. This makes it difficult when sorting through log files side-by-side to find the source of a crash.

For example, if I want to look for the source of a crash found in the file CRASH_20181118_195829_6129002223_release_2.7.7.1.txt I should theoretically be able to sort through the PERF log files by date until I get to 20181118. However, the PERF logs are named thusly:

PERF_RoboTutor_release_sw_2.7.7.1_000000_2018.11.10.08.43.11_6118002316.json

The session ID is put before the date, so the order is different.

Two possible solutions:

1. Add session ID to CRASH.

• prevents code-refactor for PERF log data analysis.

2. Move session ID to end of PERF.

• possibly makes more sense

• may require code-refactor for parsing PERF logs.

[kevindeland]

EXAMPLE: I want to find the source for these CRASH logs.

But when I go to look through the PERF logs, they are ordered by Session ID.

[kevindeland]

Decided Solution
Change CRASH log name to match naming scheme of PERF Log.

Code Locations

• cmu.xprize.robotutor.tutorengine.util.CrashHandler.java : search for "logFile"
• RoboTutor.java : search for "PERF_" to find naming convention.

Acceptance Criteria

• Write code that artificially throws an Exception.
• Run RoboTutor and wait for the crash.
• Navigate to the /sdcard/Download/ folder and confirm that the files have matching conventions.

Other considerations

• It would be best if the CRASH and the PERF used the exact same date. I'm not sure if this is currently the case.

[kevindeland]

A temporary alternative for renaming PERF files to remove session number.

ls | sed -n 's/PERF_\(.*\)_2018\.\(.*\)/mv "PERF_\1_2018.\2" "PERF_\2"/p' | sh

[JackMostow]

Sure, name crash logs more like session logs, but include both crash time and session id, because crash time > session start time, and in case it's possible to have >1 crash during the same session.

And include session serial number in session id to detect data loss as well as combat clock resets.

BTW, omitting crash time and parameter values from the contents of crash logs makes it easy to count the number of instances of a given type of crash, because their contents (message + stack trace) are identical. That's how I was able use to an Excel pivot table to count crash type frequency.