Since we can report memory leaks on one variable, while the originally
allocated object was stored into another one, we should explain
how did it get there.
rdar://76645710
Paths
| Differential D100852
[analyzer] Track leaking object through stores ClosedPublic Authored by vsavchenko on Apr 20 2021, 7:12 AM.
Details Summary Since we can report memory leaks on one variable, while the originally rdar://76645710
Diff Detail
Event TimelineHerald added subscribers: ASDenysPetrov, Charusso, dkrupp and 7 others. · View Herald TranscriptApr 20 2021, 7:12 AM vsavchenko added a parent revision: D100839: [analyzer] Adjust the reported variable name in retain count checker.Apr 20 2021, 7:16 AM Comment Actions I think this is already way better than before. I see that OSDynamicCast isn't supported yet and we seem to hit the same wall as D97183 because inter-operation between trackExpressionValue and the checkers isn't implemented yet.
vsavchenko marked an inline comment as done. Comment ActionsAdd a comment and replace getAs with castAs Comment Actions
Let's say that OSDynamicCast isn't fully supported. If we have a chain of bindings var1 -> var2 -> ... -> varN and varM -> varM+1 is a dynamic cast assignment, we will create a note that varM+1 is assigned/initialized here (as you can see in tests), but not further down the chain. check_dynamic_cast_alias_intermediate is a good example here.
vsavchenko added a child revision: D101041: [analyzer] Find better description for tracked symbolic values.Apr 22 2021, 3:10 AM This revision is now accepted and ready to land.Apr 25 2021, 11:34 PM Closed by commit rGe273918038a7: [analyzer] Track leaking object through stores (authored by vsavchenko). · Explain WhyApr 28 2021, 8:38 AM This revision was automatically updated to reflect the committed changes.
Revision Contents
Diff 341227 clang/lib/StaticAnalyzer/Checkers/RetainCountChecker/RetainCountDiagnostics.cpp
clang/test/Analysis/Inputs/expected-plists/edges-new.mm.plist
clang/test/Analysis/Inputs/expected-plists/retain-release-path-notes.m.plist
clang/test/Analysis/Inputs/expected-plists/retain-release.m.objc.plist
clang/test/Analysis/Inputs/expected-plists/retain-release.m.objcpp.plist
clang/test/Analysis/osobject-retain-release.cpp
clang/test/Analysis/retain-release-path-notes.m
|
Because we already know that Val.getAsLocSymbol() is equal to Sym, we can be certain that Val is either a &SymRegion{Sym} (i.e., literally this symbol in its pristine representation) or, in some rare cases, a LocAsInteger over that (which is a case i'm not sure we even want to handle). I dunno if we really need to return it here. Maybe it's easier to re-construct it in place as SValBuilder.makeLoc(Sym).