rudjigames / rmem Goto Github PK

The callstack hashing system is not thread-safe. The caching structures themselves are not strictly thread-safe, but I don't think it is an issue in practice. There is the possible race condition when adding a new entry and you could end up with some mismatched entries in the cache. But I think the most common outcome is that the cache is less efficient because you could get some garbage entries in there is two threads wrote into the same stackIndex at the exact same time.

The problem I have encountered is the order the stacktraces are written to the data stream is not guaranteed.

Thread A encounters new callstack and records it in the cache
Context switch occurs and Thread B becomes active
Thread B encounters the same callstack and finds it in the cache
Thread B, having found the callstack cached, just writes the hash to the output stream.
Context switch occers and Thread A becomes active
Thread A writes the full callstack to the output stream.

The MTuner tool will error during reading when it encounters the hash written by Thread B because it hasn't encountered the full stack from Thread A first.

My local workaround for this is to write a placeholder value into (0xffffffff) into m_stackTraceHashes when adding a new entry and then replace it with the correct hash value after I have written to the output stream.

Hi

I'm working on building rmem as part of a CMake project compiled with clang-cl on Windows, but error: "Unsupported compiler!" lights up at rmem_platform.h:132

Any chance this build configuration (clang-cl/Windows) will be supported?

Duplicated from here because I realized I should file an issue:

I'm getting the following runtime check exception in debug builds of my app, when MemoryHook::alloc is called:

Run-Time Check Failure #2 - Stack around the variable 'tmpBufferPtr' was corrupted.

It looks like addStackTrace_new still tries to write sizeof(uintptr_t)*_numFrames to a stack allocated buffer that's now only the fixed 96 bytes.

I would like to point out that an identifier like “__RMEM_HOOK_H__” does eventually not fit to the expected naming convention of the C++ language standard.
Would you like to adjust your selection for unique names?