The original intention was to ensure that either a ring buffer with data was
selected (sel >= 0 ), or there is no data left to process (activeNum == 0).
However, in an unlikely case that all ring buffers contain a PERF_RECORD_LOST
event, it is possible for the assert to fail, as there may still be data in
buffers, but at the same time no buffer would be selected. Buffer processing
advances the data pointers, so in the next loop iteration the results may be
different.
/usr/lib/gcc/x86_64-linux-gnu/9/include/cpuid.h:223:1: error: redefinition of ‘unsigned int __get_cpuid_max(unsigned int, unsigned int*)’
In file included from ../../client/TracyProfiler.cpp:108,
from ../../TracyClient.cpp:23:
/usr/lib/gcc/x86_64-linux-gnu/9/include/cpuid.h:223:1: note: ‘unsigned int __get_cpuid_max(unsigned int, unsigned int*)’ previously defined here
If call stack capture is enabled for context switch data, the 64KB buffer is
too small to work without overruns. However, if the default buffer size is
increased, then the maximum locked memory limit is hit.
This change keeps the small buffer size for all the buffers that may be used
without escalated privileges. The context switch buffer is bigger, but it does
not need to obey the limits, as the application is running as root, if it is
to be used.
Both Windows and Linux use 32-bit thread identifiers. MacOS has a 64-bit
counter, but in practice it will never overflow during profiling and no false
aliasing will happen.
These changes are only done client-side and in the network protocol. The
server still uses 64-bit thread identifiers, to enable virtual threads, etc.
Fuck knows how this is supposed to work. perf_event_open() opens the
descriptor successfully, but it produces no samples, if precise_ip is not 0.
There are no such problems on ARM (where precise_ip is 3, but maybe it is not
supported at all on that architecture, again, fuck knows if), and on AMD
perf_event_open() does not succeed when precise_ip > 0.
