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.
Renamed TRACY_NO_SYS_TRACE -> TRACY_NO_SYSTEM_TRACING to match the
build flag name. Unlike the meson logic, the CMake logic directly
maps the option name to the build flag that is injected. With the
mismatched name, the flag wasn't being properly applied.
Added TRACY_TIMER_FALLBACK option to expose the same-named flag.
Moved signal.h include to get sigaction definition that was missing when
TRACY_NO_CALLSTACK was defined.
Retrieval of the descriptor has to be performed in a single step. Finding out
what is missing and then downloading in bulk is not possible, as libbacktrace
caches the returned descriptors.
Build identifiers stored in vectors are searched linearly. While not optimal,
this is enough for a basic implementation. In the future binary search option
may be explored, to see if it is worthwhile. Possible gains wouldn't be
significant, due to relatively small amount of debug info modules to handle.
Debug info descriptor requests that have not yet been checked for (i.e. not in
the s_di_known vector) are stored in the s_di_pending vector. When a check is
performed from within a libbacktrace callback handler, there are some unknown
problems with downloading data. Hence, the download process is delayed to be
performed at a later time. The debug info descriptors retrieval can be then
repeated.
/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
'program_invocation_short_name' is Linux-specific; other OSs such as
macOS do not support it.
Fixes build break on macOS 12.2 with _GNU_SOURCE defined.
Consider running the following code with operator new and delete overloaded to
track allocations with call stacks:
std::thread( []({ thread_local std::string str; });
Each call stack requires a memory allocation to be performed by the profiler,
to make the stack available at a later time. When the thread is created, the
TLS block is initialized and the std::string buffer can be allocated. To track
this allocation, rpmalloc has to be initialized. This initialization also
happens within the TLS block.
Now, when the thread exits, the heap managed by rpmalloc may be released first
during the TLS block destruction (and if the destruction is performed in
reverse creation order, then it *will* be destroyed first, as rpmalloc was
initialized only after the std::string initialization, to track the allocation
performed within). The next thing to happen is destruction of std::string and
release of the memory block it contains.
The release is tracked by the profiler, and as mentioned earlier, to save the
call stack for later use, a memory allocation is needed. But the allocator is
no longer available in this thread, because rpmalloc was released just before!
As a solution to this issue, profiler will detect whether the allocator is
still available and will ignore the call stack, if it's not. The other
solution is to disable the rpmalloc thread cleanup, which may potentially
cause leak-like behavior, in case a large number of threads is spawned and
destroyed.
Note that this is not a water-tight solution. Other functions will still want
to allocate memory for call stacks, but it is rather unlikely that such calls
would be performed during TLS block destruction. It is also possible that the
event queue will run out of allocated space for events at this very moment,
and in such a case the allocator will also fail.
