This is an archive of the discontinued LLVM Phabricator instance.

[analyzer] MallocChecker: pr39348: Realize that sized delete isn't a custom delete.
ClosedPublic

Authored by NoQ on Oct 22 2018, 5:44 PM.

Details

Summary

Fixes https://bugs.llvm.org/show_bug.cgi?id=39348

Under -fsized-deallocation, the new test case in NewDelete-sized-deallocation.cpp produces a call to operator delete with an explicitly passed size argument. MallocChecker didn't expect that and identified this as a custom operator delete, which lead to a leak false positive on extremely simple code.

Identify custom operators by source locations instead of guessing by the number of parameters. This sounds much more correct.

Additionally, it exposes a regression in NewDelete-intersections.mm's testStandardPlacementNewAfterDelete() test, where the diagnostic is delayed from before the call of placement new into the code of placement new in the header. This happens because the check for pass-into-function-after-free for placement arguments is located in checkNewAllocator(), which happens after the allocator is inlined, which is too late. Move this use-after-free check into checkPreCall instead, where it works automagically because the guard that prevents it from working is useless and can be removed as well.

I didn't bother looking at NewDelete-custom.cpp because they only manifest under the non-default-and-never-planned-to-be-default-anymore option -analyzer-config c++-allocator-inlining=false. I believe that this flag can be removed entirely. I think we've previously been thinking that these are false negatives in the new mode that are potentially undesired. Did anybody actually end up using it? If a more aggressive behavior towards custom allocators is desired, would it make sense to re-implement it directly, without relying on side effects of broken operator new modeling (?)

Diff Detail

Repository
rL LLVM

Event Timeline

NoQ created this revision.Oct 22 2018, 5:44 PM
NoQ updated this revision to Diff 170541.Oct 22 2018, 5:46 PM

Nono, that was an old patch, sry. Here's the correct patch.

NoQ updated this revision to Diff 170543.Oct 22 2018, 5:50 PM

Remove weird flags that i used for debugging from the test run-lines.

MTC added a subscriber: MTC.Oct 23 2018, 6:53 AM
MTC added inline comments.
test/Analysis/NewDelete-custom.cpp
7 ↗(On Diff #170543)

Should we continue to keep this line?

test/Analysis/NewDelete-sized-deallocation.cpp
1 ↗(On Diff #170543)

I believe sized deallocation is the feature since C++14, see https://en.cppreference.com/w/cpp/memory/new/operator_delete.

because the guard that prevents it from working is useless and can be removed as well

Should we remove it then?

lib/StaticAnalyzer/Checkers/MallocChecker.cpp
729 ↗(On Diff #170543)

Should we return true on invalid source location?
Do we have a test case for that?

2444 ↗(On Diff #170543)

why it's fine to remove this branch?

test/Analysis/NewDelete-custom.cpp
7 ↗(On Diff #170543)

yes, since there are not diagnostics emitted. it would complain otherwise.

test/Analysis/NewDelete-sized-deallocation.cpp
1 ↗(On Diff #170543)

specifying 17 is also fine

NoQ updated this revision to Diff 170704.Oct 23 2018, 11:13 AM
NoQ marked an inline comment as done.

Add tests for different versions of the standard and for different ways to declare operator delete.

Should we remove it then?

why it's fine to remove this branch?

Because these two questions refer to the same branch (:

This revision is now accepted and ready to land.Oct 23 2018, 11:27 AM
MTC added inline comments.Oct 23 2018, 7:10 PM
test/Analysis/NewDelete-sized-deallocation.cpp
1 ↗(On Diff #170543)

Yea, that's true.

Szelethus added inline comments.Oct 24 2018, 5:01 AM
lib/StaticAnalyzer/Checkers/MallocChecker.cpp
727 ↗(On Diff #170704)

typo: if

test/Analysis/NewDelete-custom.cpp
3–4 ↗(On Diff #170704)

Do we still need -DLEAKS=1 and -DALLOCATOR_INLINING=1?

NoQ updated this revision to Diff 170946.Oct 24 2018, 12:00 PM

Address comments!

NoQ added inline comments.Oct 24 2018, 12:02 PM
lib/StaticAnalyzer/Checkers/MallocChecker.cpp
727 ↗(On Diff #170704)

https://en.wikipedia.org/wiki/If_and_only_if

Thx for pointing out that it's not an entirely common jargon!

test/Analysis/NewDelete-custom.cpp
3–4 ↗(On Diff #170704)

I guess i'll just remove the no-leaks run-lines because they didn't make sense in the first place.

This revision was automatically updated to reflect the committed changes.