[Lldb-commits] [PATCH] D141318: [lldb] Store shared pointers in DieToTypePtr map instead of raw pointers
Jonas Devlieghere via Phabricator via lldb-commits
lldb-commits at lists.llvm.org
Mon Jan 9 13:49:15 PST 2023
JDevlieghere added a comment.
In D141318#4037640 <https://reviews.llvm.org/D141318#4037640>, @augusto2112 wrote:
> In D141318#4037557 <https://reviews.llvm.org/D141318#4037557>, @JDevlieghere wrote:
>
>> In D141318#4037541 <https://reviews.llvm.org/D141318#4037541>, @augusto2112 wrote:
>>
>>> I changed the value of the map to a shared pointer, but could change it to a weak pointer instead, not sure which is more appropriate in this case.
>>
>> I was about to ask the same thing. What currently determines the lifetime of the stored objects?
>
> Currently, a bunch of functions in `DWARFASTParserClang` and `SymbolFileDWARF` will create a new `Type` SP, store the underlying pointer in the map, and return the SP. The lifetime of the stored objects varies by whatever the caller does with the returned SP. Looking at some of the callers, I don't see a very clear pattern, most seem to use it and immediately discard it (use after free when we look up the same type again and the underlying pointer is still in the map), but at least one caller (`SymbolFileDWARF::ResolveType`) returns the underlying pointer to //its// callers, which would still be UB even if we changed the map to store weak pointers. Based on that I'm thinking we should store them as shared pointers instead of weak ones.
Then maybe the solution is to store the type as unique pointers in the map and hand out raw pointers, relying on the map to keep the object alive? I feel pretty uncomfortable with handing out shared pointers without clearly understanding its lifetime cycle.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D141318/new/
https://reviews.llvm.org/D141318
More information about the lldb-commits
mailing list