[PATCH] D105821: [analyzer] [WIP] Model destructor for std::unique_ptr

Artem Dergachev via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Mon Jul 26 10:37:12 PDT 2021


NoQ added a comment.

In D105821#2903606 <https://reviews.llvm.org/D105821#2903606>, @RedDocMD wrote:

> The following code **emits** a warning for leaked memory:
> ...
> Why does the following command not display the warnings?

Wait, what's the difference between this command and the command that **did emit** the warning for you?

With that specific invocation, apart from the missing `cplusplus.NewDeleteLeaks`, and apart from noticing that `std::make_unique` isn't actually getting modeled but inlined instead (I have all your patches pulled and this patch applied; and the object-under-construction seems to be available later, in both C++11 and C++17, so it's kinda weird and needs more debugging), I think the reason this doesn't warn is that the pointer is technically put on the heap (when stored into `Lame::ptr`) which makes it accessible for the entire program and therefore potentially delete-able by anybody and we suppress the warning (it's kinda frustrating but we already have the opposite problem for locals and we don't really know how to solve either of those: D71041#inline-641497 <https://reviews.llvm.org/D71041#inline-641497>, the reverted D71152 <https://reviews.llvm.org/D71152>, etc.)

So basically it sounds like this is indeed not going to be too big of a problem, given that memory managed by `unique_ptr` is always heap memory, so everything that's ever put there during analysis is never going to produce any leak warnings. Maybe we could indeed get away with conservative modeling of constructors (inside `make_unique`) and destructors.

We do need conservative modeling of constructors in `make_unique` though, otherwise your pointer never reaches `Lame::ptr` which means an actual leak warning.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D105821/new/

https://reviews.llvm.org/D105821



More information about the cfe-commits mailing list