You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
StringTable::Erase() appears to leak memory. I detected this by running ./build/unittest -tc=StringName -sc=Creation under a memory leak detector. StringTable::Reclaim() also leaks because it uses StringTable::Erase()
Expected behaviour
No memory leak.
Steps to reproduce
Enable sanitizers when creating the build directory. Note: be aware that cmake does not change CXXFLAGS or LDFLAGS for an already populated build directory.
I believe your surmise to be correct. The StringTable maps interned string hashes to string data, which is stored in an equivalent manner to a C-style flexible array member (the StringName::StringData structure is used as a header for the allocated string character data). It does look like I missed a deletion of that string data when erasing a string from the table, though that technically leaves dangling references if erasing a string with a non-zero refcount (i.e. outside of Reclaim).
If interested in fixing this, the allocated string data should be freed in Reclaim() before calling Erase(), and the Erase method ideally made private to the class.
Observed behaviour
StringTable::Erase()
appears to leak memory. I detected this by running./build/unittest -tc=StringName -sc=Creation
under a memory leak detector.StringTable::Reclaim()
also leaks because it usesStringTable::Erase()
Expected behaviour
No memory leak.
Steps to reproduce
Enable sanitizers when creating the build directory. Note: be aware that cmake does not change CXXFLAGS or LDFLAGS for an already populated build directory.
make -j2 -C build-sanitize/
./build-sanitize/unittest -tc=StringName -sc=Creation
My pioneer version (and OS): 97d7be6 (and Fedora release 39)
Notes
Memory is allocated here:
pioneer/src/core/StringName.cpp
Lines 56 to 67 in 97d7be6
I think memory is leaked here:
pioneer/src/core/StringName.cpp
Lines 134 to 154 in 97d7be6
Sanity check: you allocate memory via
std::malloc()
, but I see precisely 0 occurrences of "free" in StringName.h or in StringName.cpp@Web-eWorks , you wrote the code. The code is complicated. I am not sure I understand it. Can you confirm?
The text was updated successfully, but these errors were encountered: