Omitting --per-thread leads to split traces (and other weird behavior)

[Lamoreauxaj]

As of #234 (when merged), --per-thread will be disabled sometimes even when not running with -multi-thread. However this means that a single snapshot can contain outdated data if a program switched CPUs. For example see the following traces:

The first image at the start zoomed in looks like this:

Both of these have large gaps in time between two parts of the trace because the data was stored in two separate buffers. Additionally the first image also has a decode error with pid of 0, and a cbr event with a unrealistic timestamp and incorrect pid.

Some potential changes could be made here. This issue is just to document this and lead to potential future investigation.

• magic-trace could always run with --per-thread if perf no longer fails to mmap extra events with this flag.
• magic-trace could detect that this single trace included multiple CPUs and instead only take the last contiguous chunk of data from the last CPU the process was running on when snapshotted. This would prevent the split traces even without --per-thread.
• magic-trace could filter the decode errors with pid of 0. It should be investigated why perf outputs these at all.
• magic-trace could try to detect invalid pids to eliminate that extraneous cbr event or figure out why perf gave this event at all.