[PATCH] D98726: [analyzer] Enabling MallocChecker to take up after SmartPtrModelling

RedDocMD added a comment. The issues highlighted here have been partially (one could argue mostly) solved by D105821 . That patch hasn't been merged because it needs more tests and also needs to be split. Repository: rG LLVM Github Monorepo CHANGES SINCE LA

[PATCH] D98726: [analyzer] Enabling MallocChecker to take up after SmartPtrModelling

steakhal added a comment. What's the status on this? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D98726/new/ https://reviews.llvm.org/D98726 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https

[PATCH] D98726: [analyzer] Enabling MallocChecker to take up after SmartPtrModelling

xazax.hun added a comment. We probably did not update this PR with the discussions we had offline. Basically we had a bug with a sink node due to calling into a destructor of `unique_ptr`. The catch is that the ctor was evalcalled, so the store did not have the correct bindings. Thus, after inl

[PATCH] D98726: [analyzer] Enabling MallocChecker to take up after SmartPtrModelling

NoQ added a comment. In D98726#2798325 , @RedDocMD wrote: > This is what causes the false suppression. To be more specific, the analyzer > tries to follow the logic of the destructor of unique_ptr into the standard > library. And since that is in the std

[PATCH] D98726: [analyzer] Enabling MallocChecker to take up after SmartPtrModelling

RedDocMD added a comment. In D98726#2719100 , @RedDocMD wrote: > Judging by this line > > in the `LikelyFalse

[PATCH] D98726: [analyzer] Enabling MallocChecker to take up after SmartPtrModelling

NoQ added a subscriber: vrnithinkumar. NoQ added a comment. Herald added a reviewer: teemperor. Herald added a subscriber: manas. Ok so if I was to debug this further, I'd set a breakpoint on `markInvalid()`, figure out which invocation corresponds to the right bug report, and that'd lead me to

[PATCH] D98726: [analyzer] Enabling MallocChecker to take up after SmartPtrModelling

RedDocMD added a comment. In D98726#2721228 , @NoQ wrote: >> when the visitor encounters an `ExplodedNode` > > Weird. `finalizeVisitor()` accepts not any node but the error node. Your > screenshot suggests that the error node is not in the standard librar

[PATCH] D98726: [analyzer] Enabling MallocChecker to take up after SmartPtrModelling

RedDocMD added a comment. In D98726#2721228 , @NoQ wrote: >> when the visitor encounters an `ExplodedNode` > > Weird. `finalizeVisitor()` accepts not any node but the error node. Your > screenshot suggests that the error node is not in the standard librar

[PATCH] D98726: [analyzer] Enabling MallocChecker to take up after SmartPtrModelling

NoQ added a comment. > when the visitor encounters an `ExplodedNode` Weird. `finalizeVisitor()` accepts not any node but the error node. Your screenshot suggests that the error node is not in the standard library but in user code. Might it be that there are multiple error nodes and you're looki

[PATCH] D98726: [analyzer] Enabling MallocChecker to take up after SmartPtrModelling

RedDocMD added a comment. Judging by this line in the `LikelyFalsePositiveSuppressionBRVisitor::finalizeVisitor()` method, it seems that the bug repor

[PATCH] D98726: [analyzer] Enabling MallocChecker to take up after SmartPtrModelling

RedDocMD added a comment. The call to `PathSensitiveBugReport::markInvalid()` is triggered by `LikelyFalsePositiveSuppressionBRVisitor::finalizeVisitor()`. So I guess we need to see now why the visitor thinks this is a false positive. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST A

[PATCH] D98726: [analyzer] Enabling MallocChecker to take up after SmartPtrModelling

NoQ added a comment. In D98726#2714215 , @RedDocMD wrote: > I think something is wrong about the way we are investigating this or I don't > understand the `MallocChecker`. > The following doesn't yield a bug report! => https://godbolt.org/z/Y57G7zE5j Uh-

[PATCH] D98726: [analyzer] Enabling MallocChecker to take up after SmartPtrModelling

RedDocMD added a comment. F16456099: 2021-04-24_733x821.png As you can see here, the bug note is attached in the second case (please refer to my previous comment), but somehow, it doesn't finally show up as a bug. Weird. Repository: rG LLVM Github Monorep

[PATCH] D98726: [analyzer] Enabling MallocChecker to take up after SmartPtrModelling

RedDocMD added a comment. Okay, this is alarming. The following code yields a leak warning: #include #include struct A { int field; A(int f = 0) : field{f} {} void foo() { std::cout << "Field: " << field << "\n"; } }; void foo() { int *raw = new int(10); std:

[PATCH] D98726: [analyzer] Enabling MallocChecker to take up after SmartPtrModelling

RedDocMD added a comment. I think something is wrong about the way we are investigating this or I don't understand the `MallocChecker`. The following doesn't yield a bug report! => https://godbolt.org/z/Y57G7zE5j Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews

[PATCH] D98726: [analyzer] Enabling MallocChecker to take up after SmartPtrModelling

NoQ added a comment. In D98726#2630947 , @RedDocMD wrote: > @NoQ, regarding https://godbolt.org/z/1EczEW, I don't think there should be a > warning since the original pointer may be needed in the caller. You're absolutely right! I missed this point! I s