ConvertToStructuredArray() relies on its caller to deallocate the heap-allocated object pointer it returns. One of its call-sites, in GetRenumberedThreadIds(), fails to deallocate causing a memory/resource leak. This fix aims to fix this issue via RAII-style clean up.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
lldb/source/Plugins/InstrumentationRuntime/TSan/InstrumentationRuntimeTSan.cpp | ||
---|---|---|
226 | Function creating heap-based allocation | |
229–231 | Allocation of the leaked entity | |
263 | Delete the heap-allocated resource via RAII on function exit. | |
286 | Result is set here. Note, at this point, there's no continued dependency on the StructuredData::Array object returned by the call to ConvertToStructuredArray(), and that object does not need to persist. |
lldb/source/Plugins/InstrumentationRuntime/TSan/InstrumentationRuntimeTSan.cpp | ||
---|---|---|
226 | Could this return a unique_ptr instead? |
So any functions that are "StructureData::<class> *" raw pointers in this source code should switch over to returning on of the StruturedData definitions from StructuredData.h:
class StructuredData { typedef std::shared_ptr<Object> ObjectSP; typedef std::shared_ptr<Array> ArraySP; typedef std::shared_ptr<Integer> IntegerSP; typedef std::shared_ptr<Float> FloatSP; typedef std::shared_ptr<Boolean> BooleanSP; typedef std::shared_ptr<String> StringSP; typedef std::shared_ptr<Dictionary> DictionarySP; typedef std::shared_ptr<Generic> GenericSP;
lldb/source/Plugins/InstrumentationRuntime/TSan/InstrumentationRuntimeTSan.cpp | ||
---|---|---|
226 | This should return StructureData::ArraySP. Look at the other usages of this function where they will eventually put the result into a dictionary | |
350 | If we make ConvertToStructuredArray return a ArraySP, then this code would change |
I am going to clean up the code in the entire file where raw pointers should be shared_ptr (because they get cast to shared_ptr anyways). Also planning to convert the naked new and the 2-step shared_ptr creation to make_shared<> ; the former is less-safe for potential leaks, and the latter is strictly better.
@JDevlieghere Yes, some of these planned raw pointer changes could be unique_ptr, but these types are already typedef-ed in StructuredData.h as shared_ptr and I'd like to preserve the style in the absence of specific know performance issues in this code.
Yup, any smart pointer works for me 👍
lldb/source/Plugins/InstrumentationRuntime/TSan/InstrumentationRuntimeTSan.cpp | ||
---|---|---|
38 | We don't do this anywhere in LLVM, and the coding guidelines explicitly state that "we prefer to explicitly prefix all identifiers from the standard namespace with an “std::” prefix". [1] This isn't exactly the same as using namespace std but I would argue the sentiment still holds. [1] https://llvm.org/docs/CodingStandards.html#do-not-use-using-namespace-std |
Address the style issue by removing "using", and specifying std:: namespace explicitly.
Note, lldb style guide does not appear to prohibit the import of individual members from another namespace in a non-header file. Nevertheless, fixing the style for consistency.
We don't do this anywhere in LLVM, and the coding guidelines explicitly state that "we prefer to explicitly prefix all identifiers from the standard namespace with an “std::” prefix". [1] This isn't exactly the same as using namespace std but I would argue the sentiment still holds.
[1] https://llvm.org/docs/CodingStandards.html#do-not-use-using-namespace-std