Welcome to mirror list, hosted at ThFree Co, Russian Federation.

github.com/wolfpld/tracy.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorBartosz Taudul <wolf@nereid.pl>2022-02-14 19:55:46 +0300
committerBartosz Taudul <wolf@nereid.pl>2022-02-14 19:55:46 +0300
commit9f2ffb05ac1d224f30fc31bc8368fe2c6ec805cb (patch)
treebf27a0a024960631546d49ac327968324db200c2
parent793e6b0e29ef337e392ed4ea68691bff34e07791 (diff)
Check if memory can be allocated in a thread.
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.
-rw-r--r--client/TracyProfiler.hpp5
1 files changed, 5 insertions, 0 deletions
diff --git a/client/TracyProfiler.hpp b/client/TracyProfiler.hpp
index b5d51a2e..41121a69 100644
--- a/client/TracyProfiler.hpp
+++ b/client/TracyProfiler.hpp
@@ -473,6 +473,11 @@ public:
static tracy_force_inline void MemFreeCallstack( const void* ptr, int depth, bool secure )
{
if( secure && !ProfilerAvailable() ) return;
+ if( !ProfilerAllocatorAvailable() )
+ {
+ MemFree( ptr, secure );
+ return;
+ }
#ifdef TRACY_HAS_CALLSTACK
auto& profiler = GetProfiler();
# ifdef TRACY_ON_DEMAND