For some unknown reason, local threads may be attributed to an external
process (at least when profiling on Windows). This causes some problems,
for example the CPU usage graph may show that CPU is pegged by some other
program, when it reality it is the profiled program that uses the CPU time.
Workaround by checking first, if the thread id is known to be local by the
profiler, i.e. if there were user-generated events originating from it.
This still leaves other things, such as the CPU data list, being wrong,
but the CPU data is meant to show raw TID -> PID mapping. If the source
data is wrong, there's not much to fix here.
IsThreadStringRetrieved() interface suggested that it can be used for
checking any thread state, as it had an uint64_t id parameter.
The implementation ignored this parameter and checked the status of
failure thread only. This was never an issue because the code using
this function was only checking for the failure thread state.
Fixed by renaming the function to explicitly state what it does and
removing the thread id parameter.
Previously on demand mode was determined by frame offset parameter being
greater than zero. However, if the application is not pumping frames with
FrameMark macro, the frame index will never increase and the frame offset
parameter stay at zero. It is not possible to distinguish on demand traces
from normal ones in this scenario.
Fix by explicitly saving the on demand flag in trace file and employ the
previous logic to set the flag when importing older traces.
Red and blue channels were mislabeled. Otherwise, coding and decoding was
performed correctly, as far as the color channel order described in the manual
is followed by the user.
No change to the binary protocol was made.
This enables discovery of target function names (and recursively, their
bodies), even if such function has no samples and is not present in any
callstack.
